Hi Armin, that sounds more convenient than manipulating floats as architecture dependent integers ;) So this is my implementation now:
https://bitbucket.org/amintos/pypy/commits/f30efb9a8e54e56af7e7a0d07ec19d6985c1f4e0?at=float-opt BTW, the jit log (PYPYLOG=jit-log-opt,jit-backend) tends to round small floats like '1.0 / 8.98846567431158e+307' to '0.000000', but '1.0 / 2.2250738585072014e-308' appears as a full 308-digit decimal number. This may cause some confusion when checking where the optimization is effective. Best regards, Toni Am 06.11.2014 um 19:08 schrieb Armin Rigo: > Hi Toni, > > On 6 November 2014 18:29, Toni Mattis > <toni.mat...@student.hpi.uni-potsdam.de> wrote: >> thanks for the advice. I tried what Armin proposed and like to share my >> results with you: >> >> https://bitbucket.org/amintos/pypy/commits/937254cbc554adfb748e3b5eeb44bf765d204b9d?at=default > > Thanks! Maybe instead of manipulating directly the bits (where you > have to be extra careful because on 32-bit platforms, regular RPython > integers have only 32 bits), you could use math.frexp(). The > condition should be "math.frexp(x)[0] == 0.5" or "-0.5". You can then > check for denormals by checking that "math.frexp(1.0 / x)[0]" is also > 0.5 or -0.5. > > I think that "x / inf" is always equal to "x * 0.0" (which can be > "0.0", "-0.0", or "nan", so it can't be simplified further), but it > looks like a useless optimization imho. > > > A bientôt, > > Armin. > _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
