CAS command question

[DrD]

Indeed, your points are all well taken. In spite of my insistence that the CAS commands, on which this thread is built, are incomplete, I, very much, appreciate and respect your differing opinion.

I am not sure that there is a strict definition of CAS, i.e, Computer Algebra System, to the extent of this topic. HP prime CAS includes the commands left() and right(), and it both alludes to, and is comparable to, similar commands in other Computer Math Systems, as noted earlier. You have pointed out that Giac has been extended to strings, and that point is crucial. These commands NEED to be extended to strings, because academia needs a way to input relations as objects, and be able to separate the relations' expressions, in order to further process them. CAS commands like coeff(), and Home commands like EXPR(), require expression arguments. Many external tools exist, so, sure, programmer's can use other products, custom-designed, or self-written; but that's not the point.

The problem in need of a solution, is that hp prime needs better facilities for handling function objects as string objects. The difference being evaluation, or not. The arguments, pro and con, are within this thread, and the outcome is not satisfactory: requiring hp prime customers to bridge this divide by self-written programming techniques. The prime, as designed for educators/students, should not, (necessarily), require experienced tailors to be able to stitch around it's incompatibilities.

We are at, if Mr. Trump will please excuse the analogy, the "wall." You seem to share the ex-president of Mexico's opinion, and, well ... I don't. Unfortunately, I'm just a customer ... and I have purchased only a few HP devices. My scant whisper is as a tree falls in the forest with no one around, not to be melodramatic; no, not me...

[parisse]

The CAS is coherent with itself, incompatibilites happens between HOME and CAS, and I'm afraid they can never totally disappear because the logic behind is not the same.
Programming with strings should only be used as a last resort solution, it's much more efficient to program with expressions (after having learned the minimum about how a CAS works, i.e. expression structure and evaluation).
You should explain what you mean with your wall comparison for those like me who are not from the US (or Mexico) and don't understand what you mean.

[DrD]

(01-09-2017 04:43 PM)parisse Wrote:  You should explain what you mean with your wall comparison for those like me who are not from the US (or Mexico) and don't understand what you mean.

Briefly, you are convinced that these commands should return CAS mandated, "evaluated" results, regardless of the original, [Help] constrained relation. I am convinced that they should return the "called for" side of the original relation, without evaluation, without inequality constraint. Our difference of opinion is similar to an imaginary "wall," and, convincingly, you have made your decision not make this change; metaphorically, though somewhat less emphatically, as former Mexican President Vicente Fox, when he states that he is not interested in making any changes, either ...

I prefer not to have an "evaluated" result of right(), for example, cross over, and change what's really right to whatever is ... left.

[parisse]

But it's not about conviction! Believe me, if I could make an easy change in the source code, I would already have made it, because it would take much less time than explaining things (again and again) on this forum!
But I can't modify the intrinsic logic of Giac : eval an expression means eval arguments then eval the command. I can not make a small change inside the left and right source code because once this source code is reached the arguments are already evaled. This was the reason I made a comparison with RPN: what you ask for left/right is like asking a+b to work in RPN without quotes. If you accept that it's impossible for RPN why wouldn't you accept the same here?

[Han]

What you are asking for, and perhaps you do not realize it due to continued requests for changes to left() / right() or even the creation of lhs() and rhs(), is a change in the design of the parser. The issue is not with the commands, but how the parser was designed and implemented. That is, the parser evaluates the arguments and then passes it to the commands. As parisse has already mentioned, by the time the arguments reach the actual code for left() and right(), the expression is already transformed. That is why modification to left() and right() will unlikely amount to anything fruitful. Moreover, these commands already work even as you intended them to work (i.e. like lhs and rhs) in the cases when the argument provided is in the "correct" form (i.e. unchanged).

What you probably want instead is a means for programmatically passing expressions unevaluated. A quoted expression is evaluated into its unquoted form all while keeping the form of the expression unchanged. Keeping expressions unchanged can be done by hand using single quotes (somewhat), but even then it's an evaluation as there are two types of expressions: quoted, and unquoted (the former is evaluated into the latter). However, there currently is no mechanism for passing arguments that forever remain "unchanged" except as a string. As far as what is required to make this happens, I do not know. There was mention of exception handling being a pre-requisite. And if so, that makes it unlikely since the underlying system OS (on top of which the Prime OS is built) does not have exception handling. Even lhs() and rhs() were added in the manner you want, I am sure that later on down the road there will be additional commands that you would want that need to operate on unchanged input.

Keep in mind, also, that no CAS is going to be the CAS to "rule them all" -- that is why there are so many of them (Maple, Maxima, MuPad, Mathcad, Mathematica, Derive, etc.) They all have their own idiosyncrasies -- one system might be better than another in one feature, and vice versa in another (also true in terms of their design). Yet every single one of them provides a mechanism for expanding its capabilities -- namely through programming. In your specific case, the amount of programming necessary to add lhs() and rhs() using the provided programming environment is quite minimal and does not require a complete re-design of the CAS, nor would it break other components because left() and right() do not have to be modified internally.

[DrD]

Han,

To be clear, I have made only one request, and offered one alternative, not multiple requests. The rest of this thread was trying build support for the idea, by responding to the various 'can't be done' spot issues that have followed.

Lets start with the "Dale doesn't understand how CAS works," and try to find where I fall off the train:

1. It is asserted that the CAS front end starts out by evaluation:

Quote: The issue is not with the commands, but how the parser was designed and implemented. That is, the parser evaluates the arguments and then passes it to the commands. As parisse has already mentioned, by the time the arguments reach the actual code for left() and right(), the expression is already transformed

.

Where does the parser get something to parse? I assert that the first process is an I/O step, and nothing is known about the information, other than it will be passed on to additional processes. This could be an entry point to return "dry" processed commands. Before any further "Wet" processing, which would include any conditioning of the resulting inputs to CAS, or HOME or etc., such as evaluation. DO IT BEFORE EVALUATION. If the parser is hard-coded in ROM, and no way can you intercept the incoming keystrokes, or the keystroke buffers, or the flushed buffer output, then make sure the data is captured as TYPE(2) data.

2. From the very first explanation, where it was explained "Why" and "How" things are done in CAS, I totally got it. "That's the way it's always been done." Okay, change isn't always easy ... just not impossible.

3. This is a bit troubling:

Quote:However, there currently is no mechanism for passing arguments that forever remain "unchanged" except as a string. As far as what is required to make this happens, I do not know.

Strings are a completely viable way to, "make this happen." Everything needed is present in the string. For example, lhs() would see the string object, search for the relational operators, and return everything from the first character to just before the first operator. No, a user should not have to write that routine. Especially if the product is targeted for a specific educational market. That should just be an intrinsic command, like other program statements. No one is asking for the be-all end-all CAS system, but we have referenced several other CAS and Math systems that DO have this feature. Even better, they return the corresponding result, without the reversal of sides being visible on output. This isn't altogether unlike the properly operating LEFT() and RIGHT() commands, in Home, for strings.

3. I have tried to be clear to say what I thought should happen. What I don't want, to be equally clear, is that a user need to be forewarned that the results don't always represent what the command says, or that certain additional characters must be carefully inserted in the string, before it has ANY chance to work, or any other superfluous steps. Here's an example of why: If a student is sent an example to solve, the student should be able to copy/paste the example into a requesting INPUT field, be it the command line, or a program. Likewise for the virtual calculator. Currently, I can copy and paste example problems found on the internet into an optimality program I have created for the purpose. Because a lot of the examples use implicit multiplication, and because of the inequalities in play, I naturally had to include a lot of additional program steps to facilitate other CAS commands. The upshot of that was largely because other needed CAS commands needed the expressions, as opposed to the entire relation. It's not about the extra steps, it's not about the variations of how to do it, it's not about CAS and the underlying limitations of xcas, giac, and consequently the prime. The issue of this topic is that CAS does poorly on the left right implementation.

In summary, I have not been successful in trying to help improve the CAS and the prime, but I have tried. We can let the topic go ... we've about said it all, in a variety of ways, and the take away is that we must live with the status quo, because the vendors are not able to change the behavior. That's ok, at least they aren't silent on the matter. If this were downright important, better suited products, i.e., CAS's exist, so this issue is pretty minor, especially at this stalemate point. I don't want to cause further aggravation, or frustration and I haven't heard anything that makes me want to change my thinking on this issue. It's probably just me, and a few others, so there just isn't anything more I can offer.

I hope you are having good weather, it's cold here, not to suggest we change the subject...

[Han]

For parisse: can you shed some light on how programs are executed (i.e. how does the CAS runstream behave) and in particular with respect to argument checking/processing?

[parisse]

Programs are symbolic expressions of root node 'program' with 3 arguments: the arguments, the arguments*0 (not used currently), and a (list of) expressions to be executed. During evaluation, a local context is created where the arguments variable names are assigned to the arguments variables values and the list of expression is executed.

The general scheme for any CAS is : input is a whole string, parse it into a CAS expression, eval it from top rootnode recursively. There is no I/O from the CAS point of view, the computing kernel is completely separated from user interaction.

I disagree with DrD with the fact that in an educatonial environment, we should make softwares available that exactly support the syntax of textbook problems, students are not robots, we should explain students the logic behind so that they can adapt to any kind of software later. In a professional environment, it's different and being able to copy/paste without user intervention is desirable. The additional work will be done by a programmer that should take the time to understand how the software works, I have shown code slices in this thread which demonstrate how left/right can be used to extract the relevant information with more freedom for the user and more control on the syntax than with strings. Using strings instead of symbolic expressions shoud not be the normal choice because strings have no structure, and calling the parser is inefficient. But I have nothing against improving left and right for strings arguments if DrD really prefers to program with strings.

[DrD]

(01-10-2017 07:58 AM)parisse Wrote:  Using strings instead of symbolic expressions shoud not be the normal choice because strings have no structure, and calling the parser is inefficient. But I have nothing against improving left and right for strings arguments if DrD really prefers to program with strings.

1. How does the "CAS" interface with the hardware architecture? Before (Parisse), can interact with the hp prime hardware, has the hardware architecture already evaluated the keystrokes, and (Parisse), isn't able to see unevaluated data? This would make the whole discussion a different matter, because this would be a hardware constraint, and nothing to do with CAS firmware. IF that is the case, I totally, understand, and withdraw my complaints. Maybe you just can't implement these features, due to hardware limitations. While Parisse and Han have said that my lack of understanding of how CAS works is the problem, nothing has been said that reveals why CAS can't do this.

2. The INPUT() command can handle various types of objects. It so happens, that TYPE(8), Function Objects, get evaluated before users get a chance to work with them directly. Therefore TYPE(2), String Objects, are the ONLY way to access unevaluated content. It's not that DrD wants to work with strings, per se.

3. I haven't been living in a cave, though. I have computer science coursework, and vocational experience in the design of M6800 processor computer systems, in my early background. Prior to recent retirement, I have been on the diagnostic side, (maintenance and repair) of some pretty sophisticated systems. Most recently, I played a role in the development of a SCADA based telemetry system, using microwave, VHF and UHF data radio, and 2w/4w landline communications, in the natural gas industry. This includes state-of-the-art PLC systems from more than one manufacturer. So if willing and you want to get a little more technical, I'll try to improve my understanding of the CAS inner workings, to better understand why the simplistic idea of left is left, and right is right can't work in this product. If you were to say something like, "It's a hardware issue." or "CAS firmware cannot access unevaluated data." I understand.

4. Another topic altogether:

Quote:I disagree with DrD with the fact that in an educatonial environment, we should make softwares available that exactly support the syntax of textbook problems, students are not robots, we should explain students the logic behind so that they can adapt to any kind of software later. In a professional environment, it's different and being able to copy/paste without user intervention is desirable. The additional work will be done by a programmer that should take the time to understand how the software works

Students exist at every level of the educational process. At higher levels, the prime is very useful to expedite problem solving, to help students learn more about the process than specific results. The student has spent a fortune trying to get the underlying education, and the tool, should not be something requiring much diversion from the fundamental educational goal. Simpler is better. Newer products will most likely be available before the student gets grey hair, so existing tools are transients. Becoming intimately familiar with the tools inner complexities, should not be a bigger problem than the problem the tool is designed to solve. If you disagree, then I do too.

Bringing this back to the topic under discussion, using strings at the user interface, gets us past all of these concerns. String handling in the prime could be improved ...

(If we were to meet and discuss these details, one on one, I bet that we really don't disagree as much as this post seems to indicate. I admit I don't have all the answers, I don't even know how to ask most of the questions!)

-Dale-

[Han]

On "why the CAS cannot do this."

By "parser" I mean the bit of code that handles how parameters are passed onto commands. I am not referring to the code that handles direct user input via key presses (which basically checks for proper syntax) or even the one that compiles a written program (again, this is just another syntax checker). During runtime, when a command is executed at the command line, or when the same command is encountered within a program (after all user interaction and relevant I/O have been completed, up to the point where the runstream encounters this command), some bit of code must go through the collection of all the parameters and "parse" them to ensure that 1) they are the correct type and 2) that they are encoded into a form that can be manipulated by the command. This is what I mean "parser" and (though I may be mistaken) this is also where the evaluation probably occurs. This could simply be a subroutine that all CAS commands call prior to actually executing their own code. My understanding, based on what parisse has written, is that these argument checks and object encodings are done external to each individual command.

Quote:(If we were to meet and discuss these details, one on one, I bet that we really don't disagree as much as this post seems to indicate.

Yes, very much so.

[parisse]

DrD: The CAS does not interact with hardware, and it shouldn't because that is not portable at all. As explained before, the CAS can parse a string to it's own internal data structures for representation of int, float, expressions, lists, operators, etc (a C structure named giac::gen for giac). This is what is called the parser (and it's not what Han calls parsing), more precisely this is a two phases step: the lexer finds words in the commandline and the parser applies grammar rules to build an expression. The CAS can also print it's internal data structures to strings. Strings are only used for communication with the outside world, everything else is done with giac::gen (and derivatives).
This is not limited to CAS, interpreters work the same way (CAS being special because variable may stay unassigned in expressions): when you type Enter after a commandline, the interpreter parses a string to an object, eval the object, print the result of evaluation (CAS programs are themselves expressions, they are eval-ed by exactly the same process). It's a fundemental CS concept, and that's why it should be teached to students for the same reason that writing a correct commandline, understanding priorities, parenthesis, etc. is universal and should be teached to students. Otherwise you will have users that are tighted to the only software they learned at school, because they did not learn the fundemental concepts that will make switching for them easy (and that's precisely what the big software companies want).

[compsystems]

For me the problem LEFT RIGHT is only visual, of course I would like it not to rewrite it to simplify.

The following code, shows that it does not matter the rewriting of the original expression, if you consider the operator.

expr0 := expr(string( simplify(left(expr0) )) + part(expr0,0) + string( simplify( right(expr0) ) ));

PHP Code:

testInequality2():=
    begin
     local expr0;
     print;

     expr0 := '(3*x^2-2*x-2) < (2*x^2-3*x+4)';
     //expr0 :=  (3*x^2-2*x-2) < (2*x^2-3*x+4);
     print("step1:");
     print(string(expr0)); 
     print("");

     print("step2: +(-2*x^2)");
     expr0 := expr0 + -2*x^2; 
     print(string(expr0));
     print("");

     print("step3: +(3*x)");
     expr0 := expr0 + 3*x;
     print(string(expr0)); 
     print("");

     print("step4: +(-4)");
     expr0 := expr0 + -4;
     print(string(expr0)); 

     print("");
  
     print("simplify → ");
     //expr0 := simplify(expr0);
     expr0 := string( simplify(left(expr0) )) + part(expr0,0) + string( simplify( right(expr0) ) );
     print(string(expr0));  
     print("");
        
     return expr(expr0);            
   
    end; 


the output is correct: 0>(x^2+x-6)

[Han]

(01-10-2017 06:58 PM)parisse Wrote:  DrD: The CAS does not interact with hardware, and it shouldn't because that is not portable at all. As explained before, the CAS can parse a string to it's own internal data structures for representation of int, float, expressions, lists, operators, etc (a C structure named giac::gen for giac). This is what is called the parser (and it's not what Han calls parsing), more precisely this is a two phases step: the lexer finds words in the commandline and the parser applies grammar rules to build an expression. The CAS can also print it's internal data structures to strings. Strings are only used for communication with the outside world, everything else is done with giac::gen (and derivatives).

I am genuinely interested in furthering my understanding GIAC. From my own point of view, it appears that my understanding of parsing and how you just explained it differs essentially only in the timing, i.e. when the action occurs (prior to runtime vs during) and not what the action does. In other words, the end result is that the parameters (input) that are being passed to a command must be encoded in some way (namely has giac::<blah> via the grammar you describe) before the content of the command itself is executed. Is this not correct? (And do the grammar rules presumably check for syntax as well? Or is that separate?)

Any further enlightenment you could provide would be greatly appreciated.

[parisse]

I'm really not an expert in the process of parsing. I'm using flex and bison to do that, you can refer to their documentation for much better explanation. In short, the C++ code output from flex reads the strings and cut it into words with a token value according to the rules in the file input_lexer.ll from giac source code (for example "(" has token value T_BEGIN_PAR). Then the C++ code output from bison translate the string into a giac::gen expression by grouping tokens according to the grammar in the file input_parser.yy. During that step, nothing is evaluated.
If you write a program from commandline, for example "f(x):=x^2;", it is parsed to the gen expression f:=x->x^2, then evaled, evaluation stores the expression x->x^2 (of rootnode 'program') into the variable f. After that if you write from commandline "f(a+1)" it is parsed to the giac::gen of(f,a+1), an expression of rootnode 'of' (the command to eval user programs), then it is evaled. During evaluation if a is assigned, it is replaced by the value of a, then + is done, f is replaced by x->x^2, 'program' is called, the argument x is replaced by a+1 (or the value of a+1), x^2 is executed and it returns (a+1)^2. You can see these steps in action with gdb if you compile the native version of giac.

[DrD]

(01-11-2017 06:46 AM)parisse Wrote:  I'm really not an expert in the process of parsing. I'm using flex and bison to do that, you can refer to their documentation for much better explanation. In short, the C++ code output from flex reads the strings and cut it into words with a token value according to the rules in the file input_lexer.ll from giac source code (for example "(" has token value T_BEGIN_PAR). Then the C++ code output from bison translate the string into a giac::gen expression by grouping tokens according to the grammar in the file input_parser.yy. During that step, nothing is evaluated.

The quote describes the point I have been driving at: -If- you can get at the content from the input_lexer.ll, and before hitting the input_parser.yy (before any evaluation step), it seems like new lhs and rhs commands could be implemented using that content, without reordering the expressions. This would leave existing CAS left() and right() commands to remain in legacy status, (evaluated first).

ARGUMENT FOR new lhs and rhs commands: Other commands require an Expression, and conditionally reversing the expressions conflicts programs that directly flow from the existing left(), right(), commands, as result might become reversed. (Examples: coeff(), symb2poly(), LNAME(); etc.)

ARGUMENT AGAINST: Legacy, "always done it that way," means that CAS requires evaluation, resulting in "<" reversing expression order, and the user expectations might be affected.

Is it at the input_parser.yy where content gets evaluated? If not, then perhaps the content could be obtained there, etc.; and this is why I have remained so determined on this issue.

[Regarding reversing of expressions]:
I haven't found any authoritative citation that makes reordering expressions containing "<," anything close to a "natural order." (I understand the process and equivalence of the reordered result). I'm not an expert in this field, but most references I have found, have more to do with programming languages, than actual algebraic lexicon. For example, x<4, places the "subject" before the "predicate" which seems more natural to me, than 4>x. However, programming languages might be a little clearer with a constant on the left side, mainly to clarify that nothing is being "assigned" to the constant 4; perhaps, as used in an IF THEN ELSE type of construct.

[parisse]

DrD, I think you are still confused. The parser steps returns the expression as is (unevaluated) but that does not change the CAS logic: you need to eval the expression otherwise nothing happens and you would get left(x>2) returned when you type left(x>2) (exactly like if you enter quote(left(x>2))).
I don't understand why it's so important for you to keep the ordering, since I have explained how you can program the same functionnality whatever the order is. In fact it's even better because the resulting program is more general.

[Han]

(01-11-2017 06:46 AM)parisse Wrote:  I'm really not an expert in the process of parsing. I'm using flex and bison to do that, you can refer to their documentation for much better explanation. In short, the C++ code output from flex reads the strings and cut it into words with a token value according to the rules in the file input_lexer.ll from giac source code (for example "(" has token value T_BEGIN_PAR). Then the C++ code output from bison translate the string into a giac::gen expression by grouping tokens according to the grammar in the file input_parser.yy. During that step, nothing is evaluated.
If you write a program from commandline, for example "f(x):=x^2;", it is parsed to the gen expression f:=x->x^2, then evaled, evaluation stores the expression x->x^2 (of rootnode 'program') into the variable f. After that if you write from commandline "f(a+1)" it is parsed to the giac::gen of(f,a+1), an expression of rootnode 'of' (the command to eval user programs), then it is evaled. During evaluation if a is assigned, it is replaced by the value of a, then + is done, f is replaced by x->x^2, 'program' is called, the argument x is replaced by a+1 (or the value of a+1), x^2 is executed and it returns (a+1)^2. You can see these steps in action with gdb if you compile the native version of giac.

Ok, I get it now. Thank you for the explanation.

[DrD]

Parisse,

1.

Quote:I have explained how you can program the same functionnality whatever the order is. In fact it's even better because the resulting program is more general.

We seem to find agreement here: It takes an EXTERNAL program like you describe, because the CAS left() and CAS right() commands are INCOMPATIBLE with other CAS commands that use an EXPRESSION as an argument, due to the INCONSISTENT CAS evaluated result, in order to provide a more "general functionality".

2.

Quote:I don't understand why it's so important for you to keep the ordering

The reason why it is important is that other ppl commands require an expression as an argument. The CAS left() and right() commands are available to separate the expressions, but they, inconsistently, return their namesake. Han, and I have suggested that new commands: lhs() and rhs(), could be designed to return the left and right side expressions, to avoid the need for extra programing requirements to overcome this shortcoming.

3.

Quote:the CAS logic: you need to eval the expression

This argument is illogical, for this kind of CAS command. The [Help] topic omits inequalities, yet the commands still process them, just poorly. Arno K has explained in pure logic that left is left, and right is right. There is a certain beauty in that statement, and I totally get what he is saying there.

4.

Quote:The parser steps returns the expression as is (unevaluated)

Use the force: This return content could be used for new lhs() and rhs() commands, to keep something like x<4, from becoming 4>x, and lhs(x<4); would become x, and rhs(x<4); would become 4. Students wouldn't need EXTERNAL programs, (or techniques), to overcome the dyslexic CAS left() and right() expressions. Only then would other hppl commands be able to work, homogeneously, with them.

5.

Quote:DrD, I think you are still confused

Agreed. I mentioned earlier that we probably agree on many more things than this post seems to suggest ...

I'm going to suggest again that this is a bug. I'll respect that you don't understand, and that you probably won't, or can't change; or won't, or can't implement, the suggested new commands. Use of left() and right() commands may cause other CAS commands, (requiring an expression), and programs containing them, to fail. How would YOU define the term, "bug?"

[Arno K]

DrD,
I totally agree too each of your last comments.
Arno

[parisse]

It seems to me that you (DrD and ArnoK) are so certain to be right that you just don't try to understand what I explain, therefore I'm afraid that my only option is now to ignore your posts. I just hope that my explanations will help other users, understanding CAS evaluation is not that complicated and once you understand that you can do (much) more with your Prime.