HP calcs are really not that accurate..

[DA74254]

I just sat here, reading the reverb memory thread and my thoughts started to spin about the sqrt(2).

To put it straight; HP sucks at math!
At least in RPN or in "inexact" mode

I put 2 on the stack and sqrt it 5 times, then squared it back. All my 5 HP's returned 1.99999999979 instead of 2.0. That goes for the Android Pro version as well.

On my Android phone and tab, I have the free42 (of course), realcalc+, RPNcalc, Prime and the default calc.

*All*, except the HP returns 2 after the 5-step sqrt/squared.

HW 49G+, 50G (in exact mode) and Prime in CAS returned correct results, though.
Maxima math on my PC returned correct result.

I'm not angry with HP, just very, very disappointed..

[pier4r]

I guess Dieter and others already explained that returning 2 is like lying , but I'm sure they will explain it once again.

[BartDB]

Hi,

I recently explained this on another forum when someone complained about sin(pi) not equalling 0 on HP calculators in numerical mode. Here's my reply (the same argument goes for sqrt(2) ).

Getting a non-zero result for sin(pi) on any numerical device is an acceptable solution, as PI cannot be accurately represented in any numerical form. Any numerical device that returns 0 is using some means to round the result to what the user expects.

I have tried one of those calculators that give sin(pi) as 0:

I press PI, display shows 3.14159265359 then press SIN and answer is 0

Now I manually type 3.14159265359 then press SIN and answer is 2.067...E-13

Why is this calculator giving 2 different answers for what seems to be the same entry? Can I trust a calculator that gives different results for the same apparent entry?

Now when the symbol PI is used, we actually want the exact solution. As PI can never be exactly represented numerically, we have to use a symbolic solver - that is where CAS comes in.

It comes down to using the right tool for the job.

You want a calculator that gives "exact" answers when it's using a numerical solver. This involves tricks to get the expected answer (e.g. hidden extra digits), but how do we know these tricks won't trip us up in other ways?

You might be happy with the "tricks" approach, but I'd rather be in charge myself of what accuracy I want and that determines what tool I use.

[Massimo Gnerucci]

(12-01-2017 07:49 PM)DA74254 Wrote:  I just sat here, reading the reverb memory thread and my thoughts started to spin about the sqrt(2).

To put it straight; HP sucks at math!
At least in RPN or in "inexact" mode

I put 2 on the stack and sqrt it 5 times, then squared it back. All my 5 HP's returned 1.99999999979 instead of 2.0. That goes for the Android Pro version as well.

On my Android phone and tab, I have the free42 (of course), realcalc+, RPNcalc, Prime and the default calc.

*All*, except the HP returns 2 after the 5-step sqrt/squared.

HW 49G+, 50G (in exact mode) and Prime in CAS returned correct results, though.
Maxima math on my PC returned correct result.

I'm not angry with HP, just very, very disappointed..

Start here (pp. 16-17)

Quote: unavoidable error caused by using finite computers to approximate nonfinite processes

[Gerson W. Barbosa]

(12-01-2017 07:49 PM)DA74254 Wrote:  I put 2 on the stack and sqrt it 5 times, then squared it back. All my 5 HP's returned 1.99999999979 instead of 2.0. That goes for the Android Pro version as well.

On my Android phone and tab, I have the free42 (of course), realcalc+, RPNcalc, Prime and the default calc.

*All*, except the HP returns 2 after the 5-step sqrt/squared.

Make that 78 times and you will get 1.99999999963 on Free42. Your 12-digit HPs have only 3 guard digits and intermediate results are rounded to 12 digits. Free42 has 22 guard digits, so to say, and it does not round intermediate results.

The HP rounding philosophy is better explained in these old threads started by Rodger Rosenbaum;

What should you get?

What should we get, Part 2

[DA74254]

Thanks for all your answers. Sorry, thogh, for bringing up an "old" issue.

Anyway, I still feel that I'm a tad disappointed, that, in 2013 (time of the Prime purchase), we do not have more accuracy on the calcs.

I just tried my maxima program (http://maxima.sourceforge.net/) to 1024 decimals with "bfloat" command, the same, though "only" 2 iterations. It still returned 2.0 as the answer. (PC win10Pro, Intel i5 CPU)

In my opinion, there should be no reason that we should not have, say, at least 256 digits/decimal points accuracy. That goes for any device capable of doing "2+2".

Below, the transcript from maxima:

Code:

(%i7) bfloat (sqrt(2));


(%o7) 1.4142135623730950488016887242096980785696718753769480731766797379907324\
784621070388503875343276415727350138462309122970249248360558507372126441214970\
999358314132226659275055927557999505011527820605714701095599716059702745345968\
620147285174186408891986095523292304843087143214508397626036279952514079896872\
533965463318088296406206152583523950547457502877599617298355752203375318570113\
543746034084988471603868999706990048150305440277903164542478230684929369186215\
805784631115966687130130156185689872372352885092648612494977154218334204285686\
060146824720771435854874155657069677653720226485447015858801620758474922657226\
002085584466521458398893944370926591800311388246468157082630100594858704003186\
480342194897278290641045072636881313739855256117322040245091227700226941127573\
627280495738108967504018369868368450725799364729060762996941380475654823728997\
180326802474420629269124859052181004459842150591120249441341728531478105803603\
371077309182869314710171111683916581726889419758716582152128229518488472089694\
63386289156288277b0

(%i8) bfloat (sqrt(%));


(%o8) 1.1892071150027210667174999705604759152929720924638174130190022247194666\
682269171598707813445381376737160373947747692131860637263617898477567853608625\
380177750701515114035570922731623428688899241754460719087105038499725591050098\
371044920154845735674580904839940930900034977959080384896588430050411987170093\
790798209846252353739812817408181137808285520148422100609589324124459310350575\
191963029413832634742802798244080228008217292720586153666393704002382073085456\
530674477148598887334576271867838116547045872761271112699886784349301758614249\
701700541314551438919987437667621785161783177987307048236318734734842180537156\
986842636482761056228477995862896332939281687874758656034737919964594007561544\
437157418903039869712943062486253517341291535975311215446746159086477606517445\
957055930979119465756398917686972170262497475333629918606531157083493680769804\
948170607437684746785586528255014184649792489099515633782998595087643532396621\
477896547910454186934661861396145218563917026341604354229856108549326870868151\
71745404554548532b0


(%i9) bfloat (%o8^2);


(%o9) 1.414213562373095048801688724209698078569671875376948073176679737990732\
478462107038850387534327641572735013846230912297024924836055850737212644121497\
099935831413222665927505592755799950501152782060571470109559971605970274534596\
862014728517418640889198609552329230484308714321450839762603627995251407989687\
253396546331808829640620615258352395054745750287759961729835575220337531857011\
354374603408498847160386899970699004815030544027790316454247823068492936918621\
580578463111596668713013015618568987237235288509264861249497715421833420428568\
606014682472077143585487415565706967765372022648544701585880162075847492265722\
600208558446652145839889394437092659180031138824646815708263010059485870400318\
648034219489727829064104507263688131373985525611732204024509122770022694112757\
362728049573810896750401836986836845072579936472906076299694138047565482372899\
718032680247442062926912485905218100445984215059112024944134172853147810580360\
337107730918286931471017111168391658172688941975871658215212822951848847208969\
463386289156288277b0

(%i10) bfloat (%^2);


(%o10)                               2.0b0

[Paul Dale]

What are you trying to represent that requires so many digits?
How can you possibly measure something that accurately?

256 digits are far more than you'd need to represent the diameter of the universe in terms of the planck length.


Pauli

[brickviking]

DA74254 Wrote:In my opinion, there should be no reason that we should not have, say, at least 256 digits/decimal points accuracy. That goes for any device capable of doing "2+2".

Paul_Dale Wrote:What are you trying to represent that requires so many digits?
How can you possibly measure something that accurately?

256 digits are far more than you'd need to represent the diameter of the universe in terms of the planck length.

In addition, while computers have gobs of spare memory and awesome (!) floating point processors, calculators do not. Most calculators are not expected to be connected to the wall just to plain work (or charge their batteries after 9 hours of use), they're expected to work after 6 months (or more!) of use just the same as when the battery was first put in. This requires serious compromises in the choices of CPU or multifunction chip so as to make best use of the limited energy resources available from batteries.

As previously mentioned, the amount of precision you actually need is often very different from the amount of precision you want. It's also different from the amount of precision you can usefully create yourself due to tolerance factors. 5mm of tolerance in the amount of space required for a bridge would probably be acceptable given other environmental factors, however in the case of aeronautics, 5mm of tolerance on a flight from Auckland to Heathrow would be considered excessive, yet calculators can already give us that degree of precision (average of 10 dp, perhaps with 1-3 guard digits).

Let's not make this a "Schwanzvergleich" discussion.

(Post 138)

[Gerson W. Barbosa]

(12-01-2017 09:09 PM)DA74254 Wrote:  In my opinion, there should be no reason that we should not have, say, at least 256 digits/decimal points accuracy. That goes for any device capable of doing "2+2”

We can take advantage of long integer numbers in Exact mode on the 49/49G+/50g to get extended accuracy at least for division operations.

For instance, evaluate the following program with ‘d’ (number of decimal places) as an argument.

« PUSH RAD -105 CF -3 CF DUP .653 * 1.74 + IP R→I DUP 2 MOD + DUP 4 * OVER DUPDUP 1 - 1
FOR i i SQ SWAP / PICK3 + ROT SWAP -1
STEP INV NIP UNROT + 1 - 3 0 UNROT
FOR i i INV i 2 - INV - + -4
STEP - 4 * EXPAND FXND DUP SIZE R→I ALOG OVER - PICK3 * SWAP IQUOT + →STR DUP HEAD -51 FC? { "." } { "," } IFTE + SWAP TAIL + 1 ROT 2 + SUB POP
»

On real hardware you should try low ‘d’ (15 or 20, never 256), unless you don’t mind waiting or draining up your battery set.

[Joe Horn]

Those who prefer to be lied to, so as to hear what they want to hear, should buy non-HP calculators, which fudge the displayed results to look like what they think that the user probably wants to see, with warts shaved off and blemishes hidden behind cosmetics (aka "guard digits").

Those who prefer to be told the truth, and see EXACTLY what the result is, warts and all, should buy HP calculators, whose philosophy is "What You See Is What You Have".

All calculators are inaccurate internally. Some just hide that fact by lying to the user, and they get away with it because many users (e.g. DA74254) prefer to be lied to. We HP aficionados prefer the truth.

[Luigi Vampa]

"Joe Horn dixit"
1+
I love your last post ;Ox

"It is the mark of an educated mind to rest satisfied with the degree
of precision which the nature of the subject admits, and not to seek
exactness where only an approximation is possible."
Aristotle

[DA74254]

(12-01-2017 10:18 PM)Paul Dale Wrote:  What are you trying to represent that requires so many digits?
How can you possibly measure something that accurately?

256 digits are far more than you'd need to represent the diameter of the universe in terms of the planck length.


Pauli

I'm just nerdy.. I once made a "prime number finder" that took abt one hour to find 115 million primes (all primes below 4.294.967.295 as in unsigned long int)
And yes, I know exactly how big my land plot is in square plancks (just over 5,5x10^72)
So, for my opinion, the 256 was just arbitrary, based on the todays cpu capabilities.

(12-01-2017 10:37 PM)brickviking Wrote:  In addition, while computers have gobs of spare memory and awesome (!) floating point processors, calculators do not. Most calculators are not expected to be connected to the wall just to plain work (or charge their batteries after 9 hours of use), they're expected to work after 6 months (or more!) of use just the same as when the battery was first put in. This requires serious compromises in the choices of CPU or multifunction chip so as to make best use of the limited energy resources available from batteries.

As previously mentioned, the amount of precision you actually need is often very different from the amount of precision you want. It's also different from the amount of precision you can usefully create yourself due to tolerance factors. 5mm of tolerance in the amount of space required for a bridge would probably be acceptable given other environmental factors, however in the case of aeronautics, 5mm of tolerance on a flight from Auckland to Heathrow would be considered excessive, yet calculators can already give us that degree of precision (average of 10 dp, perhaps with 1-3 guard digits).

Let's not make this a "Schwanzvergleich" discussion.

(Post 138)

Regarding the power drain - my phone seems to cope with "massive precision", thoug, as I've learned from this discussion, that may be a lie..
And no, a "mine-is-bigger-than-yours" discussion was not my intension.

(12-02-2017 01:36 AM)Joe Horn Wrote:  Those who prefer to be lied to, so as to hear what they want to hear, should buy non-HP calculators, which fudge the displayed results to look like what they think that the user probably wants to see, with warts shaved off and blemishes hidden behind cosmetics (aka "guard digits").

Those who prefer to be told the truth, and see EXACTLY what the result is, warts and all, should buy HP calculators, whose philosophy is "What You See Is What You Have".

All calculators are inaccurate internally. Some just hide that fact by lying to the user, and they get away with it because many users (e.g. DA74254) prefer to be lied to. We HP aficionados prefer the truth.

Everybody is lied to every day and everybody hears what everybody thinks everybody wants to hear. So no, I do not want to be lied to any more than the next person.

Not wanting to step on any toes (which I accidentally did, apparently), I probably should approach this in my first post more like a question than a statement. I did learn something here, which is good. I also learned that the binary operation modus of electronics never can represent decimal output accurate (in short). (This last sentence probably don't sound correct, but English is not my native language).

(12-02-2017 01:59 AM)Luigi Vampa Wrote:  "Joe Horn dixit"
1+
I love your last post ;Ox

"It is the mark of an educated mind to rest satisfied with the degree
of precision which the nature of the subject admits, and not to seek
exactness where only an approximation is possible."
Aristotle

I should have listened to Aristotle..

[Paul Dale]

(12-02-2017 07:42 AM)DA74254 Wrote:  And yes, I know exactly how big my land plot is in square plancks (just over 5,5x10^72)

Did your property surveyors really measure each dimension to 36 or more decimal places?



Pauli

[emece67]

(12-02-2017 07:42 AM)DA74254 Wrote:  I also learned that the binary operation modus of electronics never can represent decimal output accurate (in short). (This last sentence probably don't sound correct, but English is not my native language).

To my knowledge, most (if not all) hp calculators do not work internally in binary, but in decimal. Well, in fact they do work in binary, as they use 2-level digital circuitry, but use BCD (Binary Coded Decimal) to represent the numbers, thus the maths are done in decimal.

The root of the problem is that they use a finite number of digits (decimal or binary) to represent numbers.

Regards.

p.s. As a note, an wp34s returns 2.000000000000006 (shown as 2, as the display holds 12 digits only). In double mode it returns 1.999999999999999999999999999999974.

p.s. 2. Tried what happens when you subtract 2 from the result?

[DA74254]

(12-02-2017 08:32 AM)Paul Dale Wrote:  

(12-02-2017 07:42 AM)DA74254 Wrote:  And yes, I know exactly how big my land plot is in square plancks (just over 5,5x10^72)

Did your property surveyors really measure each dimension to 36 or more decimal places?



Pauli

I was just checking the surveyors accuracy

Btw, I just found out that the diameter of the observable universe is in the area of 54 decillion (longscale numbering) PL

[DA74254]

(12-02-2017 08:49 AM)emece67 Wrote:  p.s. 2. Tried what happens when you subtract 2 from the result?

In which program/unit?

I tried, just now on the Prime and it shows +0,00000000021. (Home/RPN mode)
In CAS (exact mode) it shows 0.

[jebem]

This is an issue that keeps coming to our attention and it will continue because it only shows the shortcomings of the calculators when comparing its results with what common people (like me). knows as the true answer.

Even HP did lie on some models (that are not welcomed here) exactly to give the expected answers common people believes are the correct ones. In defense of HP they explain this small lies in the documentation.

Divide 1 by 3 and multiply the result by 3 and any non math educated person knows the answer.
But this seems impossible to solve on a computer, no matter how many digits it can handle, unless some form of lie or trick is used.
Well, the computer is right and the common people too. It is just two different ways to look to the same problem.

[DA74254]

I have been lied to, and I don't like it.

Well, some good came out of this. My slight ADHD/ADD, which demands things set square still prefers the "good" answers from the lying calcs, though I myself, upon reading the HP article linked here and the explanations from you, sets things "square" in a better way.

With the new understanding, and the 2^3=7,99999999998 issue freshly in mind, I'll settle for the acceptance that infinite answers can't be reproduced in a finite setting.
And, using the HP calc formula for cube calculations, I reproduced the same answer in Maxima. Thus, concluding that even Maxima lies to me at will.

Thanks again, and to emphasize; it was not my intension to step on anyones toes.

[larthurl]

(12-01-2017 08:23 PM)Massimo Gnerucci Wrote:  

(12-01-2017 07:49 PM)DA74254 Wrote:  I just sat here, reading the reverb memory thread and my thoughts started to spin about the sqrt(2).

To put it straight; HP sucks at math!
At least in RPN or in "inexact" mode

I put 2 on the stack and sqrt it 5 times, then squared it back. All my 5 HP's returned 1.99999999979 instead of 2.0. That goes for the Android Pro version as well.

On my Android phone and tab, I have the free42 (of course), realcalc+, RPNcalc, Prime and the default calc.

*All*, except the HP returns 2 after the 5-step sqrt/squared.

HW 49G+, 50G (in exact mode) and Prime in CAS returned correct results, though.
Maxima math on my PC returned correct result.

I'm not angry with HP, just very, very disappointed..

very interesting. Thanks

Start here (pp. 16-17)

Quote: unavoidable error caused by using finite computers to approximate nonfinite processes

[Gerald H]

Aristotle? He claimed women have a different number of teeth from men. Discredited.

I'm reminded of Robert Recorde:

http://www.hpmuseum.org/forum/thread-3223.html