Math rounding...

[Aldo Vitagliano]

When variables are set to EXT type, id does not matter whether the computation is run in a single expression or intermediate results are stored into variables and then reused to complete the calculation.

On the other hand, when variables are set to DBL type, it does sometimes matter, and a better accuracy is generally attained if the computation is run in a single expression.

This because the FPU register use 80 bit precision anyhow, and when an expression is all evaluated inside the FPU registers, intermediate results are not rounded-off to 64 bits precision (as they are when transfer-to-memory takes place), resulting in a lower round-off error.

The following code shows the point:

[FONT="Courier New"][SIZE="3"]   
DEFDBL A-Z
FUNCTION PBMAIN()
   A=10*ATN(10)
   B=SIN(A)
   PRINT USING$("##.################",B)
   C=SIN(10*ATN(10))
   PRINT USING$("##.################",C)
   X##=10*ATN(10)
   Y##=SIN(X##)
   Z##=SIN(10*ATN(10))
   PRINT USING$("##.#################",Y##)
   PRINT USING$("##.#################",Z##)
   WAITKEY$

END FUNCTION  [/SIZE][/FONT]

[Eddy Van Esch]

...from your tables or whatever you used.

I used my arbitrary precision floating point math library that I am developing.

Kind regards

[Michael Mattias]

> should have mentioned that.

Yes, you should have.

However, it is interesting to note the 'code-calculated' result is the rounded result from your tables or whatever you used.

[Eddy Van Esch]

No it is not a better approximation.

Yes, it is ... because the large figure was not calculated using standard PB data types. I should have mentioned that.

..In the above with its forty-nine decimal digits, the last thirty-one may as well be pot luck.

No, they are correct. I could have given you 5000 decimal digits and they would still be correct...

Kind regards

[Michael Mattias]

0.839676090553114 is the better approximation of the two, but []
.839676090553113541535296114291647723607243553607 57
is an even better one.

No it is not a better approximation. Even using EXT types you can only rely on 18 decimal digits. In the above with its forty-nine decimal digits, the last thirty-one may as well be pot luck.

>you've chopped off the remaining digits so you lose accuracy

No, you didn't lose accuracy. You have lost display digits. (which may be meaningless anyway as per above).

You cannot get neither blood from a turnip nor more than 18 accurate decimal digits from an EXTENDED data type.

[Paul Dixon]

Steven,
it's because the intermediate result has more digits than are displayed and when you type in the displayed value of 14.7112767430373 you've chopped off the remaining digits so you lose accuracy.
Try this and you'll see some of the missing digits.

x##=10*ATN(10)
PRINT x##
PRINT STR$(x##,18)

Paul.

[Steven Pringels 3]

Forget about it. issue got solved.

[Eddy Van Esch]

Ok, it's minor but which one is now correct ?
The .839676090553114 or the .839676090553138 ?

But to answer your question :
0.839676090553114 is the better approximation of the two, but this:
0.83967609055311354153529611429164772360724355360757
is an even better one.

Kind regards

[Steven Pringels 3]

eh, sorry Eddy, it's Monday morning he... your point is ?

[Eddy Van Esch]

I would have expected that these would provide slightly different results, but they all produce
0.839676090553113542
(which closely matches:
0.83967609055311354153529611429164772360724355360757 )
:

    msgbox STR$(SIN(10 * ATN(10)), 18)
    msgbox STR$(SIN(10.0## * ATN(10.0##)), 18)
    aaa## = ATN(10.0##)
    aaa## = 10.0## * aaa##
    aaa## = SIN(aaa##)
    msgbox STR$(aaa##, 18)

Kind regards

[Steven Pringels 3]

Hi everybody,

It's me again... sorry

I have the following problem.

Consider the function

10 * ATN(10)

which returns 14.7112767430373

Then I would take the sinus of it by

Sin(14.7112767430373) which results in .839676090553138

Now, since I don't like to take those intermediate steps I like to do

SIN(10 * ATN(10))

which gives me almost the same result: .839676090553114

Ok, it's minor but which one is now correct ?

The .839676090553114 or the .839676090553138 ? Then, does it even matter if it's
like 24 (ok, what do you call 15 numbers after the decimal ?)

Sorry for disturbing this peaceful day

Steven