A bug in the CAS

07082017, 03:57 AM
Post: #1




A bug in the CAS
Hello,
I find that the CAS will return 1e27 when you input 3 NTHROOT 1e27 in the CAS. Is it a bug or expected? 

07082017, 06:23 AM
Post: #2




RE: A bug in the CAS
Wow
Arno 

07082017, 07:33 AM
Post: #3




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 1E11 it works, bellow 1E11 it doesn't [1E12 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. 

07082017, 08:58 AM
Post: #4




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 EEXkey gives a hint, the e is small in the inputline and converted to upper case on parsing, 27e81 becomes 2.7E80 without the root. Arno 

07082017, 07:53 PM
Post: #5




RE: A bug in the CAS
Fixed in source code.


07092017, 02:50 AM
Post: #6




RE: A bug in the CAS
(07082017 08:58 AM)Arno K Wrote: Well, CAS or not should not matter here, ist a calculator and so has to produce reliable putput. 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(1e80), 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. 

07092017, 06:03 AM
(This post was last modified: 07092017 06:03 AM by Freire.)
Post: #7




RE: A bug in the CAS
Just out of curiosity, if the problem was with the small "e" why 3rd root of 1e11 works while 3rd root of 1e12 doesnt?


07092017, 06:27 AM
Post: #8




RE: A bug in the CAS
I think 1e11 is converted to a fraction first, then the root is taken, but that is a guess.
Arno 

07092017, 07:03 AM
Post: #9




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(1e80) 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) 

07092017, 07:42 AM
(This post was last modified: 07092017 09:09 AM by wangchong01.)
Post: #10




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)) You may try: Code: a:=parabola(0,1) The problem still exists in the Xcas 1.2.3. 2.assume When I assume(x>y), the calculator will not simplify abs(xy) to xy, but it will work if I assume x>2 and simplify(abs(x2)). 

07092017, 04:12 PM
Post: #11




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. 

07102017, 04:34 AM
Post: #12




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. 

07102017, 07:48 AM
Post: #13




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.


07102017, 10:56 AM
Post: #14




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 

07112017, 12:59 PM
Post: #15




RE: A bug in the CAS
I'll try to do that, perhaps next week...


07292017, 06:52 AM
(This post was last modified: 07292017 07:01 AM by wangchong01.)
Post: #16




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.


07292017, 10:11 AM
Post: #17




RE: A bug in the CAS
(07292017 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. 

07292017, 11:53 AM
Post: #18




RE: A bug in the CAS
Fixed in source.


« Next Oldest  Next Newest »

User(s) browsing this thread: