thread repost: Discussion on Parser/UI Options

[Manolo Sobrino]

Tim, thanks again for resurrecting the thread. I didn't want to write about the Prime any more... but now that Bernard joins in:

(04-03-2014 07:44 PM)parisse Wrote:  5/ I don't believe that having dedicated typed and always affected variables like A-Z, Z1-Z0, L1-L0 etc is good, nor implicit multiplication, ...

I agree with you with respect to automatic variables with fixed types, it's a limitation that maybe creates other problems, and maybe they should be called registers instead. But the real problem comes when the numerical environment can't handle (symbolic) undefined variables by itself. You can't interoperate effectively with a CAS if all your variables need to have an assigned value always. The whole point of Algebra is not dealing with particular values of things...

... Wait a moment, really?

Funny things happen, and I'm talking about the state of things according to the emulator (2013 11 25. Rev:5447), so maybe it is not like this any more and you all should just ignore what comes next (I have plenty of calculators for my needs and although I generally agree with what Tim told us I can't justify getting yet another school one, even more so at this stage of development... I don't do this for a living. Anyway, if anyone is willing to give one away, I'd reconsider it )

1) Go to CAS and define: y:=x

2) Go to HOME and input: y

Then the numerical CLI prints: x

That's very good because it knows that x=y.

3) input x

Then you get "Error: Syntax Error". Same error as if you hadn't defined y. The variable y has been created by the CAS, HOME knows about it, no problem. It knows that whatever is y, its value is x. But it doesn't know what x is! It's strange because at the Vars menu, x and y appear both as CAS variables. I guess Giac creates variables on the fly and the numerical environment doesn't.

That is not that bad, because now we've learnt that we can move symbolic variables around environments by doing this... Say you want to get an expression with engineering-ugly numerical coefficients in terms of the variable x. Just do it with y. Quirky things happen then that I guess can be worked around with the approx() function. (Why Giac's evalf() and evalc() are not in the CAS menus is a mystery to me.)

Wouldn't the logical thing be that any unknown variable is created on the fly by HOME as a Giac variable? Say when I input x, it prints x?

This kind of problems arises when you're glueing things together. That's why I still think that building the new software around Giac, in the sense I expounded, is the better technical solution. Tim doesn't, but the truth is that it doesn't matter because constraints for the project have already killed that road. And if things are worked out and you get the most of Giac functionality behind whatever HP wants that's a good outcome. It's not easy, though.

About implied multiplication. Well, many people just expect it because it's nice sharing the conventions of blackboard-written maths with the syntax of the computer program you're using, even when we're just dealing with 1-d expressions. Mathematica does it and there is no ambiguity there. I think it's just a personal choice.

If you do it, you have to be consistent: The Giac interpreter version, that is CAS mode, understands x(1+x), but not (1+x)x. In HOME mode, in terms of the previously CAS-defined y:=x, interesting things happen (emulator) again:

(1+y)y is rendered immediately as: (1+y)*y ____________ (1+x)*x

y(1+y) as... y(1+y) ____________ x(1+x)

(Where are the *'s now??) It's funny, looks like if you want to parse implied left-multiplication you have to be in CAS, and if you want to parse implied right-multiplication you have to be in HOME. HP calculators tend to be convoluted, but that's too much convolution . Clearly the Prime needs its own parser.

Giac/Xcas 1.1.0 gives you an 'implicit multiplication' warning about x(1+x), but comes up with x*(1+x). With (1+x)x, a parser error happens.

(04-03-2014 07:44 PM)parisse Wrote:  All this vision is probably not shared by HP, I have no problem with that, perhaps I'm wrong after all, but of course I implement Xcas following my vision. And I don't think it's a problem for HP or geogebra (4.4 by the way, not 5.0) because it means I concentrate on improving the computing kernel, which is a plus whatever your vision is.

A good thing about this is that we're not in fear of a case of Big Company killing another CAS . It's your work, it's GPLv3, the only one that can dare to think that you're wrong is yourself. I expect to use more Giac/Xcas now that I have some Android devices around (there are some minor annoyances, Xcas Pad doesn't seem to have a quick access to evalf()). Let me thank you for it.

I believe both projects can (and should) coexist happily while keeping their own characteristics.