Against PEP 240

[Robin Becker]

In article <9f0ha4029t6 at enews2.newsguy.com>, Alex Martelli
<aleaxit at yahoo.com> writes
...
>
>
>> Floating point is what it says floating point. I don't use commas. As
>
>Why, you used several in the previous paragraph ("snobol, spitbol"
>etc).  And what does the first sentence mean?  We're talking
>about whether 7.35 should mean what it LOOKS like it means
>(7.35, aka 735/100) or rather 7.3499999999999996 (or whatever).
>What, in the literal 7.35, shows or suggests that the point
>should "float" (and in binary, yet, though the notation is
>in decimal)...?
>

I treat floating point numbers as approximations to the reals. Precision
is important, but infinite precision is impossible. The rational numbers
are countably infinite ie aleph 0; reals are a higher order set. The
number pi has no representation in the rationals, but I can approximate
with finite precision. Moreover the sorts of problems caused by finite
precision calculations are well understood and have been studied widely.

I can argue very easily about the order of work and stability of
algorithms in terms of fixed precision floats. I haven't got such good
insights how to calculate the amount of work required when using
rationals. The use of rationals makes the cpu time data dependant. 

>
>> My main objection is that this is likely to bust just about any
>> extension that uses floating point.
>

If I have made a really fast vector multiplier for floats I might use
myfastmult((1.0,2.0),(3.0,4.0)); if I was being really speed conscious I
would always assume that this function was being used with floats. It
would go wrong if I used the same call. I now have to either force the
conversion internally (which slows things down) or locate and change
every call of the function.


>Why would a Python literal 7.35 (rather than, as you'd like, 7.35R)
>mean rational, and (say) 7.35f (rather than 7.35) mean floating
>point have any effect on an extension?  Unless that extension does
>(the equivalent of) an eval or exec of some string, I don't see
>what Python literal notation matters to extensions.
>
.....
>> I'm not against using rationals. They will be slower and I'll have to
>> worry about that. I'll be happy if the numerical types PEP allows me
>> eventually to get an interval arithmetic together and or do some proper
>
>Can't you do interval arithmetic today, btw?  Quite apart from
>the issue of what a literal 7.35 means?
>
>
...
I can do interval type arithmetic with a class definition no problem. If
we're allowing new literals and the like I might want to have an
interval literal like (1,2)I :)
-- 
Robin Becker