Possible bug in VB double-precision arithmetic/comparison operators? 
Author Message
 Possible bug in VB double-precision arithmetic/comparison operators?

Hello everyone,

        I've been working on a VB program implementing a mathematical model of
hillslope evolution, and today I ran into a numerical problem in VB that's got
me puzzled.  During one procedure in my program, I have to evaluate the
expression:

        xoriginal(j) < hillslope_cell(i).x

xoriginal() is an array of double-precision floating point variables, and
hillslope_cell() is an array of variables of a user-defined type, Cell, in
which the variable x is also a double-precision floating point variable.  In
fact, all of the variables used for calculations are declared as
double-precision, and nowhere in the program is there anything that could
result in any of them being cast into another type.
        Hence I'm puzzled that when xoriginal(j) and hillslope_cell(i).x have
the same value, the above comparison yields a value of True.  Different
numerical expressions are used to arrive at their values, but at a certain
point in my program they should be equal.  Using my first data set, for
example, they should at one point both equal 250.  It seems that this does
indeed happen, for when my program halts at this point, they both equal exactly
250 in the watch window, and if I print them in the debug window, I get the
same result.  VarType() returns 5 here, indicating that they are still both
double-precision.  If, and only if, I then from the debug window manually
assign a value of 250 to hillslope_cell(i).x, the comparison then operates
correctly.
        Apparently, hillslope_cell(i).x is NOT quite equal to xoriginal(j) at
this point in my program, though to almost all appearances it is.  Can anyone
out there give me an explanation as to why this is so?  I don't know the raw
nitty-gritty of how VB handles its floating point arithmetic, but I find this
phenomenon very disturbing.  I can only guess that VB is hiding some extra
digits from me somewhere, but this would seem truly odd.  This error shows up
in both VB4 and VB5.  Right now, I and the others I've shown this problem to
are led to conclude that it's a result of a bug in VB.
        Any help in understanding why this is/isn't due to a bug in VB would be
greatly appreciated.

                                        Sincerely,
                                        Richard

___

=========================================================================
Richard Tran Mills
Department of Physics:              phone: (423)974-7850
 Complex Systems Lab,               fax: (423)974-2368


Knoxville, TN  37996                URL - http://www.*-*-*.com/ ~rtm
=========================================================================



Wed, 05 Jan 2000 03:00:00 GMT  
 Possible bug in VB double-precision arithmetic/comparison operators?

Quote:

>Hello everyone,

>        I've been working on a VB program implementing a mathematical model of
>hillslope evolution, and today I ran into a numerical problem in VB that's got
>me puzzled.  During one procedure in my program, I have to evaluate the
>expression:

>        xoriginal(j) < hillslope_cell(i).x

>xoriginal() is an array of double-precision floating point variables, and
>hillslope_cell() is an array of variables of a user-defined type, Cell, in
>which the variable x is also a double-precision floating point variable.  In
>fact, all of the variables used for calculations are declared as
>double-precision, and nowhere in the program is there anything that could
>result in any of them being cast into another type.
>        Hence I'm puzzled that when xoriginal(j) and hillslope_cell(i).x have
>the same value, the above comparison yields a value of True.  Different
>numerical expressions are used to arrive at their values, but at a certain
>point in my program they should be equal.  Using my first data set, for
>example, they should at one point both equal 250.  It seems that this does
>indeed happen, for when my program halts at this point, they both equal exactly

>250 in the watch window, and if I print them in the debug window, I get the
>same result.  VarType() returns 5 here, indicating that they are still both
>double-precision.  If, and only if, I then from the debug window manually
>assign a value of 250 to hillslope_cell(i).x, the comparison then operates
>correctly.
>        Apparently, hillslope_cell(i).x is NOT quite equal to xoriginal(j) at
>this point in my program, though to almost all appearances it is.  Can anyone
>out there give me an explanation as to why this is so?  I don't know the raw
>nitty-gritty of how VB handles its floating point arithmetic, but I find this
>phenomenon very disturbing.  I can only guess that VB is hiding some extra
>digits from me somewhere, but this would seem truly odd.  This error shows up
>in both VB4 and VB5.  Right now, I and the others I've shown this problem to
>are led to conclude that it's a result of a bug in VB.
>        Any help in understanding why this is/isn't due to a bug in VB would be

>greatly appreciated.

>                                        Sincerely,

Floating point numbers arrived at through different
computations are never going to be equal.  There is always
round-off error which effects the two results differently
and fairly unpredictably.

Printing the number to see its value will not assure you
that they are equal unless you print out all of the digits
stored by VB (lots for a double precision number). Only if
all the digits and the exponent are equal,  will VB report
that they are equal.

Instead, perhaps you could set a tolerance and check to see
if the absolute value of the difference is less than your
tolerance.

HTH

--
Duncan



Wed, 05 Jan 2000 03:00:00 GMT  
 Possible bug in VB double-precision arithmetic/comparison operators?


schreibt:

Quote:
>Floating point numbers arrived at through different
>computations are never going to be equal.  There is always
>round-off error which effects the two results differently
>and fairly unpredictably.

You're perfectly right :-)
Equality of floating point numbers must always be checked with a small
tolerance, like:

if Abs(a-b) < delta then ...'assume equal

For Doubles, you also can try CSng(a)=CSng(b), that might be a bit faster,
but that comparison uses a quite huge delta, chopping the least 28 bits
from the mantissa.

Quote:
>Printing the number to see its value will not assure you
>that they are equal

Print a=b will show whether the variables really have the same value (-1
for True).

DoDi



Fri, 07 Jan 2000 03:00:00 GMT  
 Possible bug in VB double-precision arithmetic/comparison operators?

Have you tried looking at the DIFFERENCE between the two numbers?
Something like:

Const SMALL_VALUE = 0.000000000001
...

If Abs(xoriginal(j) - hillslope_cell(i).x) < SMALL_VALUE then...

Try printing the difference to see just how much they differ:

Debug.Print (xoriginal(j) - hillslope_cell(i).x)

Quote:

>Hello everyone,
>    I've been working on a VB program implementing a mathematical model of
>hillslope evolution, and today I ran into a numerical problem in VB that's got
>me puzzled.  During one procedure in my program, I have to evaluate the
>expression:
>    xoriginal(j) < hillslope_cell(i).x
>xoriginal() is an array of double-precision floating point variables, and
>hillslope_cell() is an array of variables of a user-defined type, Cell, in
>which the variable x is also a double-precision floating point variable.  In
>fact, all of the variables used for calculations are declared as
>double-precision, and nowhere in the program is there anything that could
>result in any of them being cast into another type.
>    Hence I'm puzzled that when xoriginal(j) and hillslope_cell(i).x have
>the same value, the above comparison yields a value of True.  Different
>numerical expressions are used to arrive at their values, but at a certain
>point in my program they should be equal.  Using my first data set, for
>example, they should at one point both equal 250.  It seems that this does
>indeed happen, for when my program halts at this point, they both equal exactly
>250 in the watch window, and if I print them in the debug window, I get the
>same result.  VarType() returns 5 here, indicating that they are still both
>double-precision.  If, and only if, I then from the debug window manually
>assign a value of 250 to hillslope_cell(i).x, the comparison then operates
>correctly.
>    Apparently, hillslope_cell(i).x is NOT quite equal to xoriginal(j) at
>this point in my program, though to almost all appearances it is.  Can anyone
>out there give me an explanation as to why this is so?  I don't know the raw
>nitty-gritty of how VB handles its floating point arithmetic, but I find this
>phenomenon very disturbing.  I can only guess that VB is hiding some extra
>digits from me somewhere, but this would seem truly odd.  This error shows up
>in both VB4 and VB5.  Right now, I and the others I've shown this problem to
>are led to conclude that it's a result of a bug in VB.
>    Any help in understanding why this is/isn't due to a bug in VB would be
>greatly appreciated.
>                                    Sincerely,
>                                    Richard
>___
>=========================================================================
>Richard Tran Mills
>Department of Physics:              phone: (423)974-7850
> Complex Systems Lab,               fax: (423)974-2368


>Knoxville, TN  37996                URL - http://aurora.phys.utk.edu/~rtm
>=========================================================================

Font-o-Meter!      Proportional  Fixed-Pitch
                                      ^


Fri, 07 Jan 2000 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. High-precision arithmetic on numbers and fractions

2. VB double precision/accuracy

3. Overriding Arithmetic Operators (help!)

4. Passing an Arithmetic Operator as a variable

5. Single and Double precision numbers

6. Weird Double Precision?

7. QUESTION ABOUT DOUBLE-PRECISION VARIABLES

8. HELP RE DOUBLE PRECISION

9. Double-precision real number format?

10. double precision number from binary data

11. HELP Math calculations with Double precision

12. HELP ON DOUBLE PRECISION

 

 
Powered by phpBB® Forum Software