But I have a problem with implicit multiplication in CAS. I understand that implicit multiplication can be some times quite ambigous but it is also quite conveniant for simple formulas.

This is when I get into trouble... If I enter the formula

"2x^2" then CAS interprets this as 2*x^2 and it is fine to me, but when I type

"2(x-1)^2" then the CAS interprets this as (2*(x-1))^2 :(
The problem seems to come from the parenthesis after the number :

"2(x)^2" gives me (2*x)^2

Knowing this, I avoid to use implicit multiplication but this is a real issue when student use this and get some wrong answer because the implicit multiplication has been misinterpreted.

Yeah, there was (and still is) a big discussion about this. I got the impression that there was a willingness to change its behavior -- but the current code makes the actual change somewhat of a challenge.

Thank you for the link to the thread. It is very instructing about how implicit multiplication can be ambiguous, but I don't see a clear answer about how (X)CAS deals with numbers followd by a "(" : 2(x-1)^2 --> (2*(x-1))^2

At the beginning, I thought this was a bug in the CAS implementation of Xcas on the Prime, but i checked on Xcas itself and I have the same issue. The only difference is that Xcas gives us a warning. On the prime, we have no warning at all. So it seems that it is a choice to evaluate 2(x-1)^2 as (2*(x-1))^2, choice I can't understand.

IMHO if CAS detects that there is a risk of bad interpretation on the implicit multiplication, it should warn us or simply refuse to evaluate the expression until the user use explicit multiplication.

I don't remember why, but there is a special #ifdef in the source code not to warn for implicit multiplication in Prime. I think I should remove this ifdef. Xcas indeed warns you that you are doing something ambiguous. And I don't know how to specify a different priority with bison/yacc. The reason why 2x^2 is interpreted as 2*x^2 and 2(x-1)^2 is not is just that there is a specific rule for monomials. My opinion is that you should always use *, I made an exception for a number followed by a variable name (optionnally followed by a power) because I want to have a shortcut for monomials, but that's all. I also recently added in Xcas a rule for a number followed by a commandname with arguments, like 2sin(x).

I think a real issue is being called out here and especially in the other discussion linked above. I side completely with 'fhub' with regard to implicit multiply behavior just because the '*' is implicit should in no way alter precedence. I honestly don't think there is any ambiguity for a human reader.

The shift/reduce decision is not a problem of which operator has a higher precedence, but about whether a given token has a higher precedence than a given rule. All we have to do is assign precedence to both the tokens and the rules.

Quote:
I think a real issue is being called out here and especially in the other discussion linked above. I side completely with 'fhub' with regard to implicit multiply behavior just because the '*' is implicit should in no way alter precedence. I honestly don't think there is any ambiguity for a human reader.

The shift/reduce decision is not a problem of which operator has a higher precedence, but about whether a given token has a higher precedence than a given rule. All we have to do is assign precedence to both the tokens and the rules.

Unfortunately that does not work. As I said in a previous thread, I tried it with the precedence of T_FOIS, just tried now introducing a new token, but it does not work differently, x/2y still returns x/(2*y).

And by the way, I observed about 100 students this week and the preceding one who had never used a CAS before, and they entered x/2y for x/(2*y) and not for x/2*y, I'm not alone to find the second notation not intuitive.
Also, I want to keep Xcas philosophy of being tolerant, that's why I won't reject 2(x-1)^2, but accept it and issue a warning. Don't forget that the average user is not obsessed about rules, but about entering an expression in a natural way.