On 20 August 2013 10:57, Iain Buclaw <ibuc...@ubuntu.com> wrote: > On 20 August 2013 10:07, Johannes Pfau <nos...@example.com> wrote: >> Am Fri, 16 Aug 2013 18:33:14 +0200 >> schrieb "Iain Buclaw" <ibuc...@ubuntu.com>: >> >>> I've pushed in pure implementations of functions in std.math, >>> removing the workaround in core.stdc.math. >>> >>> This passes for x64/x32. Can any ARM testers please report any >>> problems causecd by this update? >>> >>> Thanks >>> Iain. >> >> I found a bug in the floor implementation for 64 bit reals: >> >> int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff; >> The constants are wrong: At least 0x7ff must be 0x7ff0. >> >> (Remember, the 16 bits are s|eeeeeeeeeee|???? ) >> >> However, the results are still wrong and I don't really understand how >> that equation should work. >> >> The 'naive' and working way to write this is >> -------- >> int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023; >> -------- >> >> I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then >> the result is still left-shifted by 4 and needs to be right-shifted: >> ------- >> int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4; >> ------- >> >> is also working, but I don't know what's the advantage of this version. >> >> floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained? >> >> > > Thanks, it should be: > > --- > int exp = ((vu[F.EXPPOS_SHORT] >> 4) & 0x7ff) - 0x3ff; > > > > I'll raise a pull to fix as my pull into phobos got merged this morning. :o) >
Pull: http://j.mp/171CJl7 -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
