If this is in the manual, please forgive me and just point me in the right direction.

I'm doing the following on the WP-34s (2.1 1388)

2.5

Square root

x^2 (results in 2.5 in the display)

2

+/-

* (results in -5 in the display)

5

+

and the result is -2*10^(-15)

Why is that? Should I just update my firmware version?

*Edited: 12 Oct 2011, 5:45 a.m. *

This is perfectly acceptable, normal and most likely correct behaviour.

The calculator only has a finite number of digits and the intermediate results are rounded to this number of digits (16 in the case of the 34S). This means subsequent operations are working with numbers that aren't exactly what you entered.

That is a pretty old firmware version, lots has happened in the meantime. Bug fixes and improvements.

- Pauli

though 2.1 1664 returns the same answer. But it's not really a bug and so will will probably always do that.

Quote:

That is a pretty old firmware version, lots has happened in the meantime. Bug fixes and improvements.

I'm waiting for the final version before reflashing (and draining my batteries in the process).

Thanks!

For reference, I get the following answers from these calculators:

HP-25: 0

TI-89: 0

HP-48G: 2*10^(-11)

HP 33s: 2*10^(-11)

I wouldn't worry about an occasional reflash -- plug in flash and unplug doesn't take long and won't do much of anything to the battery life. Leaving (or forgetting) the calculator with cable plugged in will.

- Pauli

Results are rounded to 16 digits after every operation, so:

sqrt[2.5] = **1.581138830084189**665999..

rounded to 16 digits that is 1.581138830084190
1.581138830084190^2 = **2.500000000000001**0562...

rounded to 16 digits is 2.500000000000001

and then 5 - 2 * 2.500000000000001 = -2e-15

Thankfully it doesn't try to decide for you that that should be zero...

Cheers, Werner

Is that a hint on how long it will take to see the final firmware? ;)

I'm well aware that some rounding takes place with the root and square operations. What astonishes me more is the fact that the intermediate results 2.5 and 5 thereafter **looked** like they were exact but in fact weren't.

*Edited: 12 Oct 2011, 7:02 a.m. *

Use SHOW to see all the digits in the number. The display is only 12 digits long and numbers are 16 digits on the device. With a wider display, you'd have seen all the digits but that is not to be on this hardware.

- Pauli

Maybe I'm using SHOW the wrong way or it's buggy in my firmware version, but SHOW used on 2.5 and -5 in the calculation from posting #1 will not show any more decimal places. Isn't that what you meant?

EDIT: I flashed the newest firmware and now SHOW actually shows the whole mantissa.

*Edited: 12 Oct 2011, 8:41 a.m. after one or more responses were posted*

Some results from a random collection of calculators in my desk drawer:

Casio fx-991ES, Casio fx-4800p, TI-68: all 0

HP35s: 2*10^(-11) - intermediate results were inexact

TI36X: 2*10^(-11) - intermediate results looked exact

Update your firmware -- SHOW got changed a bit not too long ago.

- Pauli

*Edited: 12 Oct 2011, 7:29 a.m. *

HP 32s: 2*10^(-11)

HP 48g: 2*10^(-11)

Casio fx-7000g: 0

HP 12c: 0

HP 12c ARM (2009-11-19): 0

HP 35 (Non-Buggy, 1302A: 0

HP 28c: 2*10^(-11)

I have to say I'm a bit disappointed that an HP 35 and an old Casio seem to be more accurate than the 32s and 48g (at least in this case).

*Edited: 12 Oct 2011, 8:03 a.m. *

They aren't. Read Werner's post above and round the values to ten digits and you'll see why they *appear* to be more accurate.

- Pauli

I'm not a mathematician but I would say your conclusion is wrong. Those calcs that show 0 as a result might just not carry as many decimal places.

Ah. That makes sense. This is what I get for trying to carry on intelligent conversation at 7 AM.

I wonder if it wouldn't be nice to have some kind of indicator that pointed me to press SHOW. Otherwise I don't have a reason to doubt the exactitude of the result that is shown in case I get 5 with no decimal places. You know, something like the thing you do in fraction mode.

Final? What final?

We may continue development almost forever. Plans are to have stable releases from time to time on which you can rely. I can't say when the next point in time will be for a release.

Yeah, stable release is what I meant. I plan to get hold of one to use with my newly acquired overlays before you dare devils change them again! ;)

From the results here it looks like all the 10 digit machines with correct rounding return 0.

You should get the same result if you set WP 34S to SCI 10 and press RND after the sqrt and the x^2 operations.

Devilish folk are we! :-D

In fact we are discussing some keyboard changes. There are several options being discussed:

Minimalist: Just fix one or two idiosyncrasies such as having XTOA/ATOX on the keyboard which seems a bit wasteful. There are some diverging ideas concerning this approach.

Medium: Make an overhaul of the keyboard which will definitely require a new overlay. We have something up our sleeves for this approach, too.

Maximum: Complete redesign, assignable keyboard and some such... More likely to be implemented on new hardware.

HP45 returns 0.000000000 (at fix 9)

Quote:

From the results here it looks like all the 10 digit machines with correct rounding return 0.

...but of course that only applies to *this* problem and likely will not be the case for every one (or perhaps even most of them) like this....therefore, with functions in the mix which generate irrational results (like square root), it makes sense to use the 34S SHOW as a check. With this specific problem, I bet that ANY large-precision setting on the HP48/49/50 in conjunction with the LongFloat library will yield a small non-zero result (as it probably should).

Jake

It makes sense to check all digits only when in your application 2.10^{-15} is significantly different from zero.

In most of my practical applications, as soon as a result is less than a fraction of a millimeter, a millisecond, a milligram, a milliamp or a combination of theses, it's not harmful to consider it as null or negligible.

Last time I was measuring the surface of grass in my garden. I may have use the square root key to check my computations backward.

Are you serously stating that I have to use SHOW function to check that I was right at 2.10^{-15} meter precision ?

I was not attempting to count sub-atomic particles in my garden, I only have to get a rough idea of how much potting soil I have to buy !

Quote:

Are you serously stating that I have to use SHOW function to check that I was right at 2.10-15 meter precision ?
I was not attempting to count sub-atomic particles in my garden, I only have to get a rough idea of how much potting soil I have to buy !

Going back to the beginning of the thread, there was a specific problem suggested which had nothing to do with particles or gardens......there was no reference to anything, but the fact that the result was not exactly zero to 16 decimal places. It looked like everyone else in the thread accepted the premise that this was not necessarily a practical application related to "real-world" things such as measuring items to millimeter resolution or anything else. As a result, I would hope you would see the discussion for what it was - an exchange related purely to accuracy. No need to find fault with it, if that is what you were doing.

Jake

42s on iphone: -2*10^(-24)

Seems it has the highest precision so far.