Re: oleaut32/tests: added tests for negative fractional variant dates.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5729 Your paranoid android. === W98SE (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === WNT4WSSP6 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W2KPROSP4 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === WXPPROSP3 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W2K3R2SESP2 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === WVISTAADM (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W2K8SE (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W7PRO (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W7PROX64 (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 === W7PROX64 (64 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926
On 10/2/10 10:13 AM, (Marvin) wrote:
Hi,
While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5729
Your paranoid android.
=== W98SE (32 bit vartest) === vartest.c:1685: Test failed: expected 0, -5.99998846, got 0, -5.999988425925926 Looks like you got 'bit' by the way that a finite storage method mangles floating information. There was a lengthy discussion on how to 'overcome' this on the Wine-Development list a short while ago.
Maybe Dan Kegel can step in and refresh this. James McKenzie
On Sat, 2 Oct 2010, James McKenzie wrote:
Looks like you got 'bit' by the way that a finite storage method mangles floating information. There was a lengthy discussion on how to 'overcome' this on the Wine-Development list a short while ago.
No, those tests aleady account for that. /* When comparing floating point values we cannot expect an exact match * because the rounding errors depend on the exact algorithm. */ #define EQ_DOUBLE(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b)) < 1e-14) #define EQ_FLOAT(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b)) < 1e-7) ok_(__FILE__,line)(r == res && (FAILED(r) || EQ_DOUBLE(out, dt)), "expected %x, %.16g, got %x, %.16g\n", r, dt, res, out); My understanding is that that algorithm should work to account for floating-point inaccuracies (though technically should be using DBL_EPSILON and FLT_EPSILON instead of 1e-X constants, but they're probably not portable enough for this project), I was simply bit by my own stupidity, not running my last changes against a Windows OS before sending my patch. This has been corrected in my try2.
Maybe Dan Kegel can step in and refresh this.
James McKenzie
-- The older I grow, the less important the comma becomes. Let the reader catch his own breath. -- Elizabeth Clarkson Zwart
On 10/2/10 7:00 PM, Jeremy Drake wrote:
On Sat, 2 Oct 2010, James McKenzie wrote:
Looks like you got 'bit' by the way that a finite storage method mangles floating information. There was a lengthy discussion on how to 'overcome' this on the Wine-Development list a short while ago. No, those tests aleady account for that.
/* When comparing floating point values we cannot expect an exact match * because the rounding errors depend on the exact algorithm. */ #define EQ_DOUBLE(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b))< 1e-14) #define EQ_FLOAT(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b))< 1e-7)
ok_(__FILE__,line)(r == res&& (FAILED(r) || EQ_DOUBLE(out, dt)), "expected %x, %.16g, got %x, %.16g\n", r, dt, res, out);
My understanding is that that algorithm should work to account for floating-point inaccuracies (though technically should be using DBL_EPSILON and FLT_EPSILON instead of 1e-X constants, but they're probably not portable enough for this project),
I was simply bit by my own stupidity, not running my last changes against a Windows OS before sending my patch. This has been corrected in my try2. Ok. I seen that. However, will this work in Wine as well might come up as it has before.
I don't want to raise the 'noise' level and I did not see [try 2] before making my comment, but this might be something you want to keep in mind for the future. Also, please be aware that my comment is based on a previous thread, which you still might want to visit, in this mailing list/forum. It may save you time and give you something to think about in regards to this patch and future patches. Note: My comment is not based on actual programming experience using the Epsilon features and code, but rather on previous comments. I'm just a simple programmer who tests Wine on the Mac platform. Since I tend to remove messages as they no longer apply to my personal habits, however I did find a pointer to the following document written by Bruce Dawson: http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm This came from http://www.winehq.org/pipermail/wine-devel/2010-July/085089.html It looks like you read through it, based on a review of the proposed patch. I don't know if this can be applied to the ok() checks though. James McKenzie
participants (3)
-
James McKenzie -
Jeremy Drake -
testbotīŧ testbot.winehq.org