November 21, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | I just realized, that because of the bug in how array literals are treated, there are memory allocations involved. If there is a bug in array literal code, or in the memory allocation, it could well be triggered by a change in the environment. It should be possible to track this down a bit more. Please, in gammafunction.d, around line 611, add the line: /* Resort to interval halving if not close enough. */ ihalve: dir = 0; di = 0.5L; for( i=0; i<400; i++ ) { + printf("%La %La %La\n", x0, x1, y0); if( i != 0 ) { x = x0 + di * (x1 - x0); if( x == 1.0L ) { x = 1.0L - real.epsilon; and also add an import core.stdc.stdio; in this file somewhere. Also at line 704, if ( nflg ) { goto done; } nflg = 1; lgm = logGamma(a+b) - logGamma(a) - logGamma(b); for( i=0; i<15; i++ ) { /* Compute the function at this point. */ + printf("NEWT %La %La %La\n", x, x0, x1); if ( i != 0 ) y = betaIncomplete(a,b,x); if ( y < yl ) { Then compile & run this: import std.mathspecial; import std.stdio; void main() { writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18, 0.0813601)); } |
November 21, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | The results are below. BTW, something funny is probably going on with the memory allocations and array literals and all because when I checked in the workaround for this (changeset 2185 http://dsource.org/projects/phobos/changeset/2185 ), it broke stuff and I had to revert it. Results: 0x0.p+0 0x1p+0 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1p+0 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1.1804eea8d2ecafb2p-4 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1.1804eea8d2ecafb2p-5 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1.04e0420638da04cp-5 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1.e6153a2ee5fb55d2p-7 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1.c4da30dcde0ea44p-9 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1.890d1616fb7cb0ep-13 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1.2818d1e2215bbbdcp-21 0x1.4d403f8b304a4aa8p-4 0x1.f88cc851df724acep-103 0x1.5012b5df54e94f6p-38 0x1.4d403f8b304a4aa8p-4 0x1.b0f21306a8a3f06ap-72 0x1.5012b5df54e94f6p-38 0x1.4d403f8b304a4aa8p-4 0x1.b0f21306a8a3f06ap-72 0x1.5012b5dfc125d422p-39 0x1.4d403f8b304a4aa8p-4 0x1.b0f21306a8a3f06ap-72 0x1.5012b5e0999edda4p-40 0x1.4d403f8b304a4aa8p-4 0x1.b0f21306a8a3f06ap-72 0x1.391906d83f397b3p-40 0x1.4d403f8b304a4aa8p-4 0x1.b0f21306a8a3f06ap-72 0x1.23b1705dc827e8fp-41 0x1.4d403f8b304a4aa8p-4 0x1.b0f21306a8a3f06ap-72 0x1.0fc0754e6ede4ce2p-43 0x1.4d403f8b304a4aa8p-4 0x1.b0f21306a8a3f06ap-72 0x1.d7bb43ed4b8a3cb8p-48 0x1.4d403f8b304a4aa8p-4 0x1.b0f21306a8a3f06ap-72 0x1.636033815363d902p-56 0x1.4d403f8b304a4aa8p-4 0x1.3d4f49d31c670614p-71 0x1.636033815363d902p-56 0x1.4d403f8b304a4aa8p-4 0x1.3d4f49d31c670614p-71 0x1.6362ae1fe70a11dp-57 0x1.4d403f8b304a4aa8p-4 0x1.3d4f49d31c670614p-71 0x1.6367a35d0e56836cp-58 0x1.4d403f8b304a4aa8p-4 0x1.3d4f49d31c670614p-71 0x1.4b1c4dad68a4e8cep-58 0x1.4d403f8b304a4aa8p-4 0x1.3d4f49d31c670614p-71 0x1.34841050c9b6aaccp-59 0x1.4d403f8b304a4aa8p-4 0x1.3d4f49d31c670614p-71 0x1.1fa9840b09d27c44p-61 0x1.4d403f8b304a4aa8p-4 0x1.fcba6abe87ee8baep-66 0x1.1fa9840b09d27c44p-61 0x1.4d403f8b304a4aa8p-4 0x1.fcba6abe87ee8baep-66 0x1.2f8f5760fe11f0ap-62 0x1.4d403f8b304a4aa8p-4 0x1.4f5afe0ce690d95cp-63 0x1.2f8f5760fe11f0ap-62 0x1.4d403f8b304a4aa8p-4 0x1.d73cd667715a5d4ep-63 0x1.2f8f5760fe11f0ap-62 0x1.4d403f8b304a4aa8p-4 0x1.e086f094f0f3c592p-63 0x1.2f8f5760fe11f0ap-62 0x1.4d403f8b304a4aa8p-4 0x1.e086f094f0f3c592p-63 0x1.121349774e697e9ep-62 0x1.4d403f8b304a4aa8p-4 0x1.e086f094f0f3c592p-63 0x1.012b60e0e371b0b4p-62 0x1.4d403f8b304a4aa8p-4 0x1.e086f094f0f3c592p-63 0x1.0003814474fc450ep-62 0x1.4d403f8b304a4aa8p-4 0x1.ef335416e5c498f4p-63 0x1.0003814474fc450ep-62 0x1.4d403f8b304a4aa8p-4 0x1.f79d2b4fe7de9188p-63 0x1.0003814474fc450ep-62 0x1.4d403f8b304a4aa8p-4 0x1.f8306a1e4276665ap-63 0x1.0003814474fc450ep-62 0x1.4d403f8b304a4aa8p-4 0x1.f8306a1e4276665ap-63 0x1.fc604d3e83e50ce6p-63 0x1.4d403f8b304a4aa8p-4 0x1.f8306a1e4276665ap-63 0x1.fa485bae632db9ap-63 0x1.4d403f8b304a4aa8p-4 0x1.f8306a1e4276665ap-63 0x1.fa23b805d24d9ec4p-63 0x1.4d403f8b304a4aa8p-4 0x1.f918ffdb6a9d2c52p-63 0x1.fa23b805d24d9ec4p-63 0x1.4d403f8b304a4aa8p-4 0x1.f918ffdb6a9d2c52p-63 0x1.f99e5bf09e75658cp-63 0x1.4d403f8b304a4aa8p-4 0x1.f95bade6048948fp-63 0x1.f99e5bf09e75658cp-63 0x1.4d403f8b304a4aa8p-4 0x1.f95bade6048948fp-63 0x1.f97d04eb517f573ep-63 0x1.4d403f8b304a4aa8p-4 0x1.f96c5968ab045018p-63 0x1.f97d04eb517f573ep-63 0x1.4d403f8b304a4aa8p-4 0x1.f974af29fe41d3acp-63 0x1.f97d04eb517f573ep-63 0x1.4d403f8b304a4aa8p-4 0x1.f975410947366826p-63 0x1.f97d04eb517f573ep-63 0x1.4d403f8b304a4aa8p-4 0x1.f975410947366826p-63 0x1.f97966ed789af692p-63 0x1.4d403f8b304a4aa8p-4 0x1.f975410947366826p-63 0x1.f97753fb5fe8af5cp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9772faf2f8c4692p-63 0x1.f97753fb5fe8af5cp-63 0x1.4d403f8b304a4aa8p-4 0x1.f97741d547ba7af8p-63 0x1.f97753fb5fe8af5cp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774312e7f9dfbap-63 0x1.f97753fb5fe8af5cp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774312e7f9dfbap-63 0x1.f9774c1b18a5da4ep-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774797004fdd04p-63 0x1.f9774c1b18a5da4ep-63 0x1.4d403f8b304a4aa8p-4 NEWT 0x1.f97749d90c7adba8p-63 0x1.f9774797004fdd04p-63 0x1.f9774c1b18a5da4 NEWT 0x1.f9774afa12905afcp-63 0x1.f97749d90c7adba8p-63 0x1.f9774c1b18a5da4 NEWT 0x1.f9774a698f859b52p-63 0x1.f97749d90c7adba8p-63 0x1.f9774afa12905af NEWT 0x1.f9774ab1d10afb28p-63 0x1.f9774a698f859b52p-63 0x1.f9774afa12905af NEWT 0x1.f9774a8db0484b3cp-63 0x1.f9774a698f859b52p-63 0x1.f9774ab1d10afb2 NEWT 0x1.f9774a9fc0a9a332p-63 0x1.f9774a8db0484b3cp-63 0x1.f9774ab1d10afb2 NEWT 0x1.f9774a96b878f738p-63 0x1.f9774a8db0484b3cp-63 0x1.f9774a9fc0a9a33 NEWT 0x1.f9774a9b3c914d34p-63 0x1.f9774a96b878f738p-63 0x1.f9774a9fc0a9a33 NEWT 0x1.f9774a98fa852236p-63 0x1.f9774a96b878f738p-63 0x1.f9774a9b3c914d3 NEWT 0x1.f9774a97d97f0cb8p-63 0x1.f9774a96b878f738p-63 0x1.f9774a98fa85223 NEWT 0x1.f9774a9748fc01f8p-63 0x1.f9774a96b878f738p-63 0x1.f9774a97d97f0cb NEWT 0x1.f9774a97913d8758p-63 0x1.f9774a9748fc01f8p-63 0x1.f9774a97d97f0cb NEWT 0x1.f9774a97b55e4a08p-63 0x1.f9774a97913d8758p-63 0x1.f9774a97d97f0cb NEWT 0x1.f9774a97a34de8bp-63 0x1.f9774a97913d8758p-63 0x1.f9774a97b55e4a08 NEWT 0x1.f9774a97ac56195cp-63 0x1.f9774a97a34de8bp-63 0x1.f9774a97b55e4a08 0x1.f9774a97a34de8bp-63 0x1.f9774a97ac56195cp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a34de8bp-63 0x1.f9774a97a7d20106p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a34de8bp-63 0x1.f9774a97a782f7f8p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a739562p-63 0x1.f9774a97a782f7f8p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a75e270cp-63 0x1.f9774a97a782f7f8p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a760ab6p-63 0x1.f9774a97a782f7f8p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a760ab6p-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a769d498p-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a76e6934p-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a76eb95ep-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a77100eep-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a772874ap-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a772874ap-63 0x1.f9774a97a772f762p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a772874ap-63 0x1.f9774a97a772bf56p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a772874ap-63 0x1.f9774a97a772bb82p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a7729f9ep-63 0x1.f9774a97a772bb82p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a772ad9p-63 0x1.f9774a97a772bb82p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a772ae84p-63 0x1.f9774a97a772bb82p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a772ae84p-63 0x1.f9774a97a772b574p-63 0x1.4d403f8b304a4aa8p-4 0x1.f9774a97a772b1fcp-63 On 11/21/2010 12:38 PM, Don Clugston wrote: > writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18, > 0.0813601)); > } > __ |
November 21, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | On 21.11.2010 20:18, David Simcha wrote: > Can others on this mailing list please submit info about their CPUs (manufacturer and core type) and whether the unit tests pass? My working hypothesis (mostly because I can't think of anything else that's at all plausible) is that this discrepancy is somehow hardware-related. I'll start and give an example of what I'm looking for: > > Intel Penryn: Pass > AMD Brisbane: Fail I myself, very concerned with FP code producing slightly different results on AMD and Intel, so here are my results (exactly the same exe used through out): AMD Phenom II: Fail (Win7 64bit) AMD Neo: Fail (Win7 32bit) Core 2 Duo: Pass (WinVista 32bit) I have a bad feeling about it... > > On 11/21/2010 1:19 AM, Don Clugston wrote: >> On 21 November 2010 05:48, David Simcha<dsimcha at gmail.com> wrote: >>> More research into this issue: I compiled the unittest.exe >>> executable on my >>> main (desktop) computer, ran it under my primary OS (Win7 64) and it >>> failed.. I then ran the exact same executable (no recompile) on my >>> Linux >>> Partition (Ubuntu 10.10 64) using Wine and it failed. >>> >>> I then ran the exact same executable on my laptop on my primary OS >>> (also >>> Win7 64) and it passed. I ran it on my laptop's Linux partition >>> under Wine >>> (Ubuntu 10.10 32) and it passed. >>> >>> The only difference between the two systems that might account for >>> this is >>> that the laptop has an Intel Penryn CPU, whereas the desktop as an AMD >>> Brisbane CPU. Does anyone know whether different x86 CPUs can produce >>> subtly different floating point results when executing the exact >>> same code? >>> Alternatively, is it possible that some processor-specific >>> optimizations to >>> some function getting called by Don's code could be causing slightly >>> different results? >> That's _very_ interesting. The code in question doesn't use the C >> runtime at all. >> If it's the same exe, then the difference can only lie in the CPU or >> in the environment. >> Eg, if it starts with 80-bit floats disabled. >> But the fact that every other test passes on your system, makes that >> seem unlikely. >> Does the failing system have execution protection enabled? >> >> The only documented floating point difference between AMD and Intel >> that I know of, is that AMD >> raises the invalid exception when loading an 80-bit NaN, but Intel >> doesn't. BTW I found that difference >> myself, and added it to Wikipedia. That difference is not relevant here. >> >> If the CPU itself is responsible for the difference, that's a CPU bug. >> BTW this test was present in Tango for years, and nobody ever reported >> this issue before. >> _______________________________________________ >> phobos mailing list >> phobos at puremagic.com >> http://lists.puremagic.com/mailman/listinfo/phobos >> > > _______________________________________________ > phobos mailing list > phobos at puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos |
November 21, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | On 11/21/2010 9:18 AM, David Simcha wrote:
> Can others on this mailing list please submit info about their CPUs (manufacturer and core type) and whether the unit tests pass? My working hypothesis (mostly because I can't think of anything else that's at all plausible) is that this discrepancy is somehow hardware-related. I'll start and give an example of what I'm looking for:
>
> Intel Penryn: Pass
> AMD Brisbane: Fail
>
auto tester is an atom n280 (yeah, slow, but it's an otherwise unused box): pass
|
November 21, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | On Nov 21, 2010, at 1:35 PM, Brad Roberts wrote:
>
> auto tester is an atom n280 (yeah, slow, but it's an otherwise unused box): pass
Intel Core 2 Duo: pass
I have an AMD X2 I can test as well, but it will take some time.
|
November 22, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | Intel Core 2 Duo: Pass
-Lars
On Sun, 2010-11-21 at 12:18 -0500, David Simcha wrote:
> Can others on this mailing list please submit info about their CPUs (manufacturer and core type) and whether the unit tests pass? My working hypothesis (mostly because I can't think of anything else that's at all plausible) is that this discrepancy is somehow hardware-related. I'll start and give an example of what I'm looking for:
>
> Intel Penryn: Pass
> AMD Brisbane: Fail
>
> On 11/21/2010 1:19 AM, Don Clugston wrote:
> > On 21 November 2010 05:48, David Simcha<dsimcha at gmail.com> wrote:
> >> More research into this issue: I compiled the unittest.exe executable on my
> >> main (desktop) computer, ran it under my primary OS (Win7 64) and it
> >> failed.. I then ran the exact same executable (no recompile) on my Linux
> >> Partition (Ubuntu 10.10 64) using Wine and it failed.
> >>
> >> I then ran the exact same executable on my laptop on my primary OS (also
> >> Win7 64) and it passed. I ran it on my laptop's Linux partition under Wine
> >> (Ubuntu 10.10 32) and it passed.
> >>
> >> The only difference between the two systems that might account for this is that the laptop has an Intel Penryn CPU, whereas the desktop as an AMD Brisbane CPU. Does anyone know whether different x86 CPUs can produce subtly different floating point results when executing the exact same code? Alternatively, is it possible that some processor-specific optimizations to some function getting called by Don's code could be causing slightly different results?
> > That's _very_ interesting. The code in question doesn't use the C
> > runtime at all.
> > If it's the same exe, then the difference can only lie in the CPU or
> > in the environment.
> > Eg, if it starts with 80-bit floats disabled.
> > But the fact that every other test passes on your system, makes that
> > seem unlikely.
> > Does the failing system have execution protection enabled?
> >
> > The only documented floating point difference between AMD and Intel
> > that I know of, is that AMD
> > raises the invalid exception when loading an 80-bit NaN, but Intel
> > doesn't. BTW I found that difference
> > myself, and added it to Wikipedia. That difference is not relevant here.
> >
> > If the CPU itself is responsible for the difference, that's a CPU bug.
> > BTW this test was present in Tango for years, and nobody ever reported
> > this issue before.
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> >
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
|
November 25, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lars Tandle Kyllingstad | With regard to the AMD vs Intel bug: The previous results narrowed it down significantly, but I'm going to need more info to fix this. Please, somebody with AMD add this to line to std.math.internal.gammafunction line 624, add an import core.stdc.stdio; in the file, if( x == 0.0L ) { di = 0.5; x = x0 + di * (x1 - x0); if( x == 0.0 ) goto under; } y = betaIncomplete( a, b, x ); + printf("%d %La %La %La %La %La %La %La\n", i, x, y, di, yl, yh, a, b); yp = (x1 - x0)/(x1 + x0); if( fabs(yp) < dithresh ) goto newt; yp = (y-y0)/y0; if( fabs(yp) < dithresh ) goto newt; compile Phobos, and then run this program: import std.mathspecial; import std.stdio; void main() { writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18, 0.0813601)); } |
November 25, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | I'll do it in a few days if noone else does, but right now I'm out of town for Thanksgiving and don't have access to my AMD computer. On Thu, Nov 25, 2010 at 10:06 AM, Don Clugston <dclugston at googlemail.com>wrote: > With regard to the AMD vs Intel bug: > > The previous results narrowed it down significantly, but I'm going to > need more info to fix this. > Please, somebody with AMD add this to line to > std.math.internal.gammafunction line 624, add an import > core.stdc.stdio; in the file, > > if( x == 0.0L ) { > di = 0.5; > x = x0 + di * (x1 - x0); > if( x == 0.0 ) > goto under; > } > y = betaIncomplete( a, b, x ); > + printf("%d %La %La %La %La %La %La %La\n", i, x, y, di, > yl, yh, a, b); > yp = (x1 - x0)/(x1 + x0); > if( fabs(yp) < dithresh ) > goto newt; > yp = (y-y0)/y0; > if( fabs(yp) < dithresh ) > goto newt; > > compile Phobos, and then run this program: > > import std.mathspecial; > import std.stdio; > > void main() > { > writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18, > 0.0813601)); > } > _______________________________________________ > phobos mailing list > phobos at puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101125/7d1c02bf/attachment-0001.html> |
November 25, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | On 25.11.2010 18:06, Don Clugston wrote: Ok, see results attached per CPU type. > With regard to the AMD vs Intel bug: > > The previous results narrowed it down significantly, but I'm going to > need more info to fix this. > Please, somebody with AMD add this to line to > std.math.internal.gammafunction line 624, add an import > core.stdc.stdio; in the file, > > if( x == 0.0L ) { > di = 0.5; > x = x0 + di * (x1 - x0); > if( x == 0.0 ) > goto under; > } > y = betaIncomplete( a, b, x ); > + printf("%d %La %La %La %La %La %La %La\n", i, x, y, di, > yl, yh, a, b); > yp = (x1 - x0)/(x1 + x0); > if( fabs(yp)< dithresh ) > goto newt; > yp = (y-y0)/y0; > if( fabs(yp)< dithresh ) > goto newt; > > compile Phobos, and then run this program: > > import std.mathspecial; > import std.stdio; > > void main() > { > writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18, > 0.0813601)); > } > _______________________________________________ > phobos mailing list > phobos at puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AMD_phenom_II.txt URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101125/db311284/attachment-0003.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: amd_neo.txt URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101125/db311284/attachment-0004.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: intel_core2.txt URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101125/db311284/attachment-0005.txt> |
November 26, 2010 [phobos] phobos commit, revision 2186 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | Thanks! That's fantastic. It clearly shows we have a one-bit difference at iteration 25. This now looks very much like a CPU bug. I think that if I'm correct, this should be a reduced test case. import std.mathspecial; import std.stdio; void main() { real a = 0x1.ff1275ae5b939bcap-41L; real b = 0x1.034f2a66cd21p+62L; real x = 0x1.4f5afe0ce690d95cp-63L; real s = 0x1.0076fc5cc795a06cp+40L; real u = a * log(x); real t = logGamma(b) - logGamma(a) - logGamma(b) + u + log(s); real y = exp(t); writefln("%a %a %a %a", logGamma(a), logGamma(b), u, t); writefln("%a %a %a %a", log(s), log(x), log(a), log(b)); assert(y==0x1.c91a61a8fc916338p-7L); // Intel // assert(y==0x1.c91a61a8fc91633ap-7L); // AMD } On my Intel box, this prints: 0x1.bba4a9f774f49d0ap+4 0x1.543ef272830d3ed4p+67 -0x1.5a8e8efc9cec0dbp-35 -0x1.1 16d582237016688p+2 0x1.bba4a9f774f4c37ap+4 -0x1.5b2fa254744c96d8p+5 -0x1.bba4a9f774fdd508p+4 0x1.57 e75c552cc1d47ep+5 I suspect that we'll ever see a difference in the last line, which would indicate a one-bit error in log. But if all the numbers are the same, and the assert still fails, it's a one-bit error in exp. If the values in the last line are the same, but the ones in the first line are different, it's an error in poly. Either way, if the assert fails on AMD, we're just about down the asm. |
Copyright © 1999-2021 by the D Language Foundation