|
From: Nicholas N. <n.n...@gm...> - 2009-02-25 01:14:51
|
Hi, On my Mac, memcheck/tests/vcpu_fnfns fails due to some tiny FP differences (see below). I propose changing the test to omit the +/- at the start of the answers (to remove +0 and -0 differences), to print 12 decimal places rather than 13 (to remove the difference in the 13th decimal place), and possibly to filter the sign of the exponent if its zero (to remove the difference between 1.0000e-00 and 1.0000e+00). Does this sound reasonable? Nick 94,103c94,103 < ceilD(-9.0000000110000e-01) = -0.0000000000000e+00 < ceilD(-8.0000000120000e-01) = -0.0000000000000e+00 < ceilD(-7.0000000130000e-01) = -0.0000000000000e+00 < ceilD(-6.0000000140000e-01) = -0.0000000000000e+00 < ceilD(-5.0000000150000e-01) = -0.0000000000000e+00 < ceilD(-4.0000000160000e-01) = -0.0000000000000e+00 < ceilD(-3.0000000170000e-01) = -0.0000000000000e+00 < ceilD(-2.0000000180000e-01) = -0.0000000000000e+00 < ceilD(-1.0000000190000e-01) = -0.0000000000000e+00 < ceilD(-1.9999992495467e-09) = -0.0000000000000e+00 --- > ceilD(-9.0000000110000e-01) = +0.0000000000000e+00 > ceilD(-8.0000000120000e-01) = +0.0000000000000e+00 > ceilD(-7.0000000130000e-01) = +0.0000000000000e+00 > ceilD(-6.0000000140000e-01) = +0.0000000000000e+00 > ceilD(-5.0000000150000e-01) = +0.0000000000000e+00 > ceilD(-4.0000000160000e-01) = +0.0000000000000e+00 > ceilD(-3.0000000170000e-01) = +0.0000000000000e+00 > ceilD(-2.0000000180000e-01) = +0.0000000000000e+00 > ceilD(-1.0000000190000e-01) = +0.0000000000000e+00 > ceilD(-1.9999992495467e-09) = +0.0000000000000e+00 135,144c135,144 < ceilF( -9.0110e-01) = -0.0000e+00 < ceilF( -8.0120e-01) = -0.0000e+00 < ceilF( -7.0130e-01) = -0.0000e+00 < ceilF( -6.0140e-01) = -0.0000e+00 < ceilF( -5.0150e-01) = -0.0000e+00 < ceilF( -4.0160e-01) = -0.0000e+00 < ceilF( -3.0170e-01) = -0.0000e+00 < ceilF( -2.0180e-01) = -0.0000e+00 < ceilF( -1.0190e-01) = -0.0000e+00 < ceilF( -1.9999e-03) = -0.0000e+00 --- > ceilF( -9.0110e-01) = +0.0000e+00 > ceilF( -8.0120e-01) = +0.0000e+00 > ceilF( -7.0130e-01) = +0.0000e+00 > ceilF( -6.0140e-01) = +0.0000e+00 > ceilF( -5.0150e-01) = +0.0000e+00 > ceilF( -4.0160e-01) = +0.0000e+00 > ceilF( -3.0170e-01) = +0.0000e+00 > ceilF( -2.0180e-01) = +0.0000e+00 > ceilF( -1.0190e-01) = +0.0000e+00 > ceilF( -1.9999e-03) = +0.0000e+00 308c308 < cosF( -1.9999e-03) = +1.0000e-00 --- > cosF( -1.9999e-03) = +1.0000e+00 539c539 < logD(+3.9999999960000e-01) = -9.1629073287415e-01 --- > logD(+3.9999999960000e-01) = -9.1629073287416e-01 620c620 < asinD(-9.0000000010000e-01) = -1.1197695152281e+00 --- > asinD(-9.0000000010000e-01) = -1.1197695152280e+00 |
|
From: Johan B. <jb...@gm...> - 2009-02-25 04:23:36
|
I assume this test reports the same errors when running it outside of valgrind on darwin? I still haven't managed to get the code generation in valgrind/ARM good enough to pass this testcase (I think I'm failing like 4 of the double-tests now), but I used to see errors that would cause an invalid 13th digit. I would prefer if you just added a different .exp file for darwin, if it reports the same errors when running it outside of VG. /Johan On Tue, Feb 24, 2009 at 5:14 PM, Nicholas Nethercote <n.n...@gm...> wrote: > Hi, > > On my Mac, memcheck/tests/vcpu_fnfns fails due to some tiny FP > differences (see below). > I propose changing the test to omit the +/- at the start of the > answers (to remove +0 and -0 differences), to print 12 decimal places > rather than 13 (to remove the difference in the 13th decimal place), > and possibly to filter the sign of the exponent if its zero (to remove > the difference between 1.0000e-00 and 1.0000e+00). > > Does this sound reasonable? > > Nick > > > 94,103c94,103 > < ceilD(-9.0000000110000e-01) = -0.0000000000000e+00 > < ceilD(-8.0000000120000e-01) = -0.0000000000000e+00 > < ceilD(-7.0000000130000e-01) = -0.0000000000000e+00 > < ceilD(-6.0000000140000e-01) = -0.0000000000000e+00 > < ceilD(-5.0000000150000e-01) = -0.0000000000000e+00 > < ceilD(-4.0000000160000e-01) = -0.0000000000000e+00 > < ceilD(-3.0000000170000e-01) = -0.0000000000000e+00 > < ceilD(-2.0000000180000e-01) = -0.0000000000000e+00 > < ceilD(-1.0000000190000e-01) = -0.0000000000000e+00 > < ceilD(-1.9999992495467e-09) = -0.0000000000000e+00 > --- >> ceilD(-9.0000000110000e-01) = +0.0000000000000e+00 >> ceilD(-8.0000000120000e-01) = +0.0000000000000e+00 >> ceilD(-7.0000000130000e-01) = +0.0000000000000e+00 >> ceilD(-6.0000000140000e-01) = +0.0000000000000e+00 >> ceilD(-5.0000000150000e-01) = +0.0000000000000e+00 >> ceilD(-4.0000000160000e-01) = +0.0000000000000e+00 >> ceilD(-3.0000000170000e-01) = +0.0000000000000e+00 >> ceilD(-2.0000000180000e-01) = +0.0000000000000e+00 >> ceilD(-1.0000000190000e-01) = +0.0000000000000e+00 >> ceilD(-1.9999992495467e-09) = +0.0000000000000e+00 > 135,144c135,144 > < ceilF( -9.0110e-01) = -0.0000e+00 > < ceilF( -8.0120e-01) = -0.0000e+00 > < ceilF( -7.0130e-01) = -0.0000e+00 > < ceilF( -6.0140e-01) = -0.0000e+00 > < ceilF( -5.0150e-01) = -0.0000e+00 > < ceilF( -4.0160e-01) = -0.0000e+00 > < ceilF( -3.0170e-01) = -0.0000e+00 > < ceilF( -2.0180e-01) = -0.0000e+00 > < ceilF( -1.0190e-01) = -0.0000e+00 > < ceilF( -1.9999e-03) = -0.0000e+00 > --- >> ceilF( -9.0110e-01) = +0.0000e+00 >> ceilF( -8.0120e-01) = +0.0000e+00 >> ceilF( -7.0130e-01) = +0.0000e+00 >> ceilF( -6.0140e-01) = +0.0000e+00 >> ceilF( -5.0150e-01) = +0.0000e+00 >> ceilF( -4.0160e-01) = +0.0000e+00 >> ceilF( -3.0170e-01) = +0.0000e+00 >> ceilF( -2.0180e-01) = +0.0000e+00 >> ceilF( -1.0190e-01) = +0.0000e+00 >> ceilF( -1.9999e-03) = +0.0000e+00 > 308c308 > < cosF( -1.9999e-03) = +1.0000e-00 > --- >> cosF( -1.9999e-03) = +1.0000e+00 > 539c539 > < logD(+3.9999999960000e-01) = -9.1629073287415e-01 > --- >> logD(+3.9999999960000e-01) = -9.1629073287416e-01 > 620c620 > < asinD(-9.0000000010000e-01) = -1.1197695152281e+00 > --- >> asinD(-9.0000000010000e-01) = -1.1197695152280e+00 > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Nicholas N. <n.n...@gm...> - 2009-02-25 05:04:46
|
On Wed, Feb 25, 2009 at 3:23 PM, Johan Björk <jb...@gm...> wrote: > I assume this test reports the same errors when running it outside of > valgrind on darwin? > I still haven't managed to get the code generation in valgrind/ARM > good enough to pass this testcase (I think I'm failing like 4 of the > double-tests now), but I used to see errors that would cause an > invalid 13th digit. The difference between native and Valgrind execution of that test on my Mac is this: --- native 2009-02-25 16:01:45.000000000 +1100 +++ vg 2009-02-25 16:01:51.000000000 +1100 @@ -536,7 +536,7 @@ logD(+9.9999999900000e-02) = -2.3025850939940e+00 logD(+1.9999999980000e-01) = -1.6094379134341e+00 logD(+2.9999999970000e-01) = -1.2039728053259e+00 - logD(+3.9999999960000e-01) = -9.1629073287415e-01 + logD(+3.9999999960000e-01) = -9.1629073287416e-01 logD(+4.9999999950000e-01) = -6.9314718155995e-01 logD(+5.9999999940000e-01) = -5.1082562476599e-01 logD(+6.9999999930000e-01) = -3.5667494493873e-01 On AMD64/Linux the results are identical. > I would prefer if you just added a different .exp file for darwin, if > it reports the same errors when running it outside of VG. I've recently been doing my best to eliminate multiple .exp files wherever possible because they are a maintenance headache. Nick |
|
From: Johan B. <jb...@gm...> - 2009-02-25 09:51:04
|
I agree that multiple .exp files is pain. One thing I've been hitting is that the filters now process so much of the .exp files, that it's hard to know what is actually expected, and what variations are "ok". (Ie, filter_error_summary in DRD, it only keeps the summary line) I was thinking a little bit about including a unfiltered .exp file, and then run the filters on both the .out and .exp, and compare that result. This would also solve the issue where the .exp files gets out of date (See most of the -x86 testfiles in helgrind/tests, the thread number is not filtered) Either way, I am actually seeing legitimate errors in VEX (albeit on arm) that only shows up in the last digit, so please leave it as is. /Johan On Tue, Feb 24, 2009 at 9:04 PM, Nicholas Nethercote <n.n...@gm...> wrote: > On Wed, Feb 25, 2009 at 3:23 PM, Johan Björk <jb...@gm...> wrote: >> I assume this test reports the same errors when running it outside of >> valgrind on darwin? >> I still haven't managed to get the code generation in valgrind/ARM >> good enough to pass this testcase (I think I'm failing like 4 of the >> double-tests now), but I used to see errors that would cause an >> invalid 13th digit. > > The difference between native and Valgrind execution of that test on > my Mac is this: > > --- native 2009-02-25 16:01:45.000000000 +1100 > +++ vg 2009-02-25 16:01:51.000000000 +1100 > @@ -536,7 +536,7 @@ > logD(+9.9999999900000e-02) = -2.3025850939940e+00 > logD(+1.9999999980000e-01) = -1.6094379134341e+00 > logD(+2.9999999970000e-01) = -1.2039728053259e+00 > - logD(+3.9999999960000e-01) = -9.1629073287415e-01 > + logD(+3.9999999960000e-01) = -9.1629073287416e-01 > logD(+4.9999999950000e-01) = -6.9314718155995e-01 > logD(+5.9999999940000e-01) = -5.1082562476599e-01 > logD(+6.9999999930000e-01) = -3.5667494493873e-01 > > On AMD64/Linux the results are identical. > >> I would prefer if you just added a different .exp file for darwin, if >> it reports the same errors when running it outside of VG. > > I've recently been doing my best to eliminate multiple .exp files > wherever possible because they are a maintenance headache. > > Nick > |
|
From: Tom H. <to...@co...> - 2009-02-25 10:25:01
|
Johan Björk wrote: > Either way, I am actually seeing legitimate errors in VEX (albeit on > arm) that only shows up in the last digit, so please leave it as is. It looks like that test depends on the implementation of the math functions in the C library, so maybe it isn't that surprising that you get slightly different results on different platforms? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Bart V. A. <bar...@gm...> - 2009-02-25 17:29:45
|
On Wed, Feb 25, 2009 at 10:50 AM, Johan Björk <jb...@gm...> wrote: > I agree that multiple .exp files is pain. One thing I've been hitting > is that the filters now process so much of the .exp files, that it's > hard to know what is actually expected, and what variations are "ok". > (Ie, filter_error_summary in DRD, it only keeps the summary line) Regarding the DRD regression tests: there are indeed some tests where only the summary line is kept. The reason is because for those tests the order in which the output appears can vary between each run. Filtering only the summary line is much more convenient than having multiple output files. And no variations are allowed for these tests. Summary filtering is only a problem IMHO if it is applied to most or all to all tests of a tool. This is not the case for DRD however: summary filtering is only applied to 10 out of 75 tests. Bart. |
|
From: Nicholas N. <n.n...@gm...> - 2009-02-26 00:25:52
|
On Thu, Feb 26, 2009 at 5:52 AM, Ivan Jager <aij...@an...> wrote: >> >> I propose changing the test to omit the +/- at the start of the >> answers (to remove +0 and -0 differences), to print 12 decimal places >> rather than 13 (to remove the difference in the 13th decimal place), >> and possibly to filter the sign of the exponent if its zero (to remove >> the difference between 1.0000e-00 and 1.0000e+00). > > Ok, what am I missing? IIRC the exponent part of an IEEE FP number is > represented by an integer, where the exponent is calculated by taking that > integer as unsigned and subtracting a constant. So, how is it possible to > have a different representation for 1.0000e-00 and 1.0000e+00? I don't know. Something in the printf() implementation? > Out of curiosity, are you encountering the differences on PPC or on an x86 > Mac? The only thing I can think of which could cause a diffirence on x86 > would be the compiler, since on Linux/x86 at least GCC defaults to not using > -ffloat-store. If I understand correctly, compiling the tests with > -ffloat-store should produce the same results as on any sane architecture, > however that would also mean the tests wouldn't be testing the extended > precision part of Valgrind/x86. x86 Mac. N |