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