SwissMicros Calculator Forum

rudi wrote: ↑

Thu Jun 23, 2022 12:27 pm

Brianetta, let's play a game; You are a computer, that can calculate with 1 digit and four decimal places.

First you get the job to calculate 1 / 3:
That results in 0,3333

Now you get the job to calculate 3 * 0,3333:
That results in 0,9999

No errors occoured, but due to rounding and limited precission, you found that (1/3)*3 is not 1 but 0,9999

Yes. I understand the principle entirely. It's something we accept and work around.

Brianetta wrote: ↑

Thu Jun 23, 2022 12:31 pm

I understand the principle entirely. It's something we accept and work around.

It's worse: it's something we have to accept. And we can't work around it - we can take it into account only.

What would be nice, though, is some indication whether a number displayed on screen has been rounded, as can be seen by using the SHOW function. When one divides 1 by three, then multiplies the result by three, the display looks like an integer value. The RND function works in all display modes except All, where it doesn't round to the displayed value (or do anything, as far as I can tell).

One of the things I liked about my school calculator, the TI-68, was that it worked to 13 places internally, and rounded to 10 places when it was done. If you want to maintain 13 places over several operations, it had an option (and an annunciator) for that. This sort of automatic rounding was neat.

Rounded to 10 places "when it was done"?

If you round to 10 places after every operation, you'll get 1 / 3 = 0.3333333333, then after multiplying that by 3 you get 0.9999999999, which is still not 1. The kind of magic you seem to be looking for would require the calculator to know that it shouldn't round after the first operation, but it should round after the second, because only then is the entire calculation "done." How is the calculator supposed to know?

(Regarding RND in ALL mode: it rounds to 12 digits since version 3.0.11.)

Thomas Okken wrote: ↑

Wed Jun 22, 2022 9:07 am

J-F Garnier wrote: ↑

Tue Jun 21, 2022 9:25 am

Nice finding ! This is a minor Free42 accuracy flaw:

Doing SQRT( 0+1i ) is giving:
0.7071067811865475244008443621048490 +
0.7071067811865475244008443621048491 i

Since the real and imag parts are not equal (as they should be), squaring back this number doesn't give exactly 0 for the real part.

Indeed! Complex sqrt is missing special cases for pure real and pure imaginary arguments. That's an oversight.

I thought you handled the pure imaginary ones already, Thomas - but only for Y/2 being a perfect square, I think.
Werner

Thomas Okken wrote: ↑

Thu Jun 23, 2022 1:53 pm

Rounded to 10 places "when it was done"?

If you round to 10 places after every operation, you'll get 1 / 3 = 0.3333333333, then after multiplying that by 3 you get 0.9999999999, which is still not 1. The kind of magic you seem to be looking for would require the calculator to know that it shouldn't round after the first operation, but it should round after the second, because only then is the entire calculation "done." How is the calculator supposed to know?

(Regarding RND in ALL mode: it rounds to 12 digits since version 3.0.11.)

It wasn't an RPN calculator, you entered an algebraic expression onto the display that was executed all at once. I doubt it could be done sanely on a stack calculator. My 42 has a precision variable on it and a rounding program that I wrote that rounds to the number of figures in that variable. I use that before comparing any number to zero in a program.

That RND change is really encouraging. I just have to wait for it to be ported to the DM42.

whuyse wrote: ↑

Thu Jun 23, 2022 2:03 pm

I thought you handled the pure imaginary ones already, Thomas - but only for Y/2 being a perfect square, I think.

Yes, that was in 2.0.21.

This latest change makes sure that Im(z) = ±Re(z) exactly, for all z = sqrt(i*x).

Walter wrote: ↑

Thu Jun 23, 2022 11:17 am

And while we're at it:

J-F Garnier wrote: ↑

Tue Jun 21, 2022 9:25 am

Here is an example of a similar accuracy flaw on the HP-42S:
SQRT (0 + 0.4652 i) gives:
0.482286222071 +
0.482286222072 i
and squaring it back gives: -9.65E-13 + 0.4652 i

Dealing with the same problem on the WP43S:
SQRT returns
0.482286222071499778398073106978605 +
0.482286222071499778398073106978605 × i.
Squaring it back gives 0. + i × 0.4652 (actually 0. + i × 0.4652000000000000000000000000000001).

And for Free42:
SQRT returns
0.4822862220714997783980731069786050 +
0.4822862220714997783980731069786049 i
Squaring it back gives 1.e-34 + 0,4652i (exact imag part but small real part residual).

Well, both almost as good, but we may ask ourself: what is the best answer?
I tend to see Free42's answer slightly better since the absolute value |z| of the squared back result is closer to (actually exactly, rounded to 34 digits) 0.4652.
But this is true but for that example, there may be cases where Free42 gives inferior answers relative to the WP34S.

BTW, this example was aimed to illustrate the same flaw on the HP-42S, the cause for this machine was that the real and imag part values are very close to the fence between rounding up or down to 12 places: 0.482286222071(4998)
So the 12-digits numbers 0.482286222071 and 0.482286222072 are (almost) equally good.

Oh, a side question: I thought that the WP34S was based on the same Intel BCD library as Free42, is that correct?

J-F

No, the WP34S uses the IBM decNumber library.

J-F Garnier wrote: ↑

Thu Jun 23, 2022 5:39 pm

Well, both almost as good, but we may ask ourself: what is the best answer?
I tend to see Free42's answer slightly better since the absolute value |z| of the squared back result is closer to (actually exactly, rounded to 34 digits) 0.4652.

I tend to say the WP43S result is the better one because it's the correctly rounded result.
0.4822862220714997783980731069786049561748... + i×0.4822862220714997783980731069786049561748... is the correct result according to WolframAlpha.
So the correctly rounded result to 34 digits is:
0.4822862220714997783980731069786050 + i×0.4822862220714997783980731069786050