A bug in the CAS
07-08-2017, 03:57 AM
Post: #1
 wangchong01 Member Posts: 85 Joined: Oct 2016
A bug in the CAS
Hello,
I find that the CAS will return 1e-27 when you input 3 NTHROOT 1e-27 in the CAS. Is it a bug or expected?

Attached File(s) Thumbnail(s)

07-08-2017, 06:23 AM
Post: #2
 Arno K Senior Member Posts: 432 Joined: Mar 2015
RE: A bug in the CAS
Wow
Arno
07-08-2017, 07:33 AM
Post: #3
 Freire Junior Member Posts: 33 Joined: Apr 2017
RE: A bug in the CAS
I believe It's because of CAS precision that would go only to 12 decimal places, if you try to do math with 1E-11 it works, bellow 1E-11 it doesn't [1E-12 for example - starts to repeat] remember that also CAS may not return exact values.
This kind of math should be handled by Home view, on Home view everything works as expected.
07-08-2017, 08:58 AM
Post: #4
 Arno K Senior Member Posts: 432 Joined: Mar 2015
RE: A bug in the CAS
Well, CAS or not should not matter here, ist a calculator and so has to produce reliable putput.
The problem here seems to be parsing of expressions, if one enters 3rd root of 27*10^-81 it works, but hitting the EEX-key gives a hint, the e is small in the input-line and converted to upper case on parsing, 27e-81 becomes 2.7E-80 without the root.
Arno
07-08-2017, 07:53 PM
Post: #5
 parisse Senior Member Posts: 1,036 Joined: Dec 2013
RE: A bug in the CAS
Fixed in source code.
07-09-2017, 02:50 AM
Post: #6
 wangchong01 Member Posts: 85 Joined: Oct 2016
RE: A bug in the CAS
(07-08-2017 08:58 AM)Arno K Wrote:  Well, CAS or not should not matter here, ist a calculator and so has to produce reliable putput.
The problem here seems to be parsing of expressions, if one enters 3rd root of 27*10^-81 it works, but hitting the EEX-key gives a hint, the e is small in the input-line and converted to upper case on parsing, 27e-81 becomes 2.7E-80 without the root.
Arno

I have tried some ways to avoid the ambiguous parsing but it doesn't work at all. I found that other two bugs in the CAS:
1.if you input exact(1e-80), you will get 0. I set the epsilon to 2.2250738585e−308 but got the same result. I think there may be something wrong for the CAS to deal with small numbers.
2. If you input bloc(), you will get 0. But if you then move your cursor to the "bloc" and press Enter, the calculator crashes.

Attached File(s) Thumbnail(s)

07-09-2017, 06:03 AM (This post was last modified: 07-09-2017 06:03 AM by Freire.)
Post: #7
 Freire Junior Member Posts: 33 Joined: Apr 2017
RE: A bug in the CAS
Just out of curiosity, if the problem was with the small "e" why 3rd root of 1e-11 works while 3rd root of 1e-12 doesnt?
07-09-2017, 06:27 AM
Post: #8
 Arno K Senior Member Posts: 432 Joined: Mar 2015
RE: A bug in the CAS
I think 1e-11 is converted to a fraction first, then the root is taken, but that is a guess.
Arno
07-09-2017, 07:03 AM
Post: #9
 parisse Senior Member Posts: 1,036 Joined: Dec 2013
RE: A bug in the CAS
No. It was a comparison with epsilon. I have changed a few tests where equality with 0 was done by comparison to exact, this explains that exact(1e-80) returns 0 on the Prime but not anymore in Xcas.
I have also fixed printing of bloc() (bloc is not supposed to be called directly by the user... but of course it should not crash)
07-09-2017, 07:42 AM (This post was last modified: 07-09-2017 09:09 AM by wangchong01.)
Post: #10
 wangchong01 Member Posts: 85 Joined: Oct 2016
RE: A bug in the CAS
I have found other two bugs
1.function parabola:
Code:
single_inter(line(0,1+i),parabola(0,1))
Then I got "undef". I think it may be due to the undef in the result returned by parabola.
You may try:
Code:
a:=parabola(0,1) a[2,2]
Then you will get [undef].
The problem still exists in the Xcas 1.2.3.
2.assume
When I assume(x>y), the calculator will not simplify abs(x-y) to x-y, but it will work if I assume x>2 and simplify(abs(x-2)).
07-09-2017, 04:12 PM
Post: #11
 parisse Senior Member Posts: 1,036 Joined: Dec 2013
RE: A bug in the CAS
This is almost correct, more precisely if you set simplification to none, you'll see that a[2,2] last two elements (parametric and cartesian equations) are undefined, but the intersection solver was solving with undef anyway. I have now fixed that.
For assumptions, parametric assumptions are not supported.
07-10-2017, 04:34 AM
Post: #12
 webmasterpdx Senior Member Posts: 541 Joined: Sep 2015
RE: A bug in the CAS
If you hit home mode and copy from cas (menu button), it'll give the correct answer. Now, I'm guessing but in CAS mode, often it's trying to approximate results and like someone earlier said, it's seeing that you are going beyond the 13 digits or whatever and gets a bit confused. However, there are many places where the crossover between home and CAS isn't perfect by far and still has minor bugs. You can usually figure out that it's in error based on the context of your use. If you are doing calculations symbolically, then you need to be in CAS mode, but if you are doing numerical computation where you want answers as accurately as possible, then you need to be in home mode.
This one needs an answer from someone working at HP.
07-10-2017, 07:48 AM
Post: #13
 parisse Senior Member Posts: 1,036 Joined: Dec 2013
RE: A bug in the CAS
You should get the same precision for numeric computations in CAS and Home, but CAS is intrinsically more complicated because it has to deal with more types, that's why there are a few more bugs remaining.
07-10-2017, 10:56 AM
Post: #14
 fhub Member Posts: 188 Joined: Dec 2013
RE: A bug in the CAS
Hi Bernard,

any chance for a new 32bit Windows version of Xcas?
The last one is almost 4 months old ...

Regards,
Franz
07-11-2017, 12:59 PM
Post: #15
 parisse Senior Member Posts: 1,036 Joined: Dec 2013
RE: A bug in the CAS
I'll try to do that, perhaps next week...
07-29-2017, 06:52 AM (This post was last modified: 07-29-2017 07:01 AM by wangchong01.)
Post: #16
 wangchong01 Member Posts: 85 Joined: Oct 2016
RE: A bug in the CAS
Unfortunately, I found some other bugs in the cas. Try simplify(asin(a*b)/abs(c)*abs(d)), and you will get something interesting. It also may have some small bugs of the unit functions, for example, the cas will "happily" translate __1 into 1_(1_(1)) and mksa(__1) will give you a stranger result.
07-29-2017, 10:11 AM
Post: #17
 DrD Senior Member Posts: 1,095 Joined: Feb 2014
RE: A bug in the CAS
(07-29-2017 06:52 AM)wangchong01 Wrote:  ... It also may have some small bugs of the unit functions, for example, the cas will "happily" translate __1 into 1_(1_(1)) and mksa(__1) will give you a stranger result.

Your example using the simplify(Expr) command does return a pretty weird result! I can also add that to the beta bug log, although Parisse may get it fixed beforehand.

Those other "small bugs," seem more like effects of GIGO, though.
07-29-2017, 11:53 AM
Post: #18
 parisse Senior Member Posts: 1,036 Joined: Dec 2013
RE: A bug in the CAS
Fixed in source.
 « Next Oldest | Next Newest »

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