Against PEP 240
claird at starbase.neosoft.com
Tue May 29 16:31:00 CEST 2001
In article <Ae4BQuAFb6E7Ew0t at jessikat.demon.co.uk>,
Robin Becker <robin at jessikat.fsnet.co.uk> wrote:
>In article <9f03m401qcu at enews2.newsguy.com>, Alex Martelli
><aleaxit at yahoo.com> writes
>Well OK I accept that BCD has been used. I also in a distant past used
>snobol, spitbol, pl/1 and similar. I defy anyone to claim that cobol
>ever had a significant impact on thought. Of course I should wear more
>Floating point is what it says floating point. I don't use commas. As
>for being naive; I used to do the most awful assembly code to get extra
>bits out of accelerated tangent series and the like. I know what an ulp
>is, but I don't claim that makes me better than anyone else though. I
>guess like many an old fart I long for the good old days when missiles
>ruled the budgets and 60 bit fp was as good as it got. Moan whine.
>My main objection is that this is likely to bust just about any
>extension that uses floating point.
Robin, I'm another old-timer who's twiddled
abundant bits in assembler to get results that
would let my customers sleep better at night.
Feel free to use adult language.
Let's be precise: extensions that pass float-
ing point data will all be broken. I don't
regard broken extensions lightly; I know what
a cost it can be to reassemble all the parts
just to recreate what one had before. Do you
agree there'd be value in adding a coda to the
PEP about how to rewrite extensions? Shall
part of the PEP be a function on the C side
that helps ease the task?
>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
>numerical differentials (and I'm not talking about finite differences).
>Of all the types I would prefer to have added the first would be a
>parametrized binary fixed point.
Cameron Laird <claird at NeoSoft.com>
More information about the Python-list