[HP Prime] "Error while checking exact value with approximate value, returning both!"

[Chris Pem10]

The output of this integral would be confusing to a student:





The answer is quite simply "6", as returned by a 48,49,50. Perhaps labeling these two results could help lower the confusion.


Three ways to work around this are: use "0." and "4." as limits of integration and get the answer "6.", use "0" and "4" and disable "Exact" in the CAS settings and get "6.", or perform the calculation in Home and get "6.".


In my opinion this is confusing as the three models prior to the Prime were able to give the correct exact answer "6" without selecting "approx" in the CAS settings (using "stock" flag settings set on the 48).


Are we always required to use decimal values in the CAS?

[Tim Wessman]

The issue is that there really is not great support for the nthroot form due to personal preferences of the CAS author. Use ^1/3 and it works fine.

TW

[Chris Pem10]

In fact, the CAS's nthroot errors are somewhat predictable:

It seems to bork on odd values for the nthroot (in my very limited testing). And of course in the general case.


So my next question is: there is a xcas bug forum at the author's website. Should I be sending my errors there? Will bug fixes there make their way into my Prime? (Luckily I had three yrs of high school French !)

[Alberto Candel]

The conventions for nth root and 1/n power in xcas are explained in pages 64 and 65 of
Symbolic algebra and Mathematics with Xcas

They are different from those in Mathematica(TM).

[Chris Pem10]

Thank you for the reference; I'm looking into it :)


Here is another example where the Prime fails (and in this case the example is a well known textbook definition taught in calculus):





The "accepted" answer for both is "e".

In my opinion, the software author's method of interpreting powers and nth roots "taints" the CAS and propigates errors throughout the system. Or I'm just not understanding something here?


And both of the limits above result to "e" on the HP 50.

Edited: 5 Dec 2013, 1:58 p.m.

[Chris Pem10]

Actually, both limits produce the correct result in XCAS in Linux:





So, perhaps the Prime is at fault and not XCAS? Prime running an old version of XCAS? Prime finds limits without using XCAS? I'm so deep in a rabbit hole I can't see the light :)

Edited: 5 Dec 2013, 2:22 p.m.

[Alberto Candel]

It looks like the xcas in the Prime is not up to the official xcas. Besides the Prime cas seems to have changed between updates. Here is what I obtain with an older emulator (the one I have running in Linux under wine)

[Chris Pem10]

I can confirm that both limits return the correct result in Home view (used capital X as the variable).

[Alberto Candel]

This is what I get at Home with the above emulator

[Mark Hardman]

You are a release behind. As reported below, this is working correctly in the new release.

[Mark Hardman]

Chris,

In your first example you are taking the limit as b goes to 0 of (1 + b). This result is 1. You are then taking that result to the power of 1/b. This gives the correct result of 1 (1^n=1).

You need to add an extra pair of parenthesis starting at the limit and closing at the end of the expression. This gives the correct result of e.

limit(1+b,b,0)^(1/b) = 1

limit((1+b)^(1/b),b,0) = e

Edited: 5 Dec 2013, 5:41 p.m.

[Chris Pem10]

Yes. You are correct ! Obviously PEBKAC in this case.

[Tim Wessman]

Well, I think this needs work on our end to clarify what is happening. It is an easy mistake to make since there are times it can not be clear to what the function is being applied. I've flagged another mark on that item to float it up higher in the queue.

TW

[parisse]

There is an error in the antiderivative of NTHROOT/surd for linear argument explaining the factor 2 errot, I'll fix that. In the meantime use fractional powers...