CAS command question

[compsystems]

I have noticed that the CAS history works different to the execution of a CAS program

The first step before programming is to test the sequence of steps of the algorithm on CAS history

CAS MODE

s := "(1/3)*x+(1/6)*y<=80"; ⇨ "(1/3)*x+(1/6)*y<=80" // ok
expr( s ); ⇨ expr( "(1/3)*x+(1/6)*y<=80" ) ⇨ 80 ≥ (1/3)*x+ (1/6)*y // ok
left( expr(s) ); ⇨ expr( "(1/3)*x+(1/6)*y<=80" ) ⇨ left( 80 ≥ (1/3)*x+ (1/6)*y ) ⇨ 80 // ok

left( expr( "'"+s+"'" )); ⇨ left( expr( "'"+"(1/3)*x+(1/6)*y<=80"+"'" ) ⇨ left( '(1/3)*x+(1/6)*y<=80' ) ⇨ (1/3)*x+(1/6)*y // ok

left(expr("'"+s+"'")) ⇨ (1/3)*x+(1/6)*y // ok

Now step by step

expr( "'"+s+"'" ); ⇨ (1/3)*x+(1/6)*y ≤ 80 ⇦ It has removed the quotes (Apparently well.). The quotation marks must be preserved
the next step fails Copying to the entry line
[up] [copy] [enter] 80≥ (1/3)*x+(1/6)*y (wrong for the above reason)

expr( "'"+s+"'" ); ⇨ '(1/3)*x+(1/6)*y ≤ 80' // This is the correct output

An easier example
HP-PRIME
3+4; [ENTER] 7 // ok
'3+4'; [ENTER] 3+4 (Apparently well.).
[up key] [copy] 3+4 [enter] 7 // wrong

This should be copied with quotation marks, or better with the function QUOTE()
[up key] [copy] '3+4' or quote(3+4) [enter] '3+4' // ok

HP50G
'3+4' [ENTER] '3+4' // ok
[up or HIST key] [copy (right-shift+var)] then [on] [paste] [ENTER] '3+4' // ok and not 7

[Han]

(01-06-2017 05:59 PM)DrD Wrote:  Unfortunately, this approach fails to return the (lhs or rhs), unless the input is constrained to coefficients with approximate numbers:

Example: s:="(1/3)x+(1/6)y<=80"; // lhs(s) ==> Error: Invalid input
(Extra credit challenge: Convert the exact(coefficients) to approximate)

You have to feed it a valid expression. Your example fails because it is an invalid expression all on its own, not because of issues with the commands. Typing: (1/3)x+(1/6)y<=80 into the CAS view and you will get an error (implicit multiplication -- there are a number of threads on this topic, I believe). You can, of course, check for this by simply doing an IFERR block for CAS(EVAL(s)).

Code:

export lhs(s)
begin
  IFERR
    CAS(EVAL(s));
  THEN
    return("Input error");
  ELSE
    CAS.left(EVAL("'" + s + "'"));
  END;
end;

[Han]

(01-06-2017 06:59 PM)compsystems Wrote:  Now step by step

expr( "'"+s+"'" ); ⇨ (1/3)*x+(1/6)*y ≤ 80 ⇦ It has removed the quotes (Apparently well.). The quotation marks must be preserved
the next step fails Copying to the entry line
[up] [copy] [enter] 80≥ (1/3)*x+(1/6)*y (wrong for the above reason)

expr( "'"+s+"'" ); ⇨ '(1/3)*x+(1/6)*y ≤ 80' // This is the correct output

An easier example
HP-PRIME
3+4; [ENTER] 7 // ok
'3+4'; [ENTER] 3+4 (Apparently well.).
[up key] [copy] 3+4 [enter] 7 // wrong

This should be copied with quotation marks, or better with the function QUOTE()
[up key] [copy] '3+4' or quote(3+4) [enter] '3+4' // ok

HP50G
'3+4' [ENTER] '3+4' // ok
[up or HIST key] [copy (right-shift+var)] then [on] [paste] [ENTER] '3+4' // ok and not 7

You keep forgetting that the parser, like with almost any other CAS software, will generally evaluate its input. Evaluation of a quoted expression results in an unquoted expression. The net effect is essentially stripping the quotation. So copying the result would be copying an unquoted expression, which is why [up key][copy] gives you 3+4 on the command line, and not '3+4'. Try [up key] twice before copying.

On the HP50G, evaluation of a symbolic object merely copies the object onto the stack because an expression and a 'quoted expression' are one and the same. They (Prime vs HP50G) also have different evaluation schemes due to their different object representations.

[DrD]

(01-06-2017 06:57 PM)chromos Wrote:  This works:
lhs("(1/3)*x+(1/6)*y<=80")

Implicit multiplication was used as the test case. This is fair, because it's an example a student might encounter directly from a workbook problem. If you can find input workarounds, that is not quite the same thing. The debate hinges on what a left() or a lhs() command, should consistently return.

[Han]

(01-06-2017 08:28 PM)DrD Wrote:  

(01-06-2017 06:57 PM)chromos Wrote:  This works:
lhs("(1/3)*x+(1/6)*y<=80")

Implicit multiplication was used as the test case. This is fair, because it's an example a student might encounter directly from a workbook problem. If you can find input workarounds, that is not quite the same thing. The debate hinges on what a left() or a lhs() command, should consistently return.

Except in some extremely simple cases, there is no implicit multiplication on the Prime. Your expression leads to an error when entered on the command line in CAS view all on its own. Feed it a valid expression and it works. You can place error traps if you want to make it more robust.

[compsystems]

(01-06-2017 08:27 PM)Han Wrote:  You keep forgetting that the parser, like with almost any other CAS software, will generally evaluate its input. Evaluation of a quoted expression results in an unquoted expression. The net effect is essentially stripping the quotation. So copying the result would be copying an unquoted expression, which is why [up key][copy] gives you 3+4 on the command line, and not '3+4'. Try [up key] twice before copying..

I think it gives more power to the calculator if the expressions between ' ' are not evaluated (expression unchanged and un-evaluated.), for that there is the command EVAL, SIMPLIFY, COLLECT and others, if the expressions are maintained as they are, I could produce programs step by step much more easily, without make long codes and converting to strings

Why not do this in hp-prime? YOU or HP-TEAM AGREE?

case 1:
INPUT
EXPR
OUTPUT
EVAL(EXPR) // OK

case2:
INPUT
'EXPR'
OUTPUT
'EXPR' and not EVAL('EXPR')

or at least one system flag
EVALUATE EXPRESSION BETWEEN ' ' (ON CAS HISTORY) yes/no

================

When defining a function where the expression is between ' ', in the history is displayed with quotes

F1(x):='sin(x)'; ⇨ 'sin(x)'
[up key] QUOTE(sin(X))
right(F1); ⇨ QUOTE(sin(X))
left(F1); ⇨ QUOTE(sin(X))

F1(90); ⇨ sin(90)

[parisse]

(01-06-2017 08:28 PM)DrD Wrote:  

(01-06-2017 06:57 PM)chromos Wrote:  This works:
lhs("(1/3)*x+(1/6)*y<=80")

Implicit multiplication was used as the test case. This is fair, because it's an example a student might encounter directly from a workbook problem. If you can find input workarounds, that is not quite the same thing. The debate hinges on what a left() or a lhs() command, should consistently return.

When you enter a commandline and press enter, the first step that happens is parse: implicit multiplication is not supported in the CAS parser except for a few obvious cases, (1/3)x will error. The second step is evaluation: evaluation of symbolic expressions is a recursive process: first eval the arguments, then apply the command or function on the evaled arguments. This is the reason why left(x<2) will return 2, x<2 is evaled to 2>x before left is applied. In algebraic mode, arguments are evaled before the command is applied. This is the main difference with RPN, where arguments are not EVAL-ed when you run a command (except if the user explicitly calls EVAL). That's why I said that RPN gives you much more control on evaluation than algebraic mode, this is one strength of RPN, but RPN has weaknesses, for example it's much harder to have optional arguments.

[DrD]

Thanks for the additional detail, Parisse. "Why" this behavior occurs has by now been very well explained. There still remains inconsistency that is frustrating. The commands for left() and right() do operate as explained, but do not always return results as expected, and do not always return results as desired.

In this thread, we have identified some of the commands outlier's, namely: relations involving the "<" operator, implicit multiplication differences, (exact, versus approximated rationals), and these exceptions extend to user developed programs; the contrasting commands in other CAS system's (giac, Maxima, etc.), and the lack of clarity in help guides.

The historical legacy for the current operation is understood. Notwithstanding this legacy, a progressive approach might include two additional new commands, lhs(), and rhs(), to make both the ppl, and CAS more useful, and more consistent with their more robust, but comparable products.

Tim, or Cyrille may have further perspective, but as an hp prime customer, and a voice for others who may share similar interest, I would like to ask for two new commands, lhs(), and rhs(), to either replace left() or right(), or be additionally included in the hp prime. Operation is probably clear enough from these related discussions, but is closely illustrated by their counterparts in Matlab or Maxima.

Thank you.
-Dale-

[compsystems]

Exists a function or command to distribute a value (quotient) to each term?

I think that COLLECT should also operate in inequalities.
collect((x+1-3*x) > (3*x+5-3*x));
⇨ =( (x+1-3*x) > (3*x+5-3*x)
(x-3*x)-1 > (3*x-3*x)+5 ⇨ (-2*x+1) > 5

collect(-2*x>4)/-2); ⇨ =( -2*x > 4)/-2;
⇨ -2*x/-2 > 4/-2
⇨ x < -2
Do you agree, Mr. Parisse?

please see
Line 8, the expression was not simplified (The quotient was not distributed), Or how the inequalities are simplified with hp-prime CAS?

HP-PRIME CAS HISTORY

PHP Code:

1: simplify: none
2: purge(x);
3: x+1 > 3*x+5; 
4: Ans-3*x; ⇨ (x+1-3*x) > (3*x+5-3*x)
5: simplify(Ans);⇨ (-2*x+1) > 5
6: Ans-1;  ⇨ (-2*x) > 4
7: Ans/-2;  ⇨ ((-2*x) > 4)/-2
8: simplify(Ans); ⇨ ((-2*x) > 4)/2 // =(
9: (-2*x) > 4;
10: left(Ans)/-2; ⇨ 2*x/2; // Using LEFT & RIGHT =(
11: simplify(Ans); ⇨ x
12: (-2*x) > 4;
13: right(Ans)/-2; ⇨ -2
14: //I DO NOT KNOW HOW TO CALL THE LINE 11 TO THE 13 ⇨ x < -2 


TI-89/TI-VOYAGE200 CAS HISTORY

PHP Code:

1: simplify: Always MAXIMUM =(
2: delvar(x): ⇨ Done
3: x+1 > 3*x+5: 
4: Ans(1)+⁻3*x: ⇨ 1-2*x > 5
5: Ans(1)+⁻1: ⇨ (-2*x) > 4
6: Ans(1)/⁻2: ⇨ x < -2 


[parisse]

(01-07-2017 11:25 AM)DrD Wrote:  The historical legacy for the current operation is understood. Notwithstanding this legacy, a progressive approach might include two additional new commands, lhs(), and rhs(), to make both the ppl, and CAS more useful, and more consistent with their more robust, but comparable products.
-Dale-

I'm not sure you realize that, but what you ask is a little bit like asking + to work in RPN mode like in algebraic mode, after all writing 2+3 is more intuitive than << 2 3 + >> or '2+3' EVAL. Evaluation is at the heart of how a CAS work, you can not change that. Matlab is not a CAS, you can't compare. Maple is a CAS and looking at Han's explanations it does (almost) the same as Giac. Maxima is also a CAS but it does not really handle inequations, for example you can't solve(y^2>2,y), therefore it's easier for Maxima to keep > >= < <= inert.

[Dirk.nl]

Hi Parisse,

I have tried left and right x+y=4 (with > >= < <= , with and without single quotes) on my iPad with PocketCAS Pro, it gave exactly the same results as the HP Prime as you explained in an earlier post! Please don't change this behavior (only) for the HP Prime.
Thanks for your explanations!

[DrD]

(01-07-2017 08:15 PM)parisse Wrote:  I'm not sure you realize that, but what you ask is a little bit like asking + to work in RPN mode like in algebraic mode, after all writing 2+3 is more intuitive than << 2 3 + >> or '2+3' EVAL. Evaluation is at the heart of how a CAS work, you can not change that. Matlab is not a CAS, you can't compare. Maple is a CAS and looking at Han's explanations it does (almost) the same as Giac. Maxima is also a CAS but it does not really handle inequations, for example you can't solve(y^2>2,y), therefore it's easier for Maxima to keep > >= < <= inert.

wxMaxima:

(%i2) s: 4*x+3*y<=48$

(%i3) lhs(s);
(%o3) 3*y+4*x

(%i4) rhs(s);
(%o4) 48

Caveman simplicity ... It's not about solve, or rpn, or anything other than left() returning the left argument, right() returning the right argument. The lhs() and rhs() are missing prime commands; left() and right() CAS commands lack functionality.

( quod erat demonstrandum )

[parisse]

Yes DrD, maxima keeps inequation operators inert but they don't solve inequations as explained in my previous post. The point is that it's not independant, if the developers introduce inequation solving in a future maxima release, they may very well decide that it is easier to have 2 inequation operators instead of 4 to handle and do like Maple and Giac, eval one form to the other.
I think I have spent enough time in this threads explaining the rationals behind this, after all we are speaking of a feature that 1/ is not documented and 2/ interests only programmers. If you are still convinced that Giac does it wrong and it would be easy to improve, I'm afraid I won't be able to convince you and you won't be able to convince me...

[DrD]

(01-08-2017 07:11 AM)parisse Wrote:  I'm afraid I won't be able to convince you and you won't be able to convince me...

I'm convinced ...

-Dale-

[compsystems]

About MatLab, start as a numerical engine, then business the symbolic engine of MAPLE, then buy MuPAD, Now we say that MatLab has two numerical and symbolic motors, for this reason it is already considered a CAS.

continuing with the inequations, I want to get the next result x < -2 or -2 > x, but without using solve cmd I tried collect, expand, simplify and nothing, The ti89 if simplify, I do not know if other CASs

(-2*x) > 4;
Ans/-2; ⇨ ((-2*x) > 4)/-2
simplify(Ans); ⇨ ((-2*x) > 4)/2 // =(
collect(Ans), ⇨ ((-2*x) > 4)/2 // =(
expand(Ans) ⇨ (1/2)*((-4)>(2*x)) // =(

Someone please, to prove the simplification of the previous inequalities in other CAS.

[DrD]

(01-07-2017 08:15 PM)parisse Wrote:  Maxima is also a CAS but it does not really handle inequations, for example you can't solve(y^2>2,y), therefore it's easier for Maxima to keep > >= < <= inert.

I'm not proficient with Maxima, but I was able to do this:

wxMaxima

(%i1) load(solve_rat_ineq)$

(%i2) solve_rat_ineq(y^2>2);
(%o2) [[y<-sqrt(2)],[y>sqrt(2)]]

(%i3) s: %o2$

(%i4) map(lhs, map(first, s));
(%o4) [y,y]

(%i5) map(rhs, map(first, s));
(%o5) [-sqrt(2),sqrt(2)]

Please note: lhs() returned the left side of the inequality, and rhs() returned the right hand side of the inequality, unambiguously.

"Maybe someday the developer's will find time ..." The hp prime is very useful, and seems to be evolving. I do hope it continues.

[compsystems]

No matter that the terms move from one place to another within inequality, the important thing is the operator.

Since the same algebraic operations can change the operand.

For example if divided by a negative amount, the direction of inequality is reversed.

But we must focus on the manipulation of algebraic expressions.

The CAS of hp-prime does not seem to simplify inequalities, this is serious.

simplify( ( (x+1)>(3*x+5) )/-2) ) -> (((x+1)>(3*x+5))/-2)

[DrD]

(01-08-2017 04:17 PM)compsystems Wrote:  About MatLab, start as a numerical engine, then business the symbolic engine of MAPLE, then buy MuPAD, Now we say that MatLab has two numerical and symbolic motors, for this reason it is already considered a CAS.

Someone please, to prove the simplification of the previous inequalities in other CAS.

wxMaxima is open source and free download. It is quite a versatile system, which you may find useful: http://andrejv.github.io/wxmaxima/

Or Google: "wxMaxima"

Another VERY useful open source program, (similar to Matlab) is Scilab. With it you can do computation AND simulation, great for engineers, scientists, and hobbyists: http://www.scilab.org/
If you have fun with the hp prime, you will love Scilab with simulation for hardware. Tons of Matlab programs are adaptable to Scilab, and lots of them work directly. If you are a hardware buff, things like the Arduino, or PLC devices (for control and monitoring) applications are it's strength.

If you already are familiar with these programs, you most likely agree. If not, and want to broaden the depth of your knowledge and breadth of your abilities ... give these free programs a try. The hp prime is a great sidekick, especially for Scilab and Arduino applications.

[John P]

(01-06-2017 08:37 PM)Han Wrote:  

(01-06-2017 08:28 PM)DrD Wrote:  Implicit multiplication was used as the test case. This is fair, because it's an example a student might encounter directly from a workbook problem. If you can find input workarounds, that is not quite the same thing. The debate hinges on what a left() or a lhs() command, should consistently return.

Except in some extremely simple cases, there is no implicit multiplication on the Prime. Your expression leads to an error when entered on the command line in CAS view all on its own. Feed it a valid expression and it works. You can place error traps if you want to make it more robust.

Hello,
Could you point me to some more in depth doc(s) about XCAS or HP Prime CAS.
Thank you.

[parisse]

(01-08-2017 05:27 PM)DrD Wrote:  

(01-07-2017 08:15 PM)parisse Wrote:  Maxima is also a CAS but it does not really handle inequations, for example you can't solve(y^2>2,y), therefore it's easier for Maxima to keep > >= < <= inert.

I'm not proficient with Maxima, but I was able to do this:

wxMaxima

(%i1) load(solve_rat_ineq)$

(%i2) solve_rat_ineq(y^2>2);
(%o2) [[y<-sqrt(2)],[y>sqrt(2)]]

Great, but my point still holds, since you must load an additional package, that is restricted to rational inequations (and of course 3>2 will still return unevaluated). If you accept additional program, then you should be able to write your own lhs/rhs with strings according to your wishes.