tismer@codespeak.net 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