CAS command question

[DrD]

Parisse,

I hope you won't ignore this last post, because I want to express my gratitude that you have taken your valuable time and energy, to hear and respond to my concern. I certainly understand your feelings, and don't blame you for wanting to ignore my future posts.

As you know, consensus isn't guaranteed, and sometimes different opinions, values, and approaches vary. I have tried to make my case, and you have tried to make yours. Thank you for the debate. This is only a one-issue thing, as far as I am concerned. I value your greater insight, experience, and wisdom in the field of mathematics. I won't blame you for ignoring me, but rest assured, I will be looking forward to your contributions to others in this fine community. I hope you won't let this debate preclude others from the gains of your contributions.

Respectfully,

-Dale-

[Arno K]

Dear Mr. Parisse,
as you can easily find out I kept myself away from this discussion as far as possible, especially after your first answer to my first comment I did not want to continue that.
I know that I sometimes am not as kind as the situation may require and Dale explained what I thought to be my point of view quite clear.
Here I see a discussion between people who a very concerned of their opinion, not to say stubbornly convinced, which will lead to no good end if continued so for me it seems better to stop that now.

Arno

[parisse]

I'm not expressing opinions, but facts: it's technically impossible to modify left and right to do what you would like because the real reason is evaluation of < and <=. For the same reason numer(4/6) will return 2 because 4/6 is evaled to 2/3 before numer is called. Of course it's not impossible to make left and right return what you would like, but that require reviewing everything in the CAS that handle inequations and certainly rewrite parts, a long and bugprone task that would probably impact normal users. Therefore I won't do it, because it's very easy to handle for a programmer as demonstrated above.

[DrD]

Quote:Of course it's not impossible to make left and right return what you would like, but that require reviewing everything in the CAS that handle inequations and certainly rewrite parts, a long and bugprone task that would probably impact normal users. Therefore I won't do it

Well, now ... Parisse' post is completely understandable and adequately addresses my original concern! There's a huge difference between the consequences of changing the existing behavior, and CAS systems not being able to do it. That was the point of my frustration. My PC's keyboard would have been relieved to have had this explanation a long time ago! So CAS left() and right() commands are not well suited for general use, and for good reason.

Now, can we dispose of this: I wonder if there is an equally justifiable reason to not build the two completely general commands lhs() and rhs()? This would go such a long way towards making the whole CAS system compatible, insofar as other CAS (and HOME comands) are concerned, that it practically screams for attention. Ideally, being able to use commands, without external intervention, is the overall goal.

There would be side benefits, also. For example, as hp prime customers use the programming language, let's say that lhs() and rhs() reveal still other commands in which inequalities don't work. The existing, less general, commands can handle those cases, until developers can explore the inner working, possibly making tweaks for accommodation of the new lhs() etc., commands. Once the evolutionary process converges, those less general commands will become obsolete, and CAS will be streamlined; making the "long and bugprone" task less so, resulting in a much better HP product.

A suitable answer that would be understandable, might be that, "CAS is a finished product, and no further extension will be forthcoming." I can understand that new commands are enhancements, and *might* appear in a future product, so FOR NOW the only solution is external programming, or more corporately, "that due to time constraints, the best that can be done is put the request on the 'list'," (even if there isn't one), and so forth.

Just in case this post is being ignored, I will say that Parisse has a very excellent CAS system, even if nothing else get done. I'm only struggling to try to make it better. If the many commands that require an expression, ALL find a dependable way to get their required expressions, from ANY source relation, CAS will be very much improved, in general.

Oh ... one last thing: What the hell is a "normal" user? The closest thing to normal I have ever been described as, is "ab-"

[Han]

(01-13-2017 10:52 AM)DrD Wrote:  Oh ... one last thing: What the hell is a "normal" user? The closest thing to normal I have ever been described as, is "ab-"

I would wager that the vast majority of students using ANY graphing calculator do no more than basic arithmetic, possibly derivatives and integrals, and graphing on their calculator. Most of them will never write a program, let alone write a program that symbolically manipulates expressions. The exception would likely be a mathematics class in which programming specifically on a calculator is emphasized. Where programs are used, it is often the case that professors simply provide the programs to their students for them to use. And in cases like AP courses, I would go so far as to say it would be unwise to have students write their own programs for use on an AP exam unless they are thoroughly checked by instructors. The instructors are more likely to be in the position to provide a sound programming solution so as to help students earn a higher score. I am far removed from the AP exams nowadays though, so all this may be moot.

[DrD]

If that is the definition of "normal" user, then the hp prime is a vastly overkill product, isn't it? If you are suggesting most user's don't create programs, then most likely they don't use very much of the command set. Hence a lot of the CAS commands aren't of much utility value, and perhaps the hp prime is less than a good match for that 'normal' student?

I was attending college when the hp25 first came out. (My first hp calc). I loved to program that thing. Proving only, I guess, my ab-normality! I had two hp49's, and gave one of them to my (then) eighth grade grandson. He was more of a gamer, but he had some fun obtaining, and messing around with game programs, for it.

Han, I have a question, about populating equations in the Advanced Graphing App. I'll start another thread for that, but if you have time, maybe you might know of a way to do that, programmatically?

[parisse]

DrD, again it's not about left and right, it's about evaluation of inequation operators. Modifying that would be a long and bugprone task (there are 200 000 lines of source code in the CAS to review...). It's much easier to ask the few people who are programming with symbolic expressions to adapt to the way evaluation is done (and as pointed before it does not make the programmer task harder because there are less inequations operators to handle).
As Han said, a normal user will use the apps and built-in commands of the Prime (Home or CAS), only a tiny percentage of them will write programs. Nowadays, it's much easier to program on a desktop than on a calc, even for people who like to do programing.

[DrD]

Parisse,

I KNOW IT'S a CAS process, required as a result of evaluation of the inequality symbol. I don't disagree with you on this point. That isn't the issue. Forget about ANY relational operator, (<, =, >), they're NOT the reason for this issue. I totally understand that CAS evaluates the expression.

Where we are disagree is before the relational operation ever enters into the discussion. We have beat this issue to death, but commands, like the CAS coeff(), command, want an expression as an argument. To get an expression, *without* evaluation, (I KNOW IT GETS EVAL'd BY CAS!), from the appropriate left or right side, it must be separated from the relation, into the corresponding expression. Then, as in this example, coeff(Expr,[Var], [Integer]), and many other commands that take expressions as arguments, they are perfectly happy.

I know there are extra preparation work-a-rounds. I know you have a offered a helper program. The specific program I made is working just fine with my own work-a-round. It's not about getting a program to work ... it is about satisfying other commands likely to be part of ANY working program, that need expressions separated consistently. Then users can supply a list of relations, and they will pass through any set of similar commands without need of further left/right expression exchange.

There isn't any further point in discussing this. I see it as a bug, you don't, we disagree. I will be glad to buy you a beer, coffee, your choice, and personally thank you for all of your contributions over time; but we simply disagree on this one. Ignoring my posts (Only on this one issue, of course!), was a great idea!

[compsystems]

Comparison with classPAd400



(x<13) AND (x>5); returns (13>x) AND (x>5) // ok

the same above expression, but rewritten.
5<x<13; returns 0 ? (Inconsistency)

(x<13) OR (x<5); returns (13>x) OR (5>x) // ok

(x<13) XOR (x<5); returns 0?

not(x<13); returns NOT(13>x) // Does not reverse inequality

solve(ABS(2-x) = 1,x); "Unable to isolate function abs" ?



Ideal if BERNARD implement some functions of the classPAD such as
EXCHANGE: reverses the direction of inequality, but that can not rewrite place between 'QUOTES' (GOOD IDEA)?
REWRITE: Takes the expression on the right side, to the left
ABSEXPAND,
NOT: for Inequality
simplify: for Inequality
collect: for Inequality

[parisse]

(01-13-2017 10:36 PM)DrD Wrote:  Where we are disagree is before the relational operation ever enters into the discussion. We have beat this issue to death, but commands, like the CAS coeff(), command, want an expression as an argument. To get an expression, *without* evaluation, (I KNOW IT GETS EVAL'd BY CAS!), from the appropriate left or right side, it must be separated from the relation, into the corresponding expression. Then, as in this example, coeff(Expr,[Var], [Integer]), and many other commands that take expressions as arguments, they are perfectly happy.

??? I don't understand what you mean by relational operation or relation. There is nothing like that in the CAS : x<2 is an expression, left(x<2) is also an expression. The first one has '<' as rootnode, the second has 'left' as rootnode.

[DrD]

By "relation," I mean one side of an object is "related" to another.
By "operation," I mean how one side of an object is related to another.
Relationships are by means of less than, equal to, and greater than symbols.
(I'll add one other term for clarification for you):
By "expression" I mean each side of the relational operator.

With regard to our topic, I mean that there is a left side expression, a relation (symbol), and a right side expression. I mean, this forms a mathematical statement, in which these two items are analogous to the subject, and predicate; as in human language. Examples of what I mean are CAS commands that require "expressions."

Some CAS commands require access to the "expressions" of a mathematical sentence, predicated by some relationship, with an expression on the opposite side of that relationship.

Therefore when CAS makes an "evaluation," (and you know best what that is), I mean it is simply incorrect, and impolite, to hand a nice man like me, the predicate, when I ask for the subject of a statement. By "incorrect" I mean what Arno K has told you, "left is left, and right is right." A difficult concept, perhaps; but, nonetheless, fundamentally true. By "impolite" I mean it is rude of you to require the extra burden of correcting your error. By error, I mean sometimes you return the wrong expression. Now that I have explained what I mean, not to over use personal pronouns, I sure hope that I have explained, you get what I have explained, and I hope the explanation suffices.

If not, you may get better clarification if you replace (at least most of) the "I's" above, with "normal users." I mean I am normal, riiiiiiiight?

Quote:x<2 is an expression, left(x<2) is also an expression. The first one has '<' as rootnode, the second has 'left' as rootnode.

I see x<2 as a mathematical statement, a sentence, a relation. It relates the two "expressions", expression x, with the expression 2. The expression "x" is the subject, predicated by the relational operation, being less than the expression 2. By asserting that expression x is the subject, I mean, it is the expression being subjected to testing. Variable.

The expression "x" is on the left side of the relation, and the expression "2" is on the right side of that relational sentence. Returning the right side 2, when the left side x, is asked for is incorrect, and it's impolite.

Turning this back to you, some "normal users" might think of a tree's rootnode, for that term. Confusing, that you use the same term for '<' and 'left,' and most likely many other things. (Do rootnodes have left and right sides, too? It's as ambiguous as, well, returning right sides when left sides are expected).

[Maybe this trick will help explain]
If you tie a string, on your right hand finger, choice of finger optional, when you encounter a left() rootnode, STOP, think, "Does the "normal user" really want me to return the expression on the left hand side they asked for; or should I return the one on the right hand side, (you know, the hand with the string on it), and give them the finger, side?"

[GOOD NEWS!] There's room for compromise here, better handling of strings! Type casting: -changing object types- 'x<4' let's say, is a TYPE(8) and could be type cast to "x<4" let's call that a TYPE(2), then if both lhs() and rhs() operated on strings, (missing from the left() and right() commands), perhaps this would help(?)

[parisse]

I don't understand your explanations, remember I'm not a native English speaker.
To clarify, there is no concept of relation or predicate or whatever in the CAS, just expressions (1+x is an expression like x>2 like sin(x+1) or like 1+(x>2)). Expressions have a rootnode and argument(s) (0, 1 or several, in the last case they are grouped in one argument of type vector and subtype sequence), each argument being either atomic (like integer or floats or fractions or variable names or even CAS commands) or themselve expressions. The rootnode of an expression is a CAS command, there is no difference between +, > or left or any CAS command. All CAS command are functions taking 0, 1 or several arguments and returning one value.
Therefore x<2 is just an expression, and it is rewritten by evaluation to the equivalent expression 2>x. left() works on expression and follows the normal rule of evaluation. The members of the initial predicate/relation/whatever you call what you entered may be reversed because of evaluation, but you do not have to check for < or <= because they will never happen after evaluation, that's why I say that programming with evaluated expressions is not harder. But if you are programming with CAS expressions, you must take in account how the CAS was designed.
You might think the CAS is wrong designed because it does not correspond to your expectations, but you can not expect that I will redesign the CAS (17 years of work) just because you want left and right to match your expectations for arguments that are not supported in the documentation. So left(x<2) returning 2 is *definitively not* a bug.

[compsystems]

(01-14-2017 12:25 PM)parisse Wrote:  ... left(x<2) returning 2 is *definitively not* a bug.

It is not a BUG, because it evaluator rewrites the expression, but many programmers do not agree with it being rewritten the expression, I want and many that the expressions will be kept as they were introduced.

MY question is HOW TO IMPROVE THE CAS?, so that it works as the CAS of the TI68K / TI-NSPIRE and CLASSPAD.

Otherwise I see inferiority or power of symbolic manipulation

Who is better, still the old CAS of the TI68K calcs?

[DrD]

(01-14-2017 12:25 PM)parisse Wrote:  You might think the CAS is wrong designed because it does not correspond to your expectations, but you can not expect that I will redesign the CAS (17 years of work) just because you want left and right to match your expectations for arguments that are not supported in the documentation. So left(x<2) returning 2 is *definitively not* a bug.

ad nauseum:

Quote: re-Quote: (Parisse)
Of course it's not impossible to make left and right return what you would like, but that require reviewing everything in the CAS that handle inequations and certainly rewrite parts, a long and bugprone task that would probably impact normal users. Therefore I won't do it

re-Quote (Dale):
Well, now ... Parisse' post is completely understandable and adequately addresses my original concern!

There's a huge difference between the consequences of changing the existing behavior, and CAS systems not being able to do it.

CAS left() and right() commands are not well suited for general use, and for good reason.

This is the point where it ends, I thank you: (seventeen years)! How quickly time flies! And we move on. (I welcome you to visit America! In America we drive on the right hand side of the road. if you drive on our roads, (Lord, please guide him), I hope you don't evaluate like your CAS does... .)

-Drive Safely-

Summary:
re-Quote: (Dale)

Quote:There isn't any further point in discussing this. I see it as a bug, you don't, we disagree. Done, fini, et.al.

[DrD]

(01-14-2017 01:05 PM)compsystems Wrote:  

(01-14-2017 12:25 PM)parisse Wrote:  ... left(x<2) returning 2 is *definitively not* a bug.

1. It is not a BUG,
2. MY question is HOW TO IMPROVE THE CAS?,
3. Otherwise I see inferiority or power of symbolic manipulation
4. Who is better, still the old CAS of the TI68K calcs?

Ans(1): Get out the fly swatter. Damn thing is still flyin' around...
Ans(2): Build new commands: lhs() rhs(). Previously described...
Ans(3): uum, yeah ...
Ans(4): Come on, the worst day of Parisse is way better than the alternative!

It's all history, now...

-Dale-

[Dirk.nl]

DRD, what are you doing?
You have made your point!

How far does your knowledge, most of us in Europe drives also on the right right side of the road.

[Mark Hardman]

(01-14-2017 02:46 PM)Dirk.nl Wrote:  DRD, what are you doing?
You have made your point!

How far does your knowledge, most of us in Europe drives also on the right right side of the road.

I completely agree. I would ask that the moderators please consider closing this thread.

I cringe to think of Bernard's valuable time being wasted in such a way.

[John P]

(01-14-2017 02:58 PM)Mark Hardman Wrote:  

(01-14-2017 02:46 PM)Dirk.nl Wrote:  DRD, what are you doing?
You have made your point!

How far does your knowledge, most of us in Europe drives also on the right right side of the road.

I completely agree. I would ask that the moderators please consider closing this thread.

I cringe to think of Bernard's valuable time being wasted in such a way.

I disagree. I like this discussion very much, no 'CAS Correctness' please.

[DrD]

(01-14-2017 02:58 PM)Mark Hardman Wrote:  

(01-14-2017 02:46 PM)Dirk.nl Wrote:  DRD, what are you doing?
You have made your point!

How far does your knowledge, most of us in Europe drives also on the right right side of the road.

I completely agree. I would ask that the moderators please consider closing this thread.

I cringe to think of Bernard's valuable time being wasted in such a way.

Gentlemen:

I understand your sentiment and completely agree. We ran to an impasse. If the moderators want to delete this entire thread, or any of it's parts, there will be no complaints from me. There's no need to post anything further on this topic. I'll consider the matter closed.

-Dale-

[Dirk.nl]

Another positieve contribution, I hope.

Do you know why the left side of the road is the right side?

Most people are right handed. In the past, if you are a knight sitting on a horse with a lance in your right hand, and you want to hit your enemy you must be on the left side of the road.
Conclusion; left is right.
Another conclusion; if you are bigger (>) than your enemy, you can stay (if you want) on the right side of the road, but if you are smaller (<) than your enemy it is better to go to the left side of the road. First evaluate your situation and than take a conclusion.