HP Prime Miscalculating

10232015, 02:35 AM
Post: #1




HP Prime Miscalculating
When I try to calculate 3.6^24*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?


10232015, 05:41 AM
Post: #2




RE: HP Prime Miscalculating
(10232015 02:35 AM)luc4as Wrote: When I try to calculate 3.6^24*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 48bit 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 floatingpoint 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 <0ɸ0> Joe 

10232015, 02:54 PM
(This post was last modified: 10232015 03:09 PM by Tim Wessman.)
Post: #3




RE: HP Prime Miscalculating
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. TW Although I work for HP, the views and opinions I post here are my own. 

10232015, 04:43 PM
Post: #4




RE: HP Prime Miscalculating
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.50.20.3 will give 1.776e15 

10232015, 04:54 PM
Post: #5




RE: HP Prime Miscalculating
Ah right, I stand corrected.
TW Although I work for HP, the views and opinions I post here are my own. 

10232015, 07:38 PM
Post: #6




RE: HP Prime Miscalculating
Hello
Is there a way to obtain that result in Wolfram Mathematica? I mean that 3.6^24*3.24 = 5.6843*10^(14) , like in the HP Prime? 

10232015, 09:33 PM
Post: #7




RE: HP Prime Miscalculating
I do not know Wolfram Mathematica very good, but in Maxima you can do:
3.6b0^24*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... :) 

10232015, 10:04 PM
Post: #8




RE: HP Prime Miscalculating
In Wolfram Alpha if you calculate:
0.5 to binary  0.3 to binary  0.2 to binary you obtain in quadprecision (you have to click on "more" bottom right): 0000000000000000000000000000003c which is not 0, so 0.50.30.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. 

10232015, 10:12 PM
Post: #9




RE: HP Prime Miscalculating
(10232015 07:38 PM)Archanus Wrote: Hello Code: FromDigits[RealDigits[N[3.6],2,48],2] 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)^22 Nigel (UK) 

10242015, 02:20 AM
(This post was last modified: 10242015 02:32 AM by Archanus.)
Post: #10




RE: HP Prime Miscalculating
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 "MiniQuark"? jaja 

10242015, 06:37 AM
Post: #11




RE: HP Prime Miscalculating
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). 

10242015, 12:48 PM
Post: #12




RE: HP Prime Miscalculating
(10232015 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: 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 

10242015, 02:14 PM
Post: #13




RE: HP Prime Miscalculating
Using Mathematica Home Edition 10.2 on my HP Pavilion, and default settings, 3.6^24*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.


10252015, 09:13 AM
Post: #14




RE: HP Prime Miscalculating
(10242015 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?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. 

10262015, 06:25 AM
Post: #15




RE: HP Prime Miscalculating
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 Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP. 

10302015, 01:34 PM
Post: #16




RE: HP Prime Miscalculating
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. 

10312015, 06:34 AM
Post: #17




RE: HP Prime Miscalculating
48 bits is more like 14 digits.


10312015, 10:50 AM
(This post was last modified: 10312015 11:07 PM by Vtile.)
Post: #18




RE: HP Prime Miscalculating
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 

11012015, 02:12 AM
Post: #19




RE: HP Prime Miscalculating
(10312015 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 nonBCD binary floatingpoint mode like the Prime's CAS. If you want 50g floatingpoint accuracy on the Prime, use Prime's Home view. That's what it's for. <0ɸ0> Joe 

11012015, 01:16 PM
Post: #20




RE: HP Prime Miscalculating
Here's one I like to show my students each year. In Excel, enter the following:
=(4/31)*31 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/31)*31) You now get 2.22045E16. To see the significance of these two values, try =((4/31)*31)*2^52 in Excel and ((4/31)*31)*2^46 on the Prime. 

« Next Oldest  Next Newest »

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