Without a test how can you know if this implementation produces the correct values? What about variant type conversions? It seems silly to send a patch without testing it...
Now I'm confused. I'm adding more types to VarRound and I'm also implementing the test_VarRound function (programmer's pride :) For this I tested more cases on Windows and got strange results (in my view). VT_R4: 7.850 -> VarRound(1) -> 7.800 VT_R4: 7.851 -> VarRound(1) -> 7.900 Is this the binary representation (in)accuracy? How can I test if the rounding worked ok when the numbers may differ in the last (invisible) bits? And how should I round a currency? It's valid on Windows but I couldn't interpret the results. Is this some kind of fixed comma type? bye Fabi
"Fabian Cenedese" <Cenedese(a)indel.ch> wrote:
For this I tested more cases on Windows and got strange results (in my view).
VT_R4: 7.850 -> VarRound(1) -> 7.800 VT_R4: 7.851 -> VarRound(1) -> 7.900
Is this the binary representation (in)accuracy? How can I test if the rounding worked ok when the numbers may differ in the last (invisible) bits?
And how should I round a currency? It's valid on Windows but I couldn't interpret the results. Is this some kind of fixed comma type?
dlls/oleaut32/tests/vartype.c around line 4514 has the following comment: /* MSDN states that rounding of R4/R8 is dependent on the underlying * bit pattern of the number and so is architecture dependent. In this * case Wine returns .2 (which is more correct) and Native returns .3 */ So, I'd suggest just surround your test by todo_wine and add a comment explaining the situation. -- Dmitry.
participants (2)
-
Dmitry Timoshkov -
Fabian Cenedese