[EMAIL PROTECTED] writes:
> Author: tismer
> Date: Wed Jul 13 17:53:23 2005
> New Revision: 14625
>
> Modified:
> pypy/dist/pypy/objspace/std/strutil.py
> Log:
> another less urgent optimization from the train Kiel-Berlin:
>
> refactored string_to_float quite a lot. The issue was raised
> by Python 2.4's test_long, which caused an overflow in strutil
> instead of an 1.#inf.
> I took the chance to rework this quite a little, with the result of
> - less rounding errors
> - smaller code
> - much faster in extreme cases
> - able to eval float('1.'+10000*'0'+'e-10000') and friends
> - seems to produce exactly the same as builtin float as far as tested.
Thank you for doing this! The original code was written in about 5
minutes flat...
> + # Usage of long numbers is explicitly avoided, because
> + # we want to be able to work without longs as a PyPy option.
Unfortunately, the 'input problem for floating point numbers' cannot
be solved using arithmetic of any fixed finite precision, see
http://citeseer.ist.psu.edu/clinger90how.html
for a proof of this.
Also, I found a difference between CPython and your code:
>>> strutil.string_to_float('0.099999999999999999')
0.099999999999999992
>>> float('0.099999999999999999')
0.10000000000000001
But still, a vast improvement, thanks!
Cheers,
mwh
--
If comp.lang.lisp *is* what vendors are relying on to make or
break Lisp sales, that's more likely the problem than is the
effect of any one of us on such a flimsy marketing strategy...
-- Kent M Pitman, comp.lang.lisp
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev