|
Traps are in general impossible to implement in modern multi-core or
multiprocessor parallel hardware. The whole trap notion assumes a
sequential execution model, which is fine if you are willing to give up
many orders of magnitude of performance; those with access to such
hardware are not willing. The whole question is very architecture
dependent - traps are doable on a Beowulf cluster design for example,
but are absolutely hopeless on a grid machine. So far, the only semantic solution to these problems that is both architecturally viable on all known architectures and also solves the mathematical difficulties is to carry a (larger) set of status flags with each operand, with rules as to how the function and the argument values and flags produce the result values and flags. In larger and more powerful machines the implementation would directly represent the flags in a long datum; in less powerful, more sequential machines (i.e. desktops) the same semantics can be implemented using global flags in dedicated registers and create-on-need memory. The right choice of status flags is a mathematical matter I'm not competent to address, but w/r/t the zero question, it would seem that {negative infinitesimal, positive infinitesimal, true integral zero} would be a useful minimal set. There would also be the several flavors of null - {undefined, missing value, propagated error} and so on. All the difficulties presently being addressed appear to arise from trying to jam too much semantic on too few bits. Ivan Vincent Lefevre wrote: On 2007-05-27 13:52:52 +0100, Nick Maclaren wrote: |