Floating Point Number Discussion from Webboard BBS

Sunday, May 02, 1999

Keywords: 	  Floating point precision

Q: (USER):

Is it correct that floating point numbers in WinBatch are stored as "doubles" in 8 bytes? That would
suggest precision of at least 15 digits, but if you do:

f = 49.000000015
Message("Lost some digits", f)
f = f - 49.0
Message("Digits really gone!", f)

Now, I'm not complaining, just trying to understand the limits of what I'm working with. Is it possible to
store a number like this and preserve the .000000015 on the end, aside from keeping it in a string?

Thanks! 

A: (WINDOWWARE):

Ummm, Floating point number representation is an uncommonly complex process.

1) To make matters worse, we've been altering the display of floating point numbers in WinBatch.

2) As I understand the situation WinBatch computes with 12 or 13 digits of precision but will only display
7 or 8 to minimize the effect of error propagation.

3) When I try your example in the 99F version I get different results. However I don't think they are the
results you might expect.

So back to 

49.000000015

This is a strange number. The precision involved is incredible. The accuracy involved is questionable. Is it
a real measurements of some sort, or simply a test number?

49,000,000,015

For example a number like that claims that if you have 49 billion pounds of stuff, you can measure to the
accuracy of + or - one pound. Unlikely. In any case beyond the computational ability of WinBatch. If you
are really into such numbers, then you want a product like Mathematica from Wolfram Research. its
supposed to be quite nice and easily able to maintain 100 digits of precision.

Q: (USER):

On 5/2/99 7:32:20 PM, Martin W wrote:
>So back to 
>
>49.000000015
>
>
>This is a strange number.
>The precision involved is
>incredible. The accuracy
>involved is questionable. Is
>it a real measurements of some
>sort, or simply a test number?

I'm testing a conversion procedure for different coordinate systems based on long integers. If you convert
from a float-based coordinate system, say running between -50.0 and +50.0, to a full-scale long
integer-based system running from -2,147,483,647 through +2,147,483,647, the 5 on the end of
49.000000015 changes the result.

>49,000,000,015
>
>For example a number like that
>claims that if you have 49
>billion pounds of stuff, you
>can measure to the accuracy of
>+ or - one pound. Unlikely.

Except in a computer. This number relates to an internal computation, not a physical object.

>In any case beyond the
>computational ability of
>WinBatch.

The number is, in a fairly complex way, related to a program flow control issue, so changing to another
language or product doesn't solve the problem. I'm not trying to get an answer to a problem, I'm trying to
determine floating point precision in WinBatch.

The limitation I see with this simple example suggests a precision *between* float and double, but
dissecting the bits of some simple numbers indicates standard IEEE double. Since that's an unusual
situation, I'd like to understand it more so I can better predict the precision behavior of floats in
WinBatch.

>If you are really
>into such numbers, then you
>want a product like
>Mathematica from Wolfram
>Research. its supposed to be
>quite nice and easily able to
>maintain 100 digits of
>precision.

What I'd like to know is, what is the precision of a float stored internally in WinBatch? Is it stored as an
8-byte IEEE double-precision floating point value (standard for doubles in C)? If so, wouldn't it in fact
store numbers with much *higher* precision than this one? If not a standard double, how many bytes and
what format?

A: (WINDOWWARE):

Numbers are stored as IEEE 8 byte doubles.

wsprintf routine are used to convert for display purposes.

I've lost track of how the numbers are converted from the input stream into the IEEE doubles. That may
be a part of the critical issue here.

This routine give a peek into what is going on. I'm suspecting the input scan in loosing digits...

f=49.0
g=1.5e-8
message(f,g)
h=f+g
j=h-f
message(h,j)

Q: (USER):

Thanks - clearly WinBatch can handle the *storage* with that much precision. This really clarifies the
issue.

On 5/3/99 7:21:22 PM, Martin W wrote:
>This routine give a peek into
>what is going on. I'm
>suspecting the input scan in
>loosing digits...
>
>
>f=49.0
>g=1.5e-8
>message(f,g)
>h=f+g
>j=h-f
>message(h,j)
>
>
>WindowWare Home
>PageDownloadsWorld Wide School

A: (WINDOWWARE):

It appears the input routines give up after 9 significant digits.

Q: (USER):

On 5/2/99 7:23:10 PM, Martin W wrote:
>Ummm, Floating point number
>representation is an
>uncommonly complex process.
>
>1) To make matters worse,
>we've been altering the
>display of floating point
>numbers in WinBatch.

Not an issue in this example. The issue is lost digits of precision in the internal storage, not display.

>2) As I understand the
>situation WinBatch computes
>with 12 or 13 digits of
>precision but will only
>display 7 or 8 to minimize the
>effect of error propagation.

Also not an issue in this example. This example shows lost digits which are *really* lost, not just not being
displayed.

>3) When I try your example in
>the 99F version I get
>different results. However I
>don't think they are the
>results you might expect.

Different from what? I didn't include output in the example, just code.

A: (WINDOWWARE):

f = 49.000000015
Message("Lost some digits", f)

99F/G -> 49.0

f = f - 49.0
Message("Digits really gone!", f)

99F/G -> 7.10542736e-015
That kind of number usually just reprsents floating point "noise". The system did the best approximation it
could to store 49.000000015 I think it gave up long before it reached the ...015 part. 

Decimals(-3)
f = 49.000000015
Message("D-3",f)
Decimals(-2)
f = 49.000000015
Message("-2",f)
Decimals(-1)
f = 49.000000015
Message("D-1",f)

But back to your original question...can Winbatch maintain those numbers "as-is". The answer is no.

For example if the number is a part number of a product according to some scheme then WinBatch will
totally trash that number. I would put a PN in front of it and treat it as a string.

f="PN49.00000000000000000000000000015"
Message("F",f)

If the number is some kind of physical measurement what ever Winbatch does should be approximately
fine.

If the number is some kind of high-precision physical measurement and you need the precision, then you
probably need a different product.

Article ID:   W14143

Filename:   Floating Point Number Discussion.txt

File Created: 1999:06:09:14:33:56

Last Updated: 1999:06:09:14:33:56

Database Search

TechHome

Floating Point Number Discussion from Webboard BBS

Sunday, May 02, 1999