The results you are seeing are due to the inacurracy of doubles. Stop in the debugger and you will see that a = 3.5999999999999996 and b = 3.6000000000000001. When you declare them as currency, they are rounded to 2 decimal places to become =.
bottom line: Always format doubles.
Welcome to the wonderful world of representation of doubles in binary. When you store 3.6, you are storing its closest representation, 3.6000000000000001. The calculation, however, yields 3.5999999999999996, which is less.
If you want to be sure they are essentially the same to n decimal places, use something like this. (I am comparing to three decimal places by using 1,000 as my multiplier.)
dim a,b as double
a = 3.0 * 1.2
b = 3.6
dim compareA, compareB as Int64
compareA = Round( a * 1000.0 )
compareB = Round( b * 1000.0 )
if compareA < compareB then
MsgBox "a less than b "
elseif compareA = compareB then
MsgBox "a equal b "
end if
BTW, note that I put a decimal point after my numeric constants, like “3.0” and “1000.0”. This tells the compiler that these are doubles and not integers, preventing unnecessary conversions.
[quote=67884:@Kem Tekinay]
BTW, note that I put a decimal point after my numeric constants, like “3.” and “1000.”. This tells the compiler that these are doubles and not integers, preventing unnecessary conversions.[/quote]
I’d strongly encourage you to use 3.0 and 1000.0 as the fact the compiler allows 3. and 1000. is a parsing bug actually
Kem, I’ve edited your post slightly as there needs to be a digit after the decimal place (i.e. 1.0 instead of 1.). The compiler currently allows both, but it’s a bug.
[quote=67893:@Kem Tekinay]Is that right? I always thought that was just shorthand, one I use all the time.
If that bug is fixed, I sure hope a compiler error comes up so I can fix the places I’ve done that. Because I can tell you, I’ve done it a lot.[/quote]
perhaps it is time someone wrote a DOUBLE tutorial and posted it, as this questionor a variation comes up every few weeks…
It would save the re-explanation, by pointing the poster to a standard explanation
Something like i+=1 might happen (and the other ones like -=, *=, /= )
i++ and/or ++i (with all the associated c semantics about pre & post increment) won’t - I think Joe’s even gone so far as to say WON’T quite definitively