M. Edward (Ed) Borasky wrote:
> Charles D Hixson wrote:
>> I stopped using VBA after I caught it making arithmetic mistakes.  
>> Not rounding errors, outright mistakes.  Now granted this was over 5 
>> years ago now, and they MAY have improved things...but I wouldn't 
>> trust it any more.  I actually rewrote things to use Excel macros to 
>> avoid doing arithmetic in VBA.  I never did figure out under what 
>> circumstances it would do this, but ever since then I've had an 
>> extreme distrust of everything programmed in MSOffice.  I figure that 
>> Excel macros are probably safe...because there would be so many eyes 
>> looking at them.  But I'm not sure.  I never heard anyone else saying 
>> that they had caught VBA (actually basic for MSAccess2000) in an 
>> arithmetic error, but I definitely did.  The numbers were small 
>> enough that a third grader would have seen the error, and there 
>> wasn't ANYTHING subtle about the program.
> Excel itself has a long and painful history of mathematical 
> incorrectness. To be fair, some of it came from the need to be upward 
> compatible from Lotus 1-2-3, which in turn needed to be upward 
> compatible from VisiCalc. A simple example is the belief in Excel that 
> 1900 was a leap year. I'm not sure what Google query you can use to 
> hunt down this stuff, but I would not make business decisions based on 
> anything done with Excel. I use it as an X-Y plotter when I'm in a 
> hurry, but when I actually care about the numbers, I do things in R.
>
I'm talking about something on the level of 17 + 3 => 21
I could GUESS that internally it was represented as 17.45 as an integer 
3.45 as an integer => 20.9 as an integer, so round up to display it...
But the numbers WERE integers.  There would be no reason to represent 
them as floats, much less as floats near the rounding point.

Mind you, this wasn't the only problem.  My favorite one was the program 
that had been working and stopped.  The only way to easily fix it was to 
export the routine as a text file, delete the original, and then import 
the text file.  My guess was that MS was storing the code mixed in with 
the text of the code, and it somehow corrupted the compiled text.  So 
what I was doing was forcing the entire thing to be recompiled.  But I 
didn't make that guess until considerably after I discovered how to fix 
it, so I just continued doing what worked. Using MSBasic is largely 
black magic rather than programming anyway.

Glad I'm free of THAT now!