03-31-2014, 06:55 PM
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.
================================
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.
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.
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.