Nick Maclaren <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
