In article <[EMAIL PROTECTED]>, Grant Edwards <[EMAIL PROTECTED]> writes: |> > |> > Firstly, a FAR more common assumption is that integers wrap in twos' |> > complement - Python does not do that. |> |> It used to, and I sure wish there was still a way to get that |> behavior back. Now I have to do all sorts of bitwise ands that |> I didn't use to.
Given that it is perhaps THE most common cause of severe failure in large scientific codes, I don't agree that it should be the default. A 'twos complement' class would be quite reasonable. |> > Secondly, it is NOT incompatible with IEEE 754, which is a |> > pure hardware standard. All it does is to trap the exception |> > and take appropriate action (as permitted by that standard). |> |> There are two allowed (selectable?) behaviors for 1/0: trap and |> Inf. Er, no. The second is REQUIRED to set an exception flag, which IEEE 754 assumes that the code will test and take appropriate action (which can be anything, including aborting the program and replacing it by a NaN). See http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf |> > Thirdly, virtually no hardware sticks strictly to IEEE 754, |> > and no language that I know of has EVER attempted to make it |> > the strict basis for its arithmetic model. |> |> All the HW and libraries I've used returned Inf for 1/0. Well, I have clearly used a much wider range than you have, then. But it isn't just that aspect I was referring to. You will also find that a high proportion of hardware traps into the kernel on overflow, and it is software that returns the infinity. |> > Fourthly, I am not proposing to change any hardware, |> |> IMO, having Python's FP results disagree with common HW FP |> results would be a pretty bad thing. No matter WHAT results are returned, they will do that! I was triggered into this project by attempting to write NaN-safe code and finding that the first few versions of Python I tried all did different things. When I saw that it just mapped what C does, all became clear. |> > and could even provide a Python option to deliver |> > mathematically incorrect results when you want them. |> |> As long as I can get IEEE 754 results, that's cool. I'd prefer |> if Python just let the HW do it's thing when possible. Including crash and burn? Seriously. I don't think that you realise just how many layers of fixup there are on a typical "IEEE 754" system, and how many variations there are even for a single platform. Regards, Nick Maclaren. -- http://mail.python.org/mailman/listinfo/python-list
