[Python-Dev] Numerical robustness, IEEE etc. (original) (raw)

Michael Hudson mwh at python.net
Fri Jun 23 14:32:37 CEST 2006

Nick Maclaren <nmm1 at cus.cam.ac.uk> writes:

> My intentions are to provide some numerically robust semantics, > preferably of the form where straightforward numeric code (i.e. code > that doesn't play any bit-twiddling tricks) will never invoke > mathematically undefined behaviour without it being flagged. See > Kahan on that.

That doesn't actually explain the details of your intent very much. Let's try again. You say that you are a mathematician.

I don't think I said that; I said I have a mathematics degree (I guess I'm a computer scientist, these days).

The standard floating-point model is that it maps functions defined on the reals (sometimes complex) to approximations defined on floating- point. The conventional interpretation was that any operation that was not mathematically continuous in an open region including its argument values (in the relevant domain) was an error, and that all such errors should be flagged. That is what I am talking about. It's all classic behaviour - nothing unusual.

Well, I think you've used longer words than necessary, but thanks for the explanation.

> Not a lot. Annex F in itself is only numerically insane. You need to > know the rest of the standard, including that which is documented only > in SC22WG14 messages, to realise the full horror.

That's not why I was mentioning it. I was mentioning it to give the idea that I'm not a numerical expert but, for example, I know what a denorm is. Unfortunately, that doesn't help, because it is not where the issues are. What I don't know is how much you know about numerical models, IEEE 754 in particular, and C99. You weren't active on the SC22WG14 reflector, but there were some lurkers.

I'm in no way deeply enough involved to be reading that sort of email, which I would have thought would have been obvious from the other things I have said.

>> This could be implemented by having a field in the threadstate of FPU >> flags to check after each fp operation (or each set of fp operations, >> possibly). I don't think I have the guts to try to implement >> anything sensible using HW traps (which are thread-local as well, >> aren't they?). > > Gods, NO!!!

Good :-) !!!!! I am sorry, but that isn't an appropriate response.

Um, I think we've been misreading each other here.

> Sorry, but I have implemented such things (but that was on a far > architecture, and besides the system is dead). Modern CPU > architectures don't even DEFINE whether interrupt handling is local > to the core or chip, and document that only in the release notes, > but what is clear is that some BLACK incantations are needed in > either case.

Well, I only really know about the PowerPC at this level... Do you? Can you tell me whether interrupts stop the core or chip, for each of the classes of interrupt, and exactly what the incantation is for changing to the other mode?

No. I've only played on single processor, single core machines.

> Think of taking a machine check interrupt on a multi- core, > highly-pipelined architecture and blench. And, if that is an > Itanic, gibber hysterically before taking early retirement on the > grounds of impending insanity.

What does a machine check interrupt have to do with anything? Because a machine check is one of the classes of interrupt that you POSITIVELY want the other cores stopped until you have worked out whether it impacts just the interrupted core or the CPU as a whole. Inter alia, the PowerPC architecture takes one when a core has just gone AWOL - and there is NO WAY that the dead core can handle the interrupt indicating its own demise!

But, a floating point exception isn't a machine check interrupt, it's a program interrupt...

Now, a more general reply: what are you actually trying to acheive with these posts? I presume it's more than just make wild claims about how much more you know about numerical programming than anyone else... Sigh. What I am trying to get is floating-point support of the form that, when a programmer makes a numerical error (see above), he gets EITHER an exception value returned OR an exception raised.

See, that wasn't so hard! We'd have saved a lot of heat and light if you'd said that at the start (and if you think you'd made it clear already: you hadn't).

Cheers, mwh

-- ... so the notion that it is meaningful to pass pointers to memory objects into which any random function may write random values without having a clue where they point, has not been debunked as the sheer idiocy it really is. -- Erik Naggum, comp.lang.lisp

More information about the Python-Dev mailing list