Absolute value: sometimes CAS is very clever, sometimes not!

[ijabbott]

So I guess there is not much that can be done about domain() as long as there is no support for continuous sets.

EDIT:

Alternatively, operators for "mathematically equal" and "mathematically not equal" could be added, although the natural symbols for those operators would be the already taken = and ≠ symbols.

[compsystems]

(09-08-2018 06:05 AM)parisse Wrote:  If you want to play with evaluation, make sure that Simplification is set to None in CAS Settings.
Then a:=domain(1/(x+1),x); followed by eval(a,1) will return x!=-1.

ok, but please hppteam include for next firmware the xcas autosimplify() command , otherwise how do I change the flag from a program code? if I need some times, maximum simplification and other times, do not simplify

-------------

(09-08-2018 10:43 AM)ijabbott Wrote:  Back to compsystem's point, why does 'x ≠ -1' get simplified to a boolean 'true' if x is unknown?

(09-08-2018 10:52 AM)parisse Wrote:  Because x (identifier) is different from 1 (integer), like for == which does not mean "mathematically equivalent".

And with what purpose the operadopr = acts as ==, if there is a command (==) or evalb() for that purpose, also for ≠

PHP Code:

evalb(x ≠ -1) returns True
evalb(1 = 2) returns False
evalb([x<>1, equal(1,2)] ) returns [True,False] 


I think that the operator =, ≠, should not operate as a comparator, this affects the logic of the algorithms, so I suggest a cas flag for these operators do not assume the comparison.

Another option is for the system to ask what kind of data it is . If it is symbolic assume(x,symbol);, do not compare

[ijabbott]

(09-08-2018 03:28 PM)compsystems Wrote:  

(09-08-2018 10:43 AM)ijabbott Wrote:  Back to compsystem's point, why does 'x ≠ -1' get simplified to a boolean 'true' if x is unknown?

(09-08-2018 10:52 AM)parisse Wrote:  Because x (identifier) is different from 1 (integer), like for == which does not mean "mathematically equivalent".

And with what purpose the operadopr = acts as ==, if there is a command (==) or evalb() for that purpose, also for ≠

'==' and '≠' seem most mostly in the same class as each other, although x≠1 →true, but x==1→0 (rather than 'false'). '=' seems to be for equalities as in equating two sides of an equation and seems to be in the same class as '<', '≤', '>', and '≥' as far as the CAS is concerned. What is missing is a "not equal to" operator in the same class as '<', '>'. etc.

Quote:I think that the operator =, ≠, should not operate as a comparator, this affects the logic of the algorithms, so I suggest a cas flag for these operators if they find symbols do not assume the comparison.

I'm not a big fan of using special flags, but agree that something is needed.

[parisse]

I'm sorry, but I don't understand what's wrong with the current comparison commands. I can clarify if you give me oneliners (but please not a collection of 10 or more commands with comments that are difficult to understand).
But let's be clear: even if I can understand some requests, I will not change the behavior of ==, != or < >, because it is too much intricated in the CAS. Modifying something there would have side-effects in many other parts and that would mean lot of bugs.
A CAS will not magically do maths for you, and it will not replace a math teacher for students. It's a tool that is primarily meant to replace hard computations by hand.

[ijabbott]

Here are a few one liners to illustrate the problem:

1. domain(ln(x),x) →x>0
2. simplify(domain(ln(x),x))→x>0
3. domain(1/x,x)→x≠0
4. simplify(domain(1/x,x))→1 «???»
   

Specifically, the bad simplification on line 4 is the problem.

Perhaps the domain on line 3 could be expressed as x<0 OR x>0 to avoid the bad simplification?

[parisse]

It's not really related to domain. It's just that x!=0 evals, while x>0 stays unevaled. I don't think that modifying x!=0 to x<0 or x>0 is a good idea, because it's more complicated to read. In a program, you can play with the answer of domain (or any expression) by disabling auto-simplification and commands like:
a:=domain(1/x); eval(a,1)[1]; eval(a,1)[2]; eval(a,1)[3];

[ijabbott]

I think I'd have to chalk the domain thing up as a victory for TI!

[parisse]

Then it's probably a good idea for me to stop the discussion here.