CAS command question

[compsystems]

Well let's continue to evaluate the CAS in separate threads

For example in this thread related to the parts of an inequality, report that the HP-PRIME CAS does not perform operations with inequalities, such as simplify, other results are strange, and there was no response

(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

(-2*x>4)/-2; ⇨ (-2*x > 4)/-2;
This must be the output
⇨ -2*x/-2 > 4/-2
⇨ x < -2

collect( (x+1-3*x) > (3*x+5-3*x));
⇨ (x+1-3*x) > (3*x+5-3*x)
This must be the output
⇨ (x-3*x)+1 > (3*x-3*x)+5 ⇨ (-2*x+1) > 5

[parisse]

(01-14-2017 01:05 PM)compsystems Wrote:  MY question is HOW TO IMPROVE THE CAS?, so that it works as the CAS of the TI68K / TI-NSPIRE and CLASSPAD.

Giac will never be a clone of the TI or Casio CAS. It will continue to improve as long as I can improve it, but I will not waste time in large redesign of Giac. My main priorities are speed efficiency and mathematical functionalities.
Double inequation like in 5<x<13 are not supported by the Prime CAS parser.
I will probably add evaluation of not(x<5) to x>=5.
(-2*x>4)/-2 already returns (-2)>(2*x/2) in the current version of Xcas.

[compsystems]

Dear Bernard. For my xCAS has a great value, because it is created by a single author, while other CASs have several developers.

I never want to clone another calculator, what should be cloned are the mathematical functionalities as
EXCHANGE: reverses the direction of inequality
REWRITE: Takes the expression on the right side, to the left.
ABSEXPAND, COMBINE, etc

[DrD]

(01-14-2017 03:27 PM)Dirk.nl Wrote:  Another positieve contribution, I hope.

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

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

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

Contraposition:

1. The left side of the road is the right side when the viewport contains an odd number of mirrors.

2. Multivariate objective functions, subject to many constraints, don't always converge on an optimality. Your conclusion isn't defensible. Left is simply, not right.

3. Strictly speaking, if you evaluate your situation, thinking left is right, when left is wrong, and the forces interact, the outcome isn't guaranteed. If you are "civil," the passing may be congenial.

Summary:
Extending your conclusion in example 2, to modern combatants, past horses and rocket powered anti-missile missile systems, to laser lances, any delay time imposed by requiring an extra handling process to get true left or right guidance, may be at a cost: erreur fatale.

May I suggest that modeling these problems may be better suited in a new thread? I started this bug report, and feel that Parisse has very adequately dealt with the issue. Agreement has been reached, for this CAS, it's simply not worth further pursuit.

73's, QRT, AR, SK