Possible bug in VB doubleprecision arithmetic/comparison operators?
Author 
Message 
r.. #1 / 4

Possible bug in VB doubleprecision 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 doubleprecision floating point variables, and hillslope_cell() is an array of variables of a userdefined type, Cell, in which the variable x is also a doubleprecision floating point variable. In fact, all of the variables used for calculations are declared as doubleprecision, 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 doubleprecision. 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 nittygritty 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)9747850 Complex Systems Lab, fax: (423)9742368
Knoxville, TN 37996 URL  http://www.***.com/ ~rtm =========================================================================

Wed, 05 Jan 2000 03:00:00 GMT 


Duncan Chesl #2 / 4

Possible bug in VB doubleprecision 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 doubleprecision floating point variables, and >hillslope_cell() is an array of variables of a userdefined type, Cell, in >which the variable x is also a doubleprecision floating point variable. In >fact, all of the variables used for calculations are declared as >doubleprecision, 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 >doubleprecision. 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 >nittygritty 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 roundoff 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 


VBDi #3 / 4

Possible bug in VB doubleprecision arithmetic/comparison operators?
schreibt: Quote: >Floating point numbers arrived at through different >computations are never going to be equal. There is always >roundoff 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(ab) < 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 


Gerald Gardn #4 / 4

Possible bug in VB doubleprecision 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 doubleprecision floating point variables, and >hillslope_cell() is an array of variables of a userdefined type, Cell, in >which the variable x is also a doubleprecision floating point variable. In >fact, all of the variables used for calculations are declared as >doubleprecision, 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 >doubleprecision. 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 >nittygritty 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)9747850 > Complex Systems Lab, fax: (423)9742368
>Knoxville, TN 37996 URL  http://aurora.phys.utk.edu/~rtm >=========================================================================
FontoMeter! Proportional FixedPitch ^

Fri, 07 Jan 2000 03:00:00 GMT 


