Hi everyone

I am a new user of the HP prime and I already love it

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.

Quote:

---

Hi everyone

I am a new user of the HP prime and I already love it

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.

Link to previous discussion

Edited: 25 Oct 2013, 2:16 p.m.

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).

Thank you for your answer. A warning is already a good thing.

Do you think it would be possible to limit the use of implicit multiplication only for the cases you mentionned and reject the user input in the other cases ?

Quote:

---

Implicit multiplication is accepted only in the following situation: a number followed by a symbol, or a number followed by a symbol to a power

---

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.

Trevor king discusses the problem of implicit mul in yacc:

http://www.physics.drexel.edu/~wking/code/yacc2dot/#implicit_multiplication

Good quote from Trevor :

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.

Trevor king discusses the problem of implicit mul in yacc:

http://www.physics.drexel.edu/~wking/code/yacc2dot/#implicit_multiplication

Good quote from Trevor :

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.

---

exp : T_NUMBER {$$ = $1;}
| T_NUMBER T_SYMBOL %prec T_IMPMULT {if (is_one($1)) $$=$2; else $$=symbolic(at_prod,gen(makevecteur($1,$2),_SEQ__VECT));}
| T_NUMBER T_SYMBOL T_POW exp %prec T_IMPMULT {if (is_one($1)) $$=symb_pow($2,$4); else $$=symbolic(at_prod,gen(makevecteur($1,symb_pow($2,$4)),_SEQ__VECT));}
| T_NUMBER T_SYMBOL T_SQ %prec T_IMPMULT {$$=symbolic(at_prod,gen(makevecteur($1,symb_pow($2,$3)) ,_SEQ__VECT));}
| T_NUMBER T_LITERAL %prec T_IMPMULT {if (is_one($1)) $$=$2; else $$=symbolic(at_prod,gen(makevecteur($1,$2) ,_SEQ__VECT));}
...

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.