+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: Absolute value: sometimes CAS is very clever, sometimes not! (/thread-11353.html)
Pages: 1 2
RE: Absolute value: sometimes CAS is very clever, sometimes not! - ijabbott - 09-08-2018 11:11 AM
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.
RE: Absolute value: sometimes CAS is very clever, sometimes not! - compsystems - 09-08-2018 03:28 PM
(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
RE: Absolute value: sometimes CAS is very clever, sometimes not! - ijabbott - 09-08-2018 04:06 PM
(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.
RE: Absolute value: sometimes CAS is very clever, sometimes not! - parisse - 09-09-2018 06:19 AM
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.
RE: Absolute value: sometimes CAS is very clever, sometimes not! - ijabbott - 09-09-2018 09:56 AM
Here are a few one liners to illustrate the problem:
- domain(ln(x),x) →x>0
- simplify(domain(ln(x),x))→x>0
- domain(1/x,x)→x≠0
- 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?
RE: Absolute value: sometimes CAS is very clever, sometimes not! - parisse - 09-09-2018 01:45 PM
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];
RE: Absolute value: sometimes CAS is very clever, sometimes not! - ijabbott - 09-09-2018 07:21 PM
I think I'd have to chalk the domain thing up as a victory for TI!
RE: Absolute value: sometimes CAS is very clever, sometimes not! - parisse - 09-09-2018 07:57 PM
Then it's probably a good idea for me to stop the discussion here.