num() rounds differently to round() for half-step values
Hi folks,
I've been doing some work on writing rounded numbers to file (for which I've used num(), and then providing a reconciliation to itemise the resulting rounding error (for which I've used round()). But I've discovered that num() rounds differently to round(), which ruins my reconciliation! Obviously, I already know how to workaround this problem to ensure my reconciliation works; but of course I'm interested in this from the bug perspective to see if you agree that this is a bonfide bug that I should report, and whether it's a batle worth fighting for the Community.
This bug concerns values that are half-steps i.e. exactly half-way between two consecutive rounded values e.g. when rounding to 1 decimal place, how should 3.5 be rounded? Round() is consistent in rounding such numbers towards zero i.e. positive half-step numbers get rounded down and negative half-step numbers get rounded up. Sometimes it goes the other way; but I accept that this is likely due to the numbers have a tiny amount of machine fp error that sends the rounding the other direction.
Num(), though, from the small amount of testing I've down, consistently rounds negative half-steps down, while positive ones have no obvious pattern as to which ones round up and which ones round down.
See attached QVW for tabulation of these different behaviours.
