Post Reply 
Absolute value: sometimes CAS is very clever, sometimes not!
09-08-2018, 11:11 AM (This post was last modified: 09-08-2018 12:08 PM by ijabbott.)
Post: #21
RE: Absolute value: sometimes CAS is very clever, sometimes not!
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.

— Ian Abbott
Find all posts by this user
Quote this message in a reply
09-08-2018, 03:28 PM (This post was last modified: 09-08-2018 03:54 PM by compsystems.)
Post: #22
RE: Absolute value: sometimes CAS is very clever, sometimes not!
(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 ≠ -1returns True
evalb
(2returns False
evalb
([x<>1equal(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

LO SUFICIENTEMENTE BUENO ES ENEMIGO DE LA EXCELENCIA.
Find all posts by this user
Quote this message in a reply
09-08-2018, 04:06 PM
Post: #23
RE: Absolute value: sometimes CAS is very clever, sometimes not!
(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.

— Ian Abbott
Find all posts by this user
Quote this message in a reply
09-09-2018, 06:19 AM
Post: #24
RE: Absolute value: sometimes CAS is very clever, sometimes not!
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.
Find all posts by this user
Quote this message in a reply
09-09-2018, 09:56 AM (This post was last modified: 09-09-2018 09:58 AM by ijabbott.)
Post: #25
RE: Absolute value: sometimes CAS is very clever, sometimes not!
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?

— Ian Abbott
Find all posts by this user
Quote this message in a reply
09-09-2018, 01:45 PM
Post: #26
RE: Absolute value: sometimes CAS is very clever, sometimes not!
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];
Find all posts by this user
Quote this message in a reply
09-09-2018, 07:21 PM
Post: #27
RE: Absolute value: sometimes CAS is very clever, sometimes not!
I think I'd have to chalk the domain thing up as a victory for TI! Smile

— Ian Abbott
Find all posts by this user
Quote this message in a reply
09-09-2018, 07:57 PM
Post: #28
RE: Absolute value: sometimes CAS is very clever, sometimes not!
Then it's probably a good idea for me to stop the discussion here.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)