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) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
