HP Prime Miscalculating

[luc4as]

When I try to calculate 3.6^2-4*3.24 in CAS mode, the calculator doesn't return 0, which is the correct answer. Home mode calculates it just fine. Does anyone know how to fix it?

[Joe Horn]

(10-23-2015 02:35 AM)luc4as Wrote:  When I try to calculate 3.6^2-4*3.24 in CAS mode, the calculator doesn't return 0, which is the correct answer. Home mode calculates it just fine.

Short answer: It's wrong in CAS for the same reason that .5-.3-.2 doesn't return 0, namely, garbage in garbage out. You THINK you put 3.6 and 3.24 into CAS, but you didn't.

Long answer: It's because Home uses BCD (which can represent 3.6 and 3.24 exactly) and CAS uses binary floating point (which can't). When you type 3.6 in Home, it's EXACTLY 3.6, but when you type 3.6 in CAS, it actually generates this value:

3.599999999999994315658113919198513031005859375 (exactly)

... because that's the largest number less than or equal to 3.6 which is representable with a 48-bit mantissa. For what it's worth, it's stored internally in hex scientific notation as 1.CCCCCCCCCCCCp+1 where "p" means "times 2 to the power of".

Quote: Does anyone know how to fix it?

Yes. You have two options:

Option #1: Use Home for all your floating-point math needs, and ONLY use CAS for EXACT & SYMBOLIC math (that is, integers with no decimal point, and variables).

Option #2: If you INSIST on doing that problem in CAS (why why why?) then type the decimal fractions as exact ratios of integers, like this:

Instead of: \({ 3.6 }^{ 2 }-4\times 3.24\), type this instead: \({ \left( \frac { 36 }{ 10 } \right) }^{ 2 }-4\times \frac { 324 }{ 100 } \)

CAS is designed for exact math, like that. Floating point reals with decimal points in them are usually NOT "exact" in CAS. If that makes CAS seem more complicated that it should be, see Option #1 above. Knowing when to use Home, and when to use CAS, is part of learning how to use the HP Prime.

"If Home and CAS behaved exactly the same, there would be no need for both to exist." -- Joe Horn

[Tim Wessman]

So as Joe's said, it isn't really an error and is working exactly correctly. If this really bothers you though, you should try turning on the "Floating" number mode in the home settings screen [SHIFT][HOME]. That will "hide" the problem.

Understanding why it is happening though is very important in my mind though and will be helpful to understanding not just the calculator, but math in general.

[retoa]

Turning on the floating number mode it will not hide the problem, the result is so small that, also if the Prime is in floating number format, it will be displayed in scientific number format.

So in floating 3, 0.5-0.2-0.3 will give 1.776e-15

[Tim Wessman]

Ah right, I stand corrected.

[Archanus]

Hello

Is there a way to obtain that result in Wolfram Mathematica?

I mean that 3.6^2-4*3.24 = -5.6843*10^(-14) , like in the HP Prime?

[retoa]

I do not know Wolfram Mathematica very good, but in Maxima you can do:

3.6b0^2-4*3.24b0; (3.6b0 is like 3.6e0 but it uses a big float instead of a float)

the result will be:

−2.220446049250313b−16 which means −2.220446049250313e−16 and is also different from 0

To obtain exactly the same result on two different machines they have to work with the same number of bits.

If Wolfram Mathematica works as good as Maxima and the Prime do, then there should be a way to obtain a similar value.
Otherwise it would mean that Wolfram Mathematica can not do all types of mathematical calculations... :-)

[retoa]

In Wolfram Alpha if you calculate:

0.5 to binary - 0.3 to binary - 0.2 to binary

you obtain in quad-precision (you have to click on "more" bottom right):

0000000000000000000000000000003c

which is not 0, so 0.5-0.3-0.2<>0.

I tried to compute (3.6 to binary)^2 - 4*(3.24 to binary) but Wolfram Alpha seems to have some problem interpreting the parenthesis.

[Nigel (UK)]

(10-23-2015 07:38 PM)Archanus Wrote:  Hello

Is there a way to obtain that result in Wolfram Mathematica?

I mean that 3.6^2-4*3.24 = -5.6843*10^(-14) , like in the HP Prime?

Code:

FromDigits[RealDigits[N[3.6],2,48],2]

will give you a rational number equivalent to the 48-bit binary representation of 3.6 . Using FromDigits and RealDigits you could probably use Mathematica to simulate 48-bit binary arithmetic if you really wanted to...

If you are trying to imply that (unlike the lowly Prime) Mathematica isn't subject to rounding errors, even when working with approximate numbers, I don't think I can agree with you. On my (very old) copy of Mathematica 3.0, the calculation

Code:

(2^0.5)^2-2

gives an answer of about 4*10^{-16}.

Nigel (UK)

[Archanus]

Thanks a Lot Dear People !!

As Wolfram Mathematica is the Most Powerful CAS Software, then yes... It's officially 0 jajaja

So Luc4as, yes, It's 0 When you see n*10^(-10) or n*10^(-11) or more... It's Zero

In Wolfram is 0*10^(-308) ... More Precision you want? jajaja What do you want to measure? a "Mini-Quark"? jaja

[parisse]

Actually, there seems to be a confusion. Inside the CAS, you should use exact representation of objects (i.e. here rationals) if you want to perform exact arithmetic, and approx representation of objects (i.e. floating point) if you want to perform approx computations.
Floating points should not be used to do exact computations unless you know exactly what you do, because they are not designed to do that, they will do exact computations for *some* rationals with denominator dividing a power of 10 in HOME or a power of 2 in CAS.
In other words, you can perfectly do your floating point computations inside the CAS and some floating point computation inside HOME are done by conversion to CAS floats calling the CAS numeric stuff (for example numeric integration) or are faster in CAS (like matrix inversion).

[retoa]

(10-23-2015 05:41 AM)Joe Horn Wrote:  Long answer: It's because Home uses BCD (which can represent 3.6 and 3.24 exactly) and CAS uses binary floating point (which can't). When you type 3.6 in Home, it's EXACTLY 3.6, but when you type 3.6 in CAS, it actually generates this value:

3.599999999999994315658113919198513031005859375 (exactly)

... because that's the largest number less than or equal to 3.6 which is representable with a 48-bit mantissa. For what it's worth, it's stored internally in hex scientific notation as 1.CCCCCCCCCCCCp+1 where "p" means "times 2 to the power of".

So the prime uses a 48 bits mantissa to work with binary floating point, and not 52 like in IEEE 754 double precision. How will be a number represented?
I mean in double precision you have 1 bit for the sign, 11 for the exponent and 52 for the mantissa. What about the Prime? If it works with 64 bits and the mantissa is truncated from 52 to 48 what are the 4 "missing" bits used for?

And how is a BCD number represented? I would say 48 bits for the mantissa as we have 12 digits (which is the same as in CAS, so it seems consistent). And the other bits?

Thank you for the answer

Reto

[dan_h]

Using Mathematica Home Edition 10.2 on my HP Pavilion, and default settings, 3.6^2-4*3.24=0. There is a SetPrecision command and maybe if a very large number of displayed digits were selected, some tiny discrepancy might have shown up.

[parisse]

(10-24-2015 12:48 PM)retoa Wrote:  So the prime uses a 48 bits mantissa to work with binary floating point, and not 52 like in IEEE 754 double precision. How will be a number represented?
I mean in double precision you have 1 bit for the sign, 11 for the exponent and 52 for the mantissa. What about the Prime? If it works with 64 bits and the mantissa is truncated from 52 to 48 what are the 4 "missing" bits used for?

Actually normalized floats have 53 bits of mantissa because the initial bit is always 1 hence not stored. There are 5 bits that are reserved in the giac::gen data for the type field, and the 48 remaining ones are for mantissa. The 5 missing bits are truncated to 0.

[cyrille de brébisson]

Hello,

>Why does prime only have 48 bits of mantissa for doubles?

Le me expand on what Bernard is saying.
The CAS does use a 8 bytes data structure to save a mathematical object.
The first 5 bits (Least significant bits) of this structure is the object type (real, integer, vector...), the rest of free for use for each possible individual type.

In the case of a structure being a real, then the rest of the 64 bits is the double. BUT since 5 bits are already used for the type, this double is truncated by 5 bits (which have been stolen to indicate the type). Hence the 48 bits of mantissa (the other bits being the sign and exponent).

One could wonder: Why make real less precise? But remember that in CAS worlds, precision is achieved through "perfect" integers, not through floating points numbers, so the reasoning is quire sound. If you want precision: use integers as floating points will ALWAYS be inaccurate, regardless of the mantissa size. hence it it not a problem to remove 5 bits of precision.

Cyrille

[retoa]

Thank you Bernard and Cyrille for the answer.

Actually with a 48 bits mantissa in CAS you obtain 12 significant digits, the same precision as in home, much more that what you normally need.

[parisse]

48 bits is more like 14 digits.

[Vtile]

The key here what none seems to take account is point were the calculator in approximation mode or in exact mode.

The given near zero answer is (approximately)correct if the calculator were approximation mode.

The given near zero answer is totally incorrect if the calculator were in exact mode.

The problem is logical not mathematical.

If the calculator is in exact mode set by user the CAS should behave according to that, while it is mathematically unorthodox solving answers like if user were using exact representation of given value instead of decimal value. In other words calculators CAS should expand (with silence or noting that "Unorthodox numerical format detected correcting user careless behaviour") the floating points to (36/10)²−4×(324/100) even if the user were typing the numbers in decimal format.

It is behaviour logic, coming from the user set logic rule called aprox/exact mode, not math in this case..

A engineers point of view.

Edit: HP 50g calculates it correctly both in aprox and exact with or without XQ command used (yep, I did RTFM to check the flag usage now when I know such command exist ) Tiny elements on and all xxxflows to error.

Code:

3: Rev #2.15
2: (3.600^2)-3.2400E0-4
1: 0.0000E0

[Joe Horn]

(10-31-2015 10:50 AM)Vtile Wrote:  ... HP 50g calculates it correctly both in aprox and exact with or without XQ command used...

So does Prime, in Home, which uses BCD, like the HP 50g. The 50g does not have a non-BCD binary floating-point mode like the Prime's CAS. If you want 50g floating-point accuracy on the Prime, use Prime's Home view. That's what it's for.

[Wes Loewer]

Here's one I like to show my students each year. In Excel, enter the following:

=(4/3-1)*3-1

You should get zero. (On the Prime you get −1.42108547152e−14.) Now put an extra set of parentheses around the whole thing in Excel:

=((4/3-1)*3-1)

You now get -2.22045E-16.

To see the significance of these two values, try

=((4/3-1)*3-1)*2^52 in Excel and ((4/3-1)*3-1)*2^46 on the Prime.