Waldek Hebisch wrote:
Tom Verhoeff wrote:
It would be a good thing if gpc provided full support of the IEEE 754 Standard.
Unfortunatly (for numerical applications, at least), many compilers either provide no support at all, or provide only partial support. The latter is often even worse than the former.
For the record, GPC does not claim (and never has AFAIK) to support IEEE 754, wholly or partially. It aims to support standard Pascal arithmetic, sometimes a few Borland oddities, and to a large extent just uses the arithmetic present on the target machine. These things might happen to overlap with IEEE, more or less.
In particular, if you really aim for an IEEE compatible GPC, you must decide what to do about platforms with non-IEEE arithmetics. (I don't currently know which platforms are or aren't IEEE compatible.) Do you want to ignore them, or provide an IEEE emulation?
Another thing to do would be to compare IEEE and standard Pascal arithmetics for areas of conflict. Some issues, such as the original topic here, will be errors which the standard allows to ignore, so with some bending of the standard, it would be ok to return NaN etc. (optionally, of course). But there may be more serious conflicts, and before starting any work in this area, it would be useful to know whether they exist, and if so, where they are.
(You may now raise your hand to volunteer. :-)
<long IEEE advertisement snipped>
I have read some texts praising IEEE, but frankly, I am unimpressed. I find some properties of IEEE (denormals) harmfull -- if denormal support is active I really can not rely on hardware detection of overflow/underflow (I can loose acuraccy without any indication).
I share some of your doubts (perhaps as issue of mathematicians vs. number crunchers ;-). OTOH, I've briefly looked Kahan's paper, and I see that the state of things before (ok, the paper is a bit old) was not exactly satisfying ...
I haven't read all your references in deatail, may do when my time permits ...
AFAIK up from i387 Intel FPU complies to the letter (and probably also to the spirit) of the standard -- but if one wants to use IEEE features brain damage show up quickly. Namely, instead of providing separate instructions for different modes of operation processor has mode bits (I think it is what standard encourages) and if one wants to mix modes one has to change processor status word like crazy (costly even on newest processors and really kills performnce on Pentium).
I also don't like this, but that's not a decisive argument for me. What's more important for me is whether we can access the modes in a portable way. (This is mostly a backend question. I haven't looked at it yet.)
The resistor example is cute, but a number comes from calculation then really w can not assume that it will be non-negative -- if it can be zero the typically it can be of any sign.
I was also wondering how practically relevant this example is. Zero resistance doesn't (in practice) usually arise from nontrivial computations, and the resistance of a superconductor in parallel with a normal resistor also seems like a rather uncommon thing to compute AFAIK.
In summary, I'm not against IEEE support, but the main questions for me are:
- How many conflicts with other supported features are there? (IOW, how many extra options may we need?)
- Will it done in a "complete" way (rather than "works for me, fails to even compile for everyone else" ;-)?
And mainly:
- Who will do the work?
Frank