thread repost: Discussion on Parser/UI Options

[Tim Wessman]

There was a long thread in another section of the forum that has accidentally been deleted a short while ago. I posted a long explanation of possible options attempting to address or explain some choices and decision points to Manolo who I felt in some ways wasn't understanding the thinking or reasoning behind some of the difficult decisions in Prime. I wanted to address his valid points and possibly get some more information regarding his reasoning. This wasn't meant to change his mind or to argue or discount his opinion, but rather to explain the deep thinking and potentially come to a better understanding on both sides.

He seemed to quite positively respond to our discussion as did some other people, but then it was accidentally deleted. I am restoring the parts that he was able to save. I will also attempt to restore some later treads that were made by others who commented on the discussion. Hopefully it will be understandable and I won't mix up comments from the wrong person. Apologies in advance if that happens.
================================

Quote:(03-29-2014 11:18 PM)Manolo Sobrino Wrote: I ranted about the Prime when it appeared, not any more. The last thing I suggested was hiding the Giac console -because yes guys, that's what you have for a CAS- from the user,

I agree completely!!! At least when the CAS is behaving consistently, not refusing to solve something for an unclear reason, and when the results are returned in and expected manner. Until that time though, seeing why the CAS refused to solve, or what it was doing can be very helpful. In short, one things are acting nicely, it is completely unhelpful. I don't think it will be much longer long though before it would be possible to be hidden away and only if you select to tap the little icon or similar will it bring up some additional useful info.

Quote: even when I've always said that the sensible thing to do was to build this new calculator around Giac, because that's what makes sense in order to get a coherent UI and that's what other companies with enough resources did in the past and worked fine.

In what way does it make sense? I've seen you cite that it makes sense, but other then "coherent UI" (in what way? How will that make it such?) and that "others have done it", I haven't seen much in the way of details.

Having spent a very, very long time thinking about this, and working with the giac codebase though, I can give about 20 reasons in an instant why it doesn't make sense, and only 1-2 that do make sense. Addressing your point #1 regarding UI:

(By UI I assume you are referring to the current parser schizophrenia)

The giac parser is done with lexx/yak. That lets you add things quickly, but when you get right down to it there is not a whole lot of flexibility in attempting to do anything outside the conceived original design of how a parser should work. You can easily recognize *static* known words and patterns, but if you attempt to do more intelligent parsing that changes behavior slightly depending on the context it gets ridiculously difficult and complex to implement VERY quickly.

In addition to not having a large amount of control to do selective recognition, there really is no mechanism in place for working with sub parts of the expressions. You either have an all or nothing parsing. You can't stop in the middle to handle errors, identify problems and prompt the user to resolve them, or do any similar things that would be helpful to the end user. This is part of the reason why any sort of "parse" error in the CAS returns a big error string, while in the home screen you are stopped and asked to fix it with the cursor right at the point of problem.

So assuming that in order to get the UI and experience to the point that I'd like it to be, there really are two choices with regards to parsing. Either you spend the time and effort to modify and extend the existing lex/yakk parser to handle EVERY potential plan and idea we have for future development, or you modify the home/numeric parser to support what is needed in order to shift all parsing in the system under the same roof. Either of those tasks is very, very large. One of them however is much, much, much shorter.

When geogebra implemented a CAS system in geogebra 5.0, they had a similar choice. There was an already existing parser that fit extremely well with the system design and met all the desires and needs in the way that made sense for that piece of software. They could have used the CAS parser directly... yet they didn't. They modified their parser to be able to pass only specific items to giac for evaluation, and interpret the results back into the existing format.

One of giac's weaknesses is that it does not have very tight memory control. This is primarily due to it being written from the assumption of having exceptions (which are very often not supported well or buggy on embedded system compilers) and that it will be running on a desktop. It uses tons of small memory allocations and pointers everywhere - the base data structure is quite complicated and it thrashes the memory. Again, this isn't an incorrect decision for a desktop application, but for a limited memory embedded device with potentially questionable OS support it does make problems.

Now if we move on to the wider idea (excluding the technical issues) of building the system around giac, we immediately run into vision conflicts. I am not even going to get into the "business" considerations and concerns a PHB type person might have, but there are *seriously* many of those as well.

1. Assume that the system would be built around giac. Exactly what does that mean? (I'd be interested to know that because depending on how you are interpreting that statement we might have much more common ground then you thing) For now, lets assume that all parts of the system use giac for parsing end evaluation.

a) You have just lost the ability to disable parts of the calculator. Giac is a monolithic blob and for many places in the world the calculator now has no future because it can't be controlled in an exam. While nobody here would consider that a problem, not making money on a device is about the quickest way to ensure that device doesn't stay around long.

b) you now have very slow programs. Giac is a great CAS from a capability point, but it has as a CORE ASSUMPTION that everything is exact and symbolic. Remember how on the 50g you can get radically different times for programs based on approx or exact? Now assume that EVERYTHING will always be exact first and there is basically nothing you can do about it. That is pretty much the situation. Throw on top of that the higher memory requirements, less tight control of loops and recursion, etc.

c) high speed graphing is no longer there. It will go much, much slower then the current basically instant graphing.

d) there can't be any sort of interval based graphing or calculations due to complete incompatibility between a symbolic engine and what is required for interval graphing.

e) memory and objects now have a completely flat "session" interface. All calculations and objects are saved into a single flat blob that is only possible to load completely. No folders. No access from outside. (didn't people want folders?) I haven't even gotten to talk about the whole app thing yet and people would already be angry.

f) any hp designed features are not going to be accepted into the "mainline" because in many cases they aren't desired for the users of a pure symbolic package as a whole. For example, having more then 8 colors. Yes, that is a limit inherent to the underlying data structure. Binary/hex/oct/dec simialr to the 48 series? Not in there. An integer is essentially a different thing and used for a different purpose. Spreadsheet access such as A1:B4 to get a region... not going to be there. What should sin(pi) be equal to? What is the meaning of accurate to n places? These are fundamental question and differences in assumptions that depending on your view can radically alter everything.

It is getting late and I am tired, but I believe I could add another 5 on here without too much difficulty.

So let's assume that we now rework giac/xcas to do everything exactly as we'd like, and to meet our plans. First, you've probably about doubled or tripled the length of development. Second, as stated before a lot of what HP users would like is not going to meld well, or be desired by xcas users or someone like geogebra. So in essence we've just forked it and made something that serves us and nobody else.

That means that all that time and effort ended up with us getting something which would NOT be compatible with the HP calculator vision either past or future, and not compatible with the purely symbolic system that exists, and in short wouldn't have made anything better! The problem just would have shifted to a much more difficult to resolve location.

Trust me, I do understand why people have said "well just use that cas engine", or "just buy one", or "why didn't you just use the 48 code base". Every single possible direction was considered and analyzed before the decision to move in this technical direction was taken. I am not trying to dismiss what people say, or tell them they are wrong, or make anyone angry. Rather, there WAS no good technical solution that would cleanly work in the first step.

Prime is doing very well. There are people getting into HP calculators that never have been before. Doors are opening that with a 50g, or a 51g, or a 52g, would never be open. For the vast majority of users who primarily use the calculator to do some math, draw some graphs, and take some tests - this calculator is amazing to them! I've seen people with no interest in math start playing with it, exploring the calculator, and getting excited about MATH! That just does not happen with other calcs in my experience.

This isn't a children's game where the first time something wrong happens they throw the pieces away, kick someone, and then run and hide under the bed. (just happened today... )

Just remember that big companies are a lot like big ships. They take a long time to get moving and a long time to turn. Once they are moving though, they either run into a rock and sink, or else are hard to stop.


End note - it may seem like I was picking on giac/xcas, or Bernard, or whatever. That is not the case. I think that giac has amazing capability. I have seen an impressive array of cases where it will solve something not possible in either casio/ti units, and even in some professional desktop or powerful open source cas systems (eg: maxima).

If I was to sum up the weaknesses, I would say that it makes some simple things more difficult then needed at times, and a lack of polish generated by restricted usage. That can be corrected though by feedback from a wide range of users and sources. Just in the past 6 months as there has been work with both HP and Geogebra I think it has made significant advances and is hugely better then it was before. I am quite confident that it will just continue to improve.

[Tim Wessman]

[This is Manolo's post, recaptured from a saved copy]
========================================
I said that I sincerely don't want to write anything more about the Prime, but you drag me to it! In any case, this is very interesting stuff and I thank you (I hope all here will do as well) for your earnest effort to explain the decisions you've made.

Quote:I agree completely!!! At least when the CAS is behaving consistently, not refusing to solve something for an unclear reason, and when the results are returned in and expected manner. Until that time though, seeing why the CAS refused to solve, or what it was doing can be very helpful. In short, one things are acting nicely, it is completely unhelpful. I don't think it will be much longer long though before it would be possible to be hidden away and only if you select to tap the little icon or similar will it bring up some additional useful info.

Excellent news, and the most interesting single piece of information about the Prime posted here since it appeared. New users will be glad. Current users will be puzzled because that's quite a spectacular change of viewpoint. If that was the plan maybe saying that the CAS environment was the CAS debugging environment would have been appropriate. Anyway, that would solve the main problems with the current Prime.

Quote:In what way does it make sense? I've seen you cite that it makes sense, but other then "coherent UI" (in what way? How will that make it such?) and that "others have done it", I haven't seen much in the way of details.

Building it around Giac would have meant having in the end just one parser and one typesystem. In a calculator with an input text line, your bread & butter UI is your parser. Not that it's the only way to get there, but if we analyse how it was done before we see that that way got results.

For instance, and I'm telling this again for the unaware folks. TI wanted a CAS calculator, in the end that was the 92, and they weren't building a CAS from scratch. So they hired Soft Warehouse. The problem was that Derive was a PC program written in Lisp (mulisp), maybe too complex for an embedded device with a non standard resolution. I don't know why they chose the 68K but it the end they not only had to pick just a subset of Derive, but to rewrite it in C (probably there's a fair amount of assembler there too).

The good thing is that the syntax and functional capabilities of the 92 are that of Derive (that is the most loved thing about the 89) and you can share a good amount of Derive expressions with it. Sadly, TI wasn't really interested in taking advantage of this: the last version of Derive could export/import to your handheld. Had they not killed it, it could have evolved into a very interesting convergent environment.

That's what I meant with building around Giac. Keep the algorithms you can, keep the syntax and the overall philosophy but have the capabilities of your device in mind while rewriting everything else.

Quote:Having spent a very, very long time thinking about this, and working with the giac codebase though, I can give about 20 reasons in an instant why it doesn't make sense, and only 1-2 that do make sense. Addressing your point #1 regarding UI:

(By UI I assume you are referring to the current parser schizophrenia)

The giac parser is done with lexx/yak. That lets you add things quickly, but when you get right down to it there is not a whole lot of flexibility in attempting to do anything outside the conceived original design of how a parser should work. You can easily recognize *static* known words and patterns, but if you attempt to do more intelligent parsing that changes behavior slightly depending on the context it gets ridiculously difficult and complex to implement VERY quickly.

In addition to not having a large amount of control to do selective recognition, there really is no mechanism in place for working with sub parts of the expressions. You either have an all or nothing parsing. You can't stop in the middle to handle errors, identify problems and prompt the user to resolve them, or do any similar things that would be helpful to the end user. This is part of the reason why any sort of "parse" error in the CAS returns a big error string, while in the home screen you are stopped and asked to fix it with the cursor right at the point of problem.

Yes, that's a problem. You can't use the Giac parser, I agree. Probably you have to write your own parser.

Quote:So assuming that in order to get the UI and experience to the point that I'd like it to be, there really are two choices with regards to parsing. Either you spend the time and effort to modify and extend the existing lex/yakk parser to handle EVERY potential plan and idea we have for future development, or you modify the home/numeric parser to support what is needed in order to shift all parsing in the system under the same roof. Either of those tasks is very, very large. One of them however is much, much, much shorter.

If that's the case, then the parser is so tightly integrated with the Giac interpreter that you really have no choice. I suspected that. If refactoring the Giac code is not possible, you have to go with your own.

Quote:When geogebra implemented a CAS system in geogebra 5.0, they had a similar choice. There was an already existing parser that fit extremely well with the system design and met all the desires and needs in the way that made sense for that piece of software. They could have used the CAS parser directly... yet they didn't. They modified their parser to be able to pass only specific items to giac for evaluation, and interpret the results back into the existing format.

That's exactly the way to solve the ugliest Prime problems without changing the underlying design.

Quote:One of giac's weaknesses is that it does not have very tight memory control. This is primarily due to it being written from the assumption of having exceptions (which are very often not supported well or buggy on embedded system compilers) and that it will be running on a desktop. It uses tons of small memory allocations and pointers everywhere - the base data structure is quite complicated and it thrashes the memory. Again, this isn't an incorrect decision for a desktop application, but for a limited memory embedded device with potentially questionable OS support it does make problems.

These are facts. Architectures are so different that they have to be essentially two different programs.

Quote:Now if we move on to the wider idea (excluding the technical issues) of building the system around giac, we immediately run into vision conflicts. I am not even going to get into the "business" considerations and concerns a PHB type person might have, but there are *seriously* many of those as well.

That's why TI eventually bought Soft Warehouse, I understand that.

Quote:1. Assume that the system would be built around giac. Exactly what does that mean? (I'd be interested to know that because depending on how you are interpreting that statement we might have much more common ground then you thing) For now, lets assume that all parts of the system use giac for parsing end evaluation.

Not for parsing (see above), but for evaluation. And yes, we're getting close, or at least I'm getting close to your options.

Quote:a) You have just lost the ability to disable parts of the calculator. Giac is a monolithic blob and for many places in the world the calculator now has no future because it can't be controlled in an exam. While nobody here would consider that a problem, not making money on a device is about the quickest way to ensure that device doesn't stay around long.

Many people here don't like this. I get that you have to do this and you're right, you need at least a parser independent from the CAS engine if you want to disable the CAS capabilities.

Quote:b) you now have very slow programs. Giac is a great CAS from a capability point, but it has as a CORE ASSUMPTION that everything is exact and symbolic. Remember how on the 50g you can get radically different times for programs based on approx or exact? Now assume that EVERYTHING will always be exact first and there is basically nothing you can do about it. That is pretty much the situation. Throw on top of that the higher memory requirements, less tight control of loops and recursion, etc.

How did they solve that with the 92/89? My guess is that they are running everything symbolic and the approximate mode/results are something having to do with the APPROX Derive function. That is an option.

Quote:c) high speed graphing is no longer there. It will go much, much slower then the current basically instant graphing.

Agreed.

Quote:d) there can't be any sort of interval based graphing or calculations due to complete incompatibility between a symbolic engine and what is required for interval graphing.

I don't understand this very well, but you'd know better than I.

Quote:e) memory and objects now have a completely flat "session" interface. All calculations and objects are saved into a single flat blob that is only possible to load completely. No folders. No access from outside. (didn't people want folders?) I haven't even gotten to talk about the whole app thing yet and people would already be angry.

As it's been discussed, just porting the Giac code as it is really makes no sense.

Quote:f) any hp designed features are not going to be accepted into the "mainline" because in many cases they aren't desired for the users of a pure symbolic package as a whole. For example, having more then 8 colors. Yes, that is a limit inherent to the underlying data structure. Binary/hex/oct/dec simialr to the 48 series? Not in there. An integer is essentially a different thing and used for a different purpose. Spreadsheet access such as A1:B4 to get a region... not going to be there. What should sin(pi) be equal to? What is the meaning of accurate to n places? These are fundamental question and differences in assumptions that depending on your view can radically alter everything.

Yes, it's a whole new world. I agree, you have to fill whatever is lacking anyway.

Quote:(Yesterday 09:23 AM)Tim Wessman Wrote: So let's assume that we now rework giac/xcas to do everything exactly as we'd like, and to meet our plans. First, you've probably about doubled or tripled the length of development. Second, as stated before a lot of what HP users would like is not going to meld well, or be desired by xcas users or someone like geogebra. So in essence we've just forked it and made something that serves us and nobody else.

That means that all that time and effort ended up with us getting something which would NOT be compatible with the HP calculator vision either past or future, and not compatible with the purely symbolic system that exists, and in short wouldn't have made anything better! The problem just would have shifted to a much more difficult to resolve location.

Yes, but then you end up with a platform of your own, fully under your control, and the next calculator will probably be easier to develop. But if we're talking about just this single calculator I fully agree, it's not worth the trouble and you can get it done without.

Quote:(Yesterday 09:23 AM)Tim Wessman Wrote: Trust me, I do understand why people have said "well just use that cas engine", or "just buy one", or "why didn't you just use the 48 code base". Every single possible direction was considered and analyzed before the decision to move in this technical direction was taken. I am not trying to dismiss what people say, or tell them they are wrong, or make anyone angry. Rather, there WAS no good technical solution that would cleanly work in the first step.

I'm sorry about the abrasive reactions. You know better than anybody else the constraints you have for your product, that's for sure. I don't like people judging lightly the nuances of a tricky situation while having no idea about what's going on either, so I apologise if I've done just that. But there was a lot of BS regarding the HOME/CAS issue. The situation with two unrelated systems in the same device that do not really get along looks a lot like a desperate move to ship something early. When you read CAS.function(), you can tell that you are just calling the Giac library and that's it. Then you press the CAS key, the Giac console just pops out and the first thing you think is "you have to be kidding me". It is a substandard integration, because there is no integration. And then there are these sycophantic pieces that start with "I think that the purpose of the HOME/CAS separation is (amazing juggling skills)" they really wear me out. You have nothing to do with that and you deserve a big kudos for not falling for it.

Quote:(Yesterday 09:23 AM)Tim Wessman Wrote: Prime is doing very well. There are people getting into HP calculators that never have been before. Doors are opening that with a 50g, or a 51g, or a 52g, would never be open. For the vast majority of users who primarily use the calculator to do some math, draw some graphs, and take some tests - this calculator is amazing to them! I've seen people with no interest in math start playing with it, exploring the calculator, and getting excited about MATH! That just does not happen with other calcs in my experience.

I'm glad about it. The Prime can become a great calculator. The Nspires for instance, can't, I'd rather prefer people buying Primes instead. According to your stated intentions to "hide away" Giac it might happen (becoming a great calculator, and more people buying it).

Many folks here don't get that HP has to look more to the TI 89 series than to the 48s if we're talking about getting people to buy school calculators, so I fully agree with your opinion regarding focusing on the 50g series. In any case, I think that HP as a company should consider all those users that have been using RPL for 20 years as well. Unluckily the 48s' system is too tied to a dead processor and emulation is the only feasible path. Sucks, but that's life.

(And now that we're on it, please get a HW1 TI89 just to play with Lars Frederiksen RPN. I can't think of a better introduction to RPN for the masses, it would be very nice having that kind of stack with performed operations/values on this device.)

Quote:(Yesterday 09:23 AM)Tim Wessman Wrote: This isn't a children's game where the first time something wrong happens they throw the pieces away, kick someone, and then run and hide under the bed. (just happened today... )

Just remember that big companies are a lot like big ships. They take a long time to get moving and a long time to turn. Once they are moving though, they either run into a rock and sink, or else are hard to stop.

Let's hope so, I really wish you the best.

Quote:(Yesterday 09:23 AM)Tim Wessman Wrote: End note - it may seem like I was picking on giac/xcas, or Bernard, or whatever. That is not the case. I think that giac has amazing capability. I have seen an impressive array of cases where it will solve something not possible in either casio/ti units, and even in some professional desktop or powerful open source cas systems (eg: maxima).

Yeah, having Parisse around is a golden asset. You should convince him that sometimes having lookup tables is not really a sin, unless you aim for automated theorem proving . Giac's integer and polynomial arithmetic is just impressive.

Quote:(Yesterday 09:23 AM)Tim Wessman Wrote: If I was to sum up the weaknesses, I would say that it makes some simple things more difficult then needed at times, and a lack of polish generated by restricted usage. That can be corrected though by feedback from a wide range of users and sources. Just in the past 6 months as there has been work with both HP and Geogebra I think it has made significant advances and is hugely better then it was before. I am quite confident that it will just continue to improve.

Good luck Tim (and the rest of the team), I know we can be hard to deal with but it is for the greater good.

--

Manolo Sobrino

[Tim Wessman]

Quote: (Yesterday 09:23 AM)Tim Wessman Wrote: (...) Trust me, I do understand why people have said "well just use that cas engine", or "just buy one", or "why didn't you just use the 48 code base". Every single possible direction was considered and analyzed before the decision to move in this technical direction was taken. (...)

(...) Prime is doing very well. There are people getting into HP calculators that never have been before. Doors are opening that with a 50g, or a 51g, or a 52g, would never be open. For the vast majority of users who primarily use the calculator to do some math, draw some graphs, and take some tests - this calculator is amazing to them! I've seen people with no interest in math start playing with it, exploring the calculator, and getting excited about MATH! That just does not happen with other calcs in my experience.

(...) I think that giac has amazing capability. I have seen an impressive array of cases where it will solve something not possible in either casio/ti units, and even in some professional desktop or powerful open source cas systems (eg: maxima).
If I was to sum up the weaknesses, I would say that it makes some simple things more difficult then needed at times, and a lack of polish generated by restricted usage. That can be corrected though by feedback from a wide range of users and sources. Just in the past 6 months as there has been work with both HP and Geogebra I think it has made significant advances and is hugely better then it was before. I am quite confident that it will just continue to improve.

Impressive stuff, Tim.
Thank You for sharing your thoughts and analysis here. Your explanation makes sense to me.

As an old RPN die hard guy (that is one reason why I'm posting in a Museum Forum ), I am using nowadays my HP-Prime much more than my HP-50G, and I'm one of the guys looking into mathematics again!

And I'm not quitting RPN, thanks to the HP-Prime: it is there in Home mode, and I must say it looks to me as powerful and flexible as the classic RPN calculators of the past (yes, I used them quite a lot, and still have a few in my collection).

As for RPL as a programming language, I understand the reasons why so many people here like it, but for me, after spending so many years on my youth coding in very low level languages (from mainframes to micro-controllers, using machine code, assembly, PL/M, you name it), I really prefer to code in a high level structured language that can be easily documented and understood by anyone working with computers - and HP has got one dialect of such kind of languages: it is called HP-PPL.

Lastly, I agree with all the others here about the "issues" and misbehavior found in the Prime: HP should fix it as soon as possible (where possible...), to maintain the customers happy and of course, maintain the high standards of quality that made HP a well established brand in the good old days.
--
Jose Mesquita

[debrouxl]

Very informative, indeed
Nitpick: I think you meant "lex/yacc".

Quote:I don't know why they chose the 68K but it the end they not only had to pick just a subset of Derive, but to rewrite it in C (probably there's a fair amount of assembler there too).

AFAWCT, the amount of pure assembly code in the TI-68k series' OS is relatively small.
Only lower-level stuff (a subset of the startup code, idle code, some interrupt handler / "trap" software interrupt subroutines, subroutines of the self-test code), the BCD floating-point code, several 32-bit / 32-bit division and modulo routines, and probably several other small bits that I'm forgetting about at the moment, are definitely written in ASM, because they use special instructions which can't be produced from C, and/or special calling conventions, or (rarely) special optimization tricks that only human ASM programmers would use.

However, even routines such as memcpy or memset aren't written in assembly: any half-decent human would never produce an optimization blunder that at least one of these routines contains. The higher-level CAS functionality is written in C, with special macros or special compiler support for the decidedly non-C calling convention of the core floating-point subroutine.
One of the most egregious and infamous pessimizations produced by that toolchain is a number of triplets of consecutive identical instructions for swapping two 16-bit halves of the same 32-bit data register.

Quote:How did they solve that with the 92/89? My guess is that they are running everything symbolic and the approximate mode/results are something having to do with the APPROX Derive function. That is an option.

Indeed, unless the user sets approximate mode in the settings, or temporarily forces it with DIAMOND + ENTER, computations are usually done with the symbolic engine when in AUTO or EXACT mode. The symbolic engine occasionally falls back to numeric it it can't deal with something.

[orcinus]

(04-01-2014 07:31 PM)debrouxl Wrote:  Nitpick: I think you meant "lex/yacc".

Someone's been watching too much Lexx

[parisse]

A few remarks
1/ giac is indeed a CAS system designed to work with exact data. That does not mean that it is not suited to work with approx data, and you can check that it is fast for example for approx linear algebra. Being able to deal with exact data has sometimes a small efficiency price, but I'm convinced this is not as important as it was 10 or 20 years ago, since the CPU speed is now fast, even on calcs (and embedded toolchains limitations will most probably be a past inconvenience in a few years). I did not see any speed comparisons between the TI nspire and the HP Prime for example...
2/ I don't think that graphing with giac would be too slow on the Prime (and by the way the number of colors is not limited to 8 on giac, there are 2^16 colors available). But there is an important difference between giac and a calc when graphing: giac does a complete separation between the UI and computation kernel, if you plot something with giac, all data is computed once, then if you zoomout or do any UI change, the display is updated using the already computed data. This could be a problem for calc users used to have the data recomputed. This is not a limitation if you assume that there is a commandline just above the graph, that you can modify easily.
3/ programming in giac is fast enough for a scripting language, if one really needs speed, then a compiled language should be used anyway. It's more important to have an easy to teach language with an easy path from defining an algebraic function to a more complex function with local variables/tests and loops.
4/ giac was not designed to hide the maths. I strongly believe that using a CAS requires that you learn some notions, like what you can solve exactly and numerically (starting with what a floating point number is, and the difference with machine and arbitrary precision integers), or the difference between an expression and a function, etc.. Many math teachers are not comfortable with these notions today, and that's perhaps one reason why calc manufacturers or geogebra want to hide this (for example the expression/functions difference). Of course you can hide some notions for common school tasks, but at some point you must really understand what you do, that's why I think we must teach it.
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 don't believe that Apps are really a good thing to teach. It's much better to teach how to write a commandline to do a plot, with a good dialog box to help you enter the arguments. This is useful for all computational tasks, and in addition you can mix graphs of different kinds on the same graph, something impossible with distincts Apps but sometimes really useful like for example
n:=1000; p:=0.5; m:=mean(binomial,n,p); s:=stddev(binomial,n,p);
N:=100000; histogram( (ranm(N,binomial,n,p).-m)./s,-3,2/s); plot(normald(x),x)
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.

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

[CR Haeger]

Hi Manolo

I believe your example for y:=x definition in CAS may have an error.

Only y appears to become a CAS variable after excecuting this so x is not defined. I'm not surprised at a HOME x throwing an error.

I agree that there are way too many predefined HOME variables (10-26 per type). To me, k-12+ Math would be fully served with say 5 per type. If additional are needed, let the USER create them. If the limit is 5 then Vars/Home could bring up the 5x5 grid of variables which to me would be quicker.

Best
Carl

[Manolo Sobrino]

(04-04-2014 12:06 PM)CR Haeger Wrote:  Hi Manolo

I believe your example for y:=x definition in CAS may have an error.

Only y appears to become a CAS variable after excecuting this so x is not defined. I'm not surprised at a HOME x throwing an error.

Carl

You're right. I was testing several possibilities before writing the post and my Vars menu got populated, maybe I defined x too or maybe it's a case of creeping dyslexia.

Tried it again after purging everything, only y appears as a CAS variable, everything works as I described before (that was what made me think about it in the first place). You can define explicitly x in CAS, and it still works that way. For instance, define (in CAS) x:=r, input x at HOME and it will print r. Now x and y appear in the Vars menu as CAS variables, r doesn't. If you input y you get x again... And if you define x:=1 in CAS, and switch to HOME it'll still print x when you input y. CAS can work with undefined variables, HOME needs defined variables as an input and will use just the definition for evaluation. It would be nice to take advantage of this, so that you could perform calculations involving any new variable without the need to define a dummy one first. Then you could go back and forth to CAS smoothly.

Or, more easily, you could just send your expression involving undefined variables to the CAS (that can handle them) by calling evalf(expression) and print the answer.

[Han]

(04-04-2014 05:17 AM)Manolo Sobrino Wrote:  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.

No, it doesn't. It only knows that y is defined to be x.

Quote:3) input x

Then you get "Error: Syntax Error". Same error as if you hadn't defined y.

As it should. You only defined y as x. You never defined x as anything, so x is undefined. There is a good reason for this behavior. If you use y:=x, and then later issue the command y:=1, it should ONLY change y. Otherwise, you implicitly create a new variable x whose value is 1 if the system were to somehow assume that y and x are now the same.

Quote: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!

And it would not unless 1) you've defined x to be some particular value and 2) you've requested the value of x. In the CAS, if you enter y:=x; and then x:=1; and type enter y by itself, it returns 1 because (as any good CAS would) it understands transitivity. In Home, the behavior is always "face-value" -- you only get what you ask for in the sense that if you want the value of y, it tells you that you that y is defined as x. There are instances where BOTH behaviors are useful. For example, if you need to know whether y is a symbolic variable or a numerical variable, having y return only x is useful. In the CAS, TYPE(y) and TYPE(x) would both return 0 if you type y:=x; and x:=1; and the same holds even if you use the CAS-specific lower-case form type(y) and type(x).

Quote: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.

Yes, provided that x and y were created/defined in CAS.

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

You could do this with any variable; perhaps I am misunderstanding something...

Quote: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??)

I agree with the consistency remark. I disagree that just because project XYZ does it that it is suddenly ok. Mathematica uses non-standard notation for functions. How many textbooks do you see use f[x] ? The typical notation is f(x). Now, what about x(t+1) -- should that be a function of x in terms of a parameter t? Or should we interpret that as a product of two expressions x and t+1 ? This is why there is no * in the second case. There is a reason for wanting explicit notation so that we can avoid instances of ambiguity. No CAS will be able to magically guess when a(b) should be multiplication and not functional notation.

[Manolo Sobrino]

(04-04-2014 09:06 PM)Han Wrote:  No, it doesn't. It only knows that y is defined to be x.

Now we are nitpicking, well, it knows that y <- x, (what is exactly the type of the answer? Is it a text string?)

(04-04-2014 09:06 PM)Han Wrote:  

Quote:3) input x

Then you get "Error: Syntax Error". Same error as if you hadn't defined y.

As it should. You only defined y as x. You never defined x as anything, so x is undefined. There is a good reason for this behavior. If you use y:=x, and then later issue the command y:=1, it should ONLY change y. Otherwise, you implicitly create a new variable x whose value is 1 if the system were to somehow assume that y and x are now the same.

That's my whole point, it would be nice that it knew what to do with undefined variables. If you input x in Mathematica, Giac/Xcas, Derive, the competition... you get a printed x. (Reduce is nicer, it asks you whether you want to define an operator Y/N. If you say no it prints x, if you say yes, it's x(x) ). I know the idea is keeping an independent numerical environment, but having the capability to work with undefined variables (or being able to deal with defined symbolic variables without having to evaluate them) is a must if you want a seamless integration with a CAS... but YMMV. As I said, I think that you can get that functionality if you parse any expression with undefined variables and send it to the CAS/call evalf(), and then print results.

(04-04-2014 09:06 PM)Han Wrote:  I agree with the consistency remark. I disagree that just because project XYZ does it that it is suddenly ok. Mathematica uses non-standard notation for functions. How many textbooks do you see use f[x] ? The typical notation is f(x). Now, what about x(t+1) -- should that be a function of x in terms of a parameter t? Or should we interpret that as a product of two expressions x and t+1 ? This is why there is no * in the second case. There is a reason for wanting explicit notation so that we can avoid instances of ambiguity. No CAS will be able to magically guess when a(b) should be multiplication and not functional notation.

I was just giving an example of a CAS that has implied multiplication. They went for brackets for function values, and that is a great thing for consistency, because using parentheses is just a typographic ambiguity that context resolves, even when they are used for wildly different things. When you give instructions to a computer it is a very good idea to establish the set of arguments of a function with a different syntax than that of a vector, an open interval, or a particular order of operations.

As I said, I think it's a personal choice. IMO it's just that most people are used to environments that understand both 2(1+2) and 2*(1+2), it's no big deal really.

[orcinus]

(04-05-2014 03:34 AM)Manolo Sobrino Wrote:  Now we are nitpicking, well, it knows that y <- x, (what is exactly the type of the answer? Is it a text string?)

An algebraic expression, i believe (i.e. y := 'x').
It doesn't care what that x is nor if it exists. That becomes important only when y gets evaluated.

I might be completely off on this, but this is how i'd expect it to behave.

[Han]

(04-05-2014 03:34 AM)Manolo Sobrino Wrote:  

(04-04-2014 09:06 PM)Han Wrote:  No, it doesn't. It only knows that y is defined to be x.

Now we are nitpicking, well, it knows that y <- x, (what is exactly the type of the answer? Is it a text string?)

Actually, it is not nitpicking when you think about it in terms of programming. Let's just say that when you type y:=x; that the system automatically treats y and x identically. What happens, then, when you want to only change y, and not x? If you change y to a value of 1, then because y and x are now identical (since y is "the same" as x now), x becomes 1 as well -- which is undesirable in many cases. In other words, there one must purge x (and/or y) before changing the value of y. The type depends on whether you use TYPE or type.

Quote:I was just giving an example of a CAS that has implied multiplication. They went for brackets for function values, and that is a great thing for consistency, because using parentheses is just a typographic ambiguity that context resolves, even when they are used for wildly different things. When you give instructions to a computer it is a very good idea to establish the set of arguments of a function with a different syntax than that of a vector, an open interval, or a particular order of operations.

As I said, I think it's a personal choice. IMO it's just that most people are used to environments that understand both 2(1+2) and 2*(1+2), it's no big deal really.

The bracket notation is inconsistent with many other languages/CAS in which a[i] refers to the i-th entry of a vector. The point is that we as humans are completely capable of deciding whether a(i) refers to the i-th entry of a list or vector, a function named a whose input variable is i, or the product of a and i -- merely based on context clues. Even so, someone just learning about functions might not necessarily see the difference so clearly. What you are asking for is a CAS that is able to infer as well as a human -- not an easy order to fill. Maple, for example, does not allow implicit multiplication. Sure, when the operands are pure numbers it may be apparent. However, once you allow it for numbers people will naturally wonder about variables. As a simple example, is xy the variable named xy, or is that a product?

[Manolo Sobrino]

(04-05-2014 08:56 PM)Han Wrote:  The bracket notation is inconsistent with many other languages/CAS in which a[ i ] refers to the i-th entry of a vector. The point is that we as humans are completely capable of deciding whether a(i) refers to the i-th entry of a list or vector, a function named a whose input variable is i, or the product of a and i -- merely based on context clues. Even so, someone just learning about functions might not necessarily see the difference so clearly. What you are asking for is a CAS that is able to infer as well as a human -- not an easy order to fill. Maple, for example, does not allow implicit multiplication. Sure, when the operands are pure numbers it may be apparent. However, once you allow it for numbers people will naturally wonder about variables. As a simple example, is xy the variable named xy, or is that a product?

Well, you could use braces {}, as in LaTeX. S. Wolfram made his own choice:

http://reference.wolfram.com/mathematica...ectly.html

• parentheses: ( ), precedence
• brackets: [ ], set of arguments
• braces: { }, lists
  

It is consistent, logical, works and people like it once they get it. I don't have a use for Maple (nor an institutional license). I could argue strongly in favour of the Mathematica approach, the point of it is not really about implied multiplication... But then Mathematica has no awkward additional rules due to having to keep the function parentheses notation while using implied multiplication. Nice side effect .

It's too late to change the parentheses notation for functions (and nobody cares). Too bad, in my experience, the less typographical ambiguities we follow when teaching maths, the less hurdles for the student to truly understand them... Concepts should be distinctly introduced: try to ask the regular student why we write f(x) instead of f in a particular case.

As many systems with implied multiplication have sensible rules for variable names: any (practical) number of consecutive (not too weird) characters will do, just the first one can't be a number, there is no ambiguity:

• xy is the variable xy
• 2xy is just 2*xy
  

In Mathematica: x*y, x(y), (x)y and x y (space) are parsed as x y.


In Derive you have to define previously a function, say f, in order to have every instance of f(z) being understood as the value of function f for argument z. Then you have that f(z) is parsed as f(z), and you obviously can't use f without it's argument any more. If you did not define f before, f(z) is parsed as f·z, and (z)f as z·f. I think this approach makes sense. You can even define x(x):=x, if then you simplify x(y) you get y, if you simplify x(x) now, of course you get a "Syntax Error: Unexpected delimiter" as every x is a function and needs its arguments: x(x(y)) gets you y and so on.

Yet Derive has its own quirks. If you input xy it will print x·y. It takes to "define" xy as an unassigned variable: xy:= . After this, if you input 2xy it will print 2·xy, and if you input xy2 it'll print xy·2.

That IMHO, is a nice implementation that keeps the polysemous parentheses.

In the particular case I quoted, x(1+x) is parsed by Giac/Xcas 1.1.0 as x*(x+1) after a warning. It behaves the same way as, for instance, 2(1+x) ->/warning/-> 2*(x+1). While (1+x)2 results in a syntax error. But, in general, Giac/Xcas will understand that f(z) is a function f with argument z, so: y(1+x) is parsed as y(x+1). Maybe x(1+x) would be a recursive function or Giac thinks that things might go awry eventually (we'll see something like that in a moment), so I guess that Giac assumes that you'd better be multiplying it .

The TI 89 CAS is a simplified Derive. If you input 2xy it will print 2·xy. Now xy is just a token, as the undefined x was for Derive. x(y) is just a token too, it will print x(y), but interestingly x(x) gives you an error: "invalid implied multiply". I guess they thought that you might use that expression to define a function and you could run into trouble (that Derive syntax error), or they might want to protect your brain. Of course (x)y will print x·y.

And then, there are interesting mixed bags. Reduce has no implied multiplication, but performs happily arithmetic implied multiplication. That's cute, why not?

I see no strong arguments against or in favour of implied multiplication when it's well done. Both do the job. I find it convenient because I type less and obviously the operator is always there.

(04-05-2014 08:56 PM)Han Wrote:  The type depends on whether you use TYPE or type.

About the type... After defining CAS variables made out of gibberish, when the CAS variable is not a number etc, it's just whatever Giac will tokenize. Maybe I can make my point better: If the evaluation of a CAS variable gives you a CAS token in the numerical environment which you have no use for and you're happy with it, why don't tokenize in the numerical environment to begin with? Just treat any undefined variable (in the eyes of the unsuspecting user) with proper syntax as a token and don't evaluate it. If you can't do that, you could ask the CAS to do it, it's its job!

There's one thing that a new user understands less than getting x after typing x, and is getting "Error: Syntax Error". It will be impossible to hide Giac if you can't get 1.4142*x after entering sqrt(2)*x. (Just go and type sqrt(2)*y at HOME, or approx(sqrt(2)*x) at CAS, that's what the competition gets when they run in APPROX mode.)

As always, YMMV.