Opened 10 years ago

Closed 3 years ago

#10567 closed defect (wontfix)

Parentheses break implicit_multiplication

Reported by: eviatarbach Owned by: was
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: user interface Keywords:
Cc: Merged in:
Authors: Eviatar Bach Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

Parentheses (brackets) seem to break implicit_multiplication, but only in some cases. This seems to be when a non-bracketed factor is followed by a bracketed. It seems to be a problem with the preparser. Here are a few examples:

sage: implicit_multiplication(True)

Working examples:

sage: (x+3)(x+4)
(x + 3)*(x + 4)
sage: (3) x
3*x
sage: 3(x+3)
3*x + 9

Non-working examples:

sage: x(x+3)
x + 3
sage: x (3)
3

Preparser does not work:

sage: preparse('x(x+3)')
'x(x+Integer(3))'

This is quite a major issue for implicit_multiplication.

Change History (7)

comment:1 Changed 10 years ago by lftabera

Well,

I think that "x(x+3)" and "x(3)" will never work, since this is the syntax of function call.

If you made the preparser to transform "x(3)" to "x*3". How will you be able to use a function named x to value 3?

comment:2 Changed 10 years ago by eviatarbach

  • Resolution set to invalid
  • Status changed from new to closed

Oh, that's why! I can't believe I didn't notice that.

comment:3 Changed 10 years ago by eviatarbach

  • Resolution invalid deleted
  • Status changed from closed to new

However, here are some examples where this doesn't work when it should.

sage: (5) (3*5)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/eviatar/<ipython console> in <module>()

TypeError: 'sage.rings.integer.Integer' object is not callable
sage: (x+3) (x+3)
x + 6

comment:4 follow-up: Changed 3 years ago by gh-black-stones

  • Milestone set to sage-duplicate/invalid/wontfix
  • Status changed from new to needs_review

There's nothing wrong with either example

(5) (3*5) is still a function call and therefore invalid because "(5)" is not a function

(x+3) (x+3) - the first (x + 3) creates an expression, and then you call the expression with the argument (x + 3). So for example (x + 3)(2) would be 2 + 3 = 5, (x + 3)(y) = y + 3, and (x + 3)(x + 3) = x + 3 + 3 = x + 6

comment:5 in reply to: ↑ 4 ; follow-up: Changed 3 years ago by nbruin

Replying to gh-black-stones:

(5) (3*5) is still a function call and therefore invalid because "(5)" is not a function

(x+3) (x+3) - the first (x + 3) creates an expression, and then you call the expression with the argument (x + 3). So for example (x + 3)(2) would be 2 + 3 = 5, (x + 3)(y) = y + 3, and (x + 3)(x + 3) = x + 3 + 3 = x + 6

These are not examples the ticket complains about. These are in fact handled as multiplication if one sets implicit_multiplication(level=10) (so (sin)(x) and sin(x) get preparsed differently depending on level)

The ticket can probably still be closed as "wontfix" because the preparser can't see the difference between x and sin, and hence parsing x(1) as multiplication would make function calls indeed impossible.

comment:6 in reply to: ↑ 5 Changed 3 years ago by gh-black-stones

Replying to nbruin:

These are not examples the ticket complains about.

See comment 3

I am just saying that when the level is set to True, the two examples are not treated as multiplication and this is intentional. To treat them as multiplication, as you pointed out, we should set the level to 10. Anyways, I concur that we should close this ticket as wontfix.

comment:7 Changed 3 years ago by embray

  • Resolution set to wontfix
  • Status changed from needs_review to closed
Note: See TracTickets for help on using tickets.