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
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