Peculiar precedence

[cdecastro]

Noticed the following odd behavior on the Prime in CAS mode,

case 1: -16(0.5)^2 = -64
case 2: -16*(0.5)^2 = -4

It seems without the explicit multiplication, -16(0.5) takes precedence over the squaring (0.5)^2. In HOME mode, the computation works as expected (i.e. case 2)

Appreciatively,
Chris

[parisse]

What is the logic behind writing parenthesis inside -16(0.5)^2 = -64?
It is faster to write -16*0.5^2, and it does not use implicit multiplication.
You should not use implicit multiplication inside the CAS without testing before. The CAS parser has rules for implicit multiplication only for expressions like
3x (also valid for 3i)
3x^2
3sin(x)
3sin(x)^2

These rules correspond to line 201-206 in the input_parser.yy file from giac source

Code:


    | 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 T_NUMBER %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));}
    | T_NUMBER T_UNARY_OP T_BEGIN_PAR exp T_END_PAR    { $$ =$1*symbolic(*$2._FUNCptr,$4); }
    | T_NUMBER T_UNARY_OP T_BEGIN_PAR exp T_END_PAR T_POW T_NUMBER    { $$ =$1*symb_pow(symbolic(*$2._FUNCptr,$4),$7); }

Of course I welcome any improvement for the parser if someone knows flex/bison enough.

[cdecastro]

Thanks for the reply Parisse! I was simply surprised when my son, a student, used the HP Prime to evaluate the expression -16(0.5)^2 and obtained the surprising (to me) result. Granted that -16*0.5^2 would be simpler, I would nonetheless have expected the implied multiplication to have been made explicit by the parser as done in HOME mode. He just needs to know that operations should be explicitly stated (just as when coding in a programming language) in any given expression as precedence is idiosyncratic between the two modes.

Appreciatively,
Chris

[Marcel]

Hi
The TI-Nspire always have the same result for a expression...
I think this is a bad thing for the Prime!
Marcel

[parisse]

I think it's probably impossible to have a bison/flex parser that correspond to what user expects (I mean if users do not read the documentation). For example look at
f(x+1)^2
x(x+1)^2
In the first example, you expect (f(x+1))^2 not f((x+1)^2). In the second example, x is almost certainly not a function because you apply it to something depending on x, and you would expect x*(x+1)^2. The precedence is not the same, but at parse time, f and x are both symbols, it is impossible for the grammar to make a difference. Therefore one must choose f(x+1)^2 precedence, because f() is the standard notation for a function, while x(x+1) is (non-standard) implicit multiplication.
Now, a highschool targetted CAS like the tinspire CAS has probably a homemade parser that applies a lot of special rules for implicit multiplication ... but on the other hand, the nspire CAS is not functional, you can not pass a function as argument to another function (the same is also true on the Prime in Home).
There is a learning curve to use a general purpose CAS like Giac. The first thing you should know is that implicit multiplication is not supported, except for the few shortcuts I recalled in my last post. The Xcas UI will give you a warning if you enter something like x(x+1)^2, I don't know why it's not displayed on the Prime, I think it would make things less confusing.

[cdecastro]

Thanks for the detailed comments. I appreciate the challenges in parsing such expressions, e.g. how is the parser to know whether ax is variable ax or the product of two variables a and x? Does it make any difference however when one of the expressions is a "constant". I gather the real issue is that this is a semantic issue that is ultimately unknown to the parser, i.e. the parser is only aware of syntax.

I am a high school mathematics teacher myself and wanted to share this experience in the interest of making work with the Prime more seemless. My only concern was that if the product is directed at an educational market, there might be some confusion from students who switch from one mode to another expect similar behavior. But, I will admit that we did not consult the documentation prior to this exploration, we were just surprised with the result. Thanks very much for the discussion and advice.

Appreciatively,
Chris

[parisse]

Correct, the parser has two pass: the first one (flex: lexical analyser) recognizes "tokens", i.e. x or f or ax are token of type T_SYMBOL, then the second pass (bison grammar) has rules that are applied to recognize a valid expression, e.g.
T_NUMBER T_MULT T_SYMBOL
or
T_NUMBER T_SYMBOL
etc.
At that step, the parser does not use the value of the token, only the type.
As for the documentation, I would not bet that HP has documentation on the CAS parser (to be honest, I don't think we have for Xcas, except maybe an emphasis on avoiding implicit multiplication).
It's intersting to see that the issue is raised here for the Prime, while I did not get questions like that for Xcas in France. Perhaps one reason is that you are using much more implicit multiplication?