[Python-Dev] Numerical robustness, IEEE etc.

[Michael Hudson]

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