Re: IEEE-FP 0.5.2 - Exception handling

Ed <nospam@xxxxxxxxxxx> wrote:
Andrew Haley wrote:
Ed <nospam@xxxxxxxxxxx> wrote:
...
The problem is much greater with IEEE. IEEE has nans/infs - which
can pop up anywhere. These aren't numbers and consequently they'll
never converge and get stuck in a loop.

Maybe, maybe not. I'm not convinced that converting overflow to Inf
makes an incorrect program more likely to get stuck in a loop, and
IEEE has the overwhelming advantage that it's reasonably easy to
detect such an overflow. But this is arguing about the qualities of
IEEE arithmetic iteself, which is off-topic for this discussion.

It's a fact of life that not everyone can be convinced.

That's true.

IEEE specifies how numeric input conversion should be done, but
it places no requirements on the language with respect to
floating-point literals.
...

They stipulate how an IEEE *application* might handle numeric input.

This makes no sense. Numeric input conversion is done by the
system itself, not by an application.

I'm sorry that you see no difference between the options available
to an application, and how a compiler behaves.

I'm trying to discover what you're talking about. Are you talking
about the way that >FLOAT is different from numeric conversion in the
text interpreter?

IEEE says nothing about compilation. One assumes that even IEEE
would balk at the notion that it could be useful for a compiler to
accept "1E9000" and compile an INF.

That seems reasonable enough

To what end? What does entering "1E9000" and compiling
INF or max-float possibly give you - apart from a headache ?

, and is compliant with Standard Forth.

If you mean that Standard Forth permits one to ignore numeric
conversion errors - as one of a range of options - then yes, it is
"compliant". Anyone is free to pick the worst option.

Exactly. This is a quality of implementation issue, not a compliance
issue.

Andrew.
.

Relevant Pages
Loading