A bug in the CAS

[wangchong01]

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?

[Arno K]

Wow
Arno

[Freire]

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.

[Arno K]

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

[parisse]

Fixed in source code.

[wangchong01]

(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.

[Freire]

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?

[Arno K]

I think 1e-11 is converted to a fraction first, then the root is taken, but that is a guess.
Arno

[parisse]

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)

[wangchong01]

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)).

[parisse]

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.

[webmasterpdx]

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.

[parisse]

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.

[fhub]

Hi Bernard,

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

Regards,
Franz

[parisse]

I'll try to do that, perhaps next week...

[wangchong01]

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.

[DrD]

(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.

[parisse]

Fixed in source.