What kind of error checking for underflow and overflow?

[Conrad Hoffman]

I'm just curious, mostly about underflow. What kind of error checking, if any, does the compiler do (with error checking turned on and off) for underflow. Do values very close to zero simply set to zero? What do you do in a case where this would matter? At the other end, how do you predict overflow without actually doing a calculation- which would cause the overflow you want to avoid. Does overflow and/or underflow cause any problem in terms of stability, or is it just a matter of reaching a limit? No, math is not my strong point!

[Paul Dixon]

Conrad,
there is no underflow or overflow checking.
Integer divide by zero will crash your program.
Other errors can give undefined results.

Worse, the compiler circumvents the FPU's built in error checking which would otherwise work very well on all floating point calculations and would even give well defined results for divide by zero and underflows.
The solution is to either make sure you don't allow your calculations to over/underflow or to code them yourself in ASM when you can check for such errors.

Paul.

[Michael Mattias]

The solution is to either make sure you don't allow your calculations to over/underflow or to code them yourself in ASM when you can check for such errors

Sounds like some functions which some kind soul should code up and post in Source Code Forum.... e.g.

FUNCTION Divide (dividend as something, divisor as something, _
                        result as something)  AS LONG
 .... 
END FUNCTION
FUNCTION Multiply (multiplicand1 AS something, multiplicand2 as something, _ 
                            result as something ) AS LONG 
...
END FUNCTION

etc, etc

Returns: 0 = success and result is in result
TRUE = overflow or underflow

Something like that...

[Michael Mattias]

Oh yeah, almost forgot...

You can always send in a new feature suggestion:
"Please support numeric overflow and underflow errors via compiler directive something like:"

#ERROR OVERFLOW ON|OFF   ' default off = what it is today

"They" say the more who ask for a feature, the more likely it is to appear in a future release

Note: There will be a run-time performance penalty for this feature. It may or may not be worth it in your particular application.

MCM

[Paul Dixon]

Michael,
I'm sure it wouldn't be difficult to do it that way but it would be very slow with the overhead of the function calls and would mean rewriting all your mathematical code to use them instead of the much easier built in functions.

Paul.

[Michael Mattias]

it would be very slow with the overhead of the function calls and would mean rewriting all your mathematical code to use them instead of the much easier built in functions.

Paul, you've been doing this long enough to know there ain't no such thing as a free lunch.

If you want overlow checking, you pay for it.

[Paul Dixon]

Michael,
I paid for it a long time ago by learning how to program in ASM so I can write specific FP routines for the task at hand.

Writing more general purpose routines which anyone could easily drop into their own code is a lot more troublesome but I'll have a think about it.

It would probably be easier to teach you ASM.

Paul.

[Michael Mattias]

>It would probably be easier to teach you ASM.

I doubt that very much.

This old joke provides the reference:

Q: How many psychiatrists does it take to change a lightbulb?
A. Only one, but it takes a very long time and the lightbulb has to want to change.

[Conrad Hoffman]

I think I just don't understand this very well. Consider the following, which I think is illegal in several ways-

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG

    DIM A AS SINGLE
    DIM B AS SINGLE
    DIM C AS SINGLE
    
    A = 8.43E-37
    B = 8.43E-37
    C = A - (B/2)
    ? FORMAT$(C,18)
 
END FUNCTION

A SINGLE is legal from +8.43E-37 to -8.43E-37 according to the help. I don't see zero in there, what does that mean? Anyway, the help also says all calculations are done in EXTENDED precision. I seem to be able to display an extended precision result, but with rounding at the SINGLE precision point. So what, exactly, is a SINGLE, and is there any advantage in using one? Also, can I rely on values in the "no man's land" near zero to act in a predictable way? It's obvious that everybody's programs aren't crashing, and I think it was reasonable for PB to take the road they did for improved performance, at least for most applications, but more details about what happens at the limits would be greatly appreciated. For some things, say optical ray tracing, or brute force numeric methods, where an error term is being forced to zero, the behavior at the limits would seem to be important.

[Paul Dixon]

Conrad,
three different FP formats are in use.
SINGLE, DOUBLE and EXTENDED although different platforms may refer to them by different names.

A SINGLE is only 4 bytes so you can store lots more of them but they have limited range
A DOUBLE is 8 bytes so you can store half as many but they have more precision and wider range
An EXTENDED is 10 bytes, you can store less but they have even more range and precision.

Each therefore has its uses.

Internally to the FPU all numbers are EXTENDED. Any other format is converted to EXT on loading and EXT is converted to the other format on saving. All calculations are done on EXT precision values.


Your little program is showing how the FPU tries its best even when you don't expect it. It's a nice piece of hardware!
Numbers are stored in a NORMALISED format with 1 bit before the binary point and all the other bits after the point. Equivalents in decimal numbers, we'll say 4 digit mantissa and 1 digit exponent as an example, would be:

 1234  = 1.234 E3
  234  = 2.340 E2
 0.005 = 5.000 E-3

Always one digit before the point. That's normalised.

But right at the limit of what can be stored there is room to continue usefully storing data but at less precision. In the decimal example above, the smallest value that can be stored is:

1.000 E-9 = 0.000 000 001

But if we allow the format to change so that the digit before the point need no longer be non-zero then we can fit a smaller range of numbers in:

0.123 E-9 = 0.000 000 000 123  'but note that we only have 3 digits  precision now, not 4

or even as small as:

0.001 E-9 = 0.000 000 000 001  'and here we only have 1 digit precision.

In the FPU these numbers are called DENORMALISED.

Eventually, of course, the number gets so small that it can no longer be represented in that format and the number undeflows.

This is all explained in much more detail than I can go into here if you read the Intel manual:

http://download.intel.com/design/PentiumII/manuals/24319002.PDF

Look at Chapter 7.

You could also try running this program and see how the bits in the exponent and mantissa change as the size of the number is repeatedly halved.

Paul.

FUNCTION PBMAIN () AS LONG

DIM p AS LONG PTR
DIM c AS SINGLE

c=1324
p=VARPTR(c)
     
FOR t& = 1 TO 16
    PRINT
    PRINT "S EEEEEEEE MMMMMMMMMMMMMMMMMMMMMMM"
    FOR r& = 1 TO 10
        c=c/2
        k$=BIN$(@p,32)
        PRINT LEFT$(k$,1);" ";MID$(k$,2,8);" ";RIGHT$(k$,23);" ";c

    NEXT

    WAITKEY$
NEXT
        
END FUNCTION

[Michael Mattias]

A SINGLE is legal from +8.43E-37 to -8.43E-37 according to the help.

My 9.0 help says, " Single-precision values can contain decimal points and have a range of +/- 8.43*10^-37 to 3.40*10^38," which range definitely includes zero.

So what, exactly, is a SINGLE, and is there any advantage in using one

That a variable is a SINGLE, DOUBLE or any other type refers to the internal storage format used, which affects both the size of the data item in memory and the available scale and precision inherent in it.

You should use SINGLE when it suits your application.

Bear in mind, however, that when performing any arithmetic, the scale and precision of the result will never be greater than the lowest scale and precision of any one operand.

[Gösta H. Lovgren-2]

JFF, here's Pauls's code in PB9. Results are in the clipboard for each iteration. A little easier to see results by pasting into a text editor (not that I understand anything much about ASM or mantissas).

(Note it appears Using$ doesn't handle all those places very well. The second "C = " doesn't show up until Iteration 4.)
'

Function PBMain () As Long
Dim p As Long Ptr
Dim c As Single
c=1324
p=VarPtr(c)
 
For t& = 1 To 16
     s$ = s$ & Using$("Iteration #,    c = #,###.########", t&, c) & $CrLf 
    s$ = s$ & Using$("c = ########.################################ (32 places)",  c) & $CrLf 
 
 
 
    s$ = s$ & "S   EEEEEEEE   MMMMMMMMMMMMMMMMMMMMMMM" & $CrLf 
    For r& = 1 To 10
        c=c/2
        k$=Bin$(@p,32)
        s$ = s$ & Left$(k$,1) & "   " & Mid$(k$,2,8) & "   " & Right$(k$,23) & "   "& Str$(c) & $CrLf 
      'PRINT LEFT$(k$,1);" ";MID$(k$,2,8);" ";RIGHT$(k$,23);" ";c
    Next
    s$ = s$ & $CrLf 
Next
 ClipBoard Set Text s$ To x&       
 ? s$
End Function                 
'

[Conrad Hoffman]

Michael, I don't see how that range includes zero. 10^-37 is a very small number, and +/- puts you on both sides of zero, but the description appears written to exclude zero, and entering that little window is, I think, the definition of underflow. Obviously I'm splitting hairs, but what I really want is a definitive statement that values in that region are predictable, generally round to zero, and can invariably be ignored. Similar question for overflow- does it hurt anything to exceed the ranges, i.e., though the answer may be wrong, can it cause a crash on its own? Which brings me to yet another question- we know it's bad practice to rely on equality between floats, since rounding will get you sooner or later. But, when all the bits are zero, the float is exactly zero. I assume one can rely on equality between floats that have been explicitly set to zero? Or not?

[Paul Dixon]

Conrad,
when the FPU underflows beyond the limit of an unnormalised number it results in a zero (as well as setting the underflow flag which is subsequently ignored.
There are 2 zeros, +0 and -0. They are considered to be equal in comparisons.

When the FPU overflows it results in a special number which the FPU will subsequently treat as infinity in calculation that involve it.
The overflow flag is again set and ignored.

There are 2 infinities, +INF and -INF. They are considered to be un-equal in comparisons.

Paul.

[Conrad Hoffman]

Paul, that's fascinating! I was unaware of the dual zeros and infinities.

[Michael Mattias]

Michael, I don't see how that range includes zero.

Huh?

Zero lies between PLUS 8.43*10^37 and MINUS 8.43*10^37.

At least it did at St. Dominic's in Sheboygan WI in 1959.

[Conrad Hoffman]

Well, there's the problem- I had the "new" math! Can you see where the two statements can be interpreted two ways... no, don't answer that

[Gösta H. Lovgren-2]

[quote=Paul Dixon;301804There are 2 zeros, +0 and -0. They are considered to be equal in comparisons.

Paul.[/quote]

Paul, Now that is really cool. Which causes me to ask. Aren't there really THREE zeroes then?

-0 below Underflow
0 mid point between Underflow and Overflow.
+0 beyond Overflow

"Boy, if you don't behave, you're gonna end up Below the Underflow." {in deep ominous George Carlin voicetto}

"Oh, Lord, I repent mah sins. I'm ready for the great PLUS ZERO now." Hmmm... really doesn't ring, does it? Not like the "GREAT BEYOND".

======================================
"Denial ain't just a river in Egypt."
Mark Twain (1835-1910)
======================================