RfD: IEEE-FP 0.5.2

David N. Williams wrote:
> Ed wrote:
> > Andrew Haley wrote:
> >> Ed <nospam@invalid.com> wrote:
> >> ...
> >>> [...]
> >
> >>> If one doesn't know for sure that letting an exception through
> >>> is safe, then throwing it seems the smarter/easier option.
> >> Sure, but it should be at the programmer's discretion.
> >
> > In that case forth programmers should have IEEE iors in the
> > event they wish to throw the exceptions.
>
> We already do:
>
> DPANS94 IEEE 754-2008
> -41 loss of precision inexact
> -42 floating-point divide by zero divideByZero
> -43 floating-point result out of range overflow
> -46 floating-point invalid argument invalid
> -54 floating-point underflow underflow
>
> At least I'm guessing "loss of precision" was intended for
> "inexact".

Are all the IEEE exceptions/flags covered by ANS ior's?

Would there be any value to an app being able to distinguish
IEEE iors from others? I don't know - just asking.

>
> The draft I'm working to push out has a new subsection in the
> implementation section, which I've copied below. It attempts to
> provide a context for IEEE exceptions that works without
> knowledge of whatever exception words might eventually be
> provided.
> ...

That's fine. But how to handle exceptions encountered during
compilation/interpretation probably needs to be defined now.

Otherwise you'll have one IEEE compiler accepting "1E9000"
and another rejecting it. Under ANS this is allowed - but ANS
was catering for all forth systems. For IEEE forths, it would
be of obvious benefit if all compilers handled source in the
same manner.

Andrew Haley wrote:
> Ed <nospam@invalid.com> wrote:
> ...
> > I should have said "an IEEE system". But yes, even an IEEE program
> > may hang as a result of overflow producing an INF which then finds
> > its way into a routine that only works with finite numbers. An IEEE
> > programmer can't simply assume that exceptions will pass through a
> > program unhindered.
>
> Sure, but that's true of floating-point arithmetic in general: if an
> overflow prevents a loop from converging, for example.

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.

> > > ...
> > > > IEEE only addresses applications. It makes no judgement as
> > > > to what a compiler or interpreter might need.
> > >
> > > I disagree with all of this paragraph.
>
> > Does IEEE specify how a forth text interpreter shall behave
> > wrt to numeric input?
>
> No.

Good

> 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.

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.

Ed <nospam@invalid.com> wrote:
> Andrew Haley wrote:
> > Ed <nospam@invalid.com> wrote:
> > ...
> > > I should have said "an IEEE system". But yes, even an IEEE program
> > > may hang as a result of overflow producing an INF which then finds
> > > its way into a routine that only works with finite numbers. An IEEE
> > > programmer can't simply assume that exceptions will pass through a
> > > program unhindered.
> >
> > Sure, but that's true of floating-point arithmetic in general: if an
> > overflow prevents a loop from converging, for example.

> 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.

> > 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.

> 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, and is compliant with Standard Forth.

Andrew.

Ed <nospam@invalid.com> wrote:
> David N. Williams wrote:
> > Ed wrote:
> > > Andrew Haley wrote:
> > >> Ed <nospam@invalid.com> wrote:
> > >> ...
> > >>> [...]
> > >
> > >>> If one doesn't know for sure that letting an exception through
> > >>> is safe, then throwing it seems the smarter/easier option.
> > >> Sure, but it should be at the programmer's discretion.
> > >
> > > In that case forth programmers should have IEEE iors in the
> > > event they wish to throw the exceptions.
> >
> > We already do:
> >
> > DPANS94 IEEE 754-2008
> > -41 loss of precision inexact
> > -42 floating-point divide by zero divideByZero
> > -43 floating-point result out of range overflow
> > -46 floating-point invalid argument invalid
> > -54 floating-point underflow underflow
> >
> > At least I'm guessing "loss of precision" was intended for
> > "inexact".

> Are all the IEEE exceptions/flags covered by ANS ior's?

> Would there be any value to an app being able to distinguish
> IEEE iors from others? I don't know - just asking.

I can't think of any additional value.

> > The draft I'm working to push out has a new subsection in the
> > implementation section, which I've copied below. It attempts to
> > provide a context for IEEE exceptions that works without
> > knowledge of whatever exception words might eventually be
> > provided.
> > ...

> That's fine. But how to handle exceptions encountered during
> compilation/interpretation probably needs to be defined now.

> Otherwise you'll have one IEEE compiler accepting "1E9000"
> and another rejecting it. Under ANS this is allowed - but ANS
> was catering for all forth systems. For IEEE forths, it would
> be of obvious benefit if all compilers handled source in the
> same manner.

In my view, we should avoid prescribing anything that is not required
for IEEE FP conformance.

This seems to me not to be strictly relevant to IEEE FP: overflow in
numeric input can happen in any system, and standard Forth has always
striven to avoid prescribing behaviour in such cases. There are quite
a few extensions I'd like to have (FPICK, for example) but this
specification shouldn't be a grab bag for things people want to change
about floating-point.

Andrew.

Andrew Haley wrote:
> Ed <nospam@invalid.com> 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.

However you will be writing more "incorrect" programs under IEEE.
That's because one is expected to take into account nan/infs and the
effects of math functions, divide-by-zero, and overflow producing
nans/infs. One would need to be an oracle.

It's not unlike writing portable ANS Forth code. No doubt it can
be done - but has anyone ever got it right the first time around

> > > 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.

> > 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.

Ed <nospam@invalid.com> wrote:
> Andrew Haley wrote:
> > Ed <nospam@invalid.com> 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.

Andrew Haley wrote:
> Ed <nospam@invalid.com> wrote:
> > Andrew Haley wrote:
> > > Ed <nospam@invalid.com> wrote:
> > > ...
> > > > 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.

It should be a compliance issue. There's no reason for an IEEE
compiler to numeric overflow errors.

A language standard that ignores quality and can't explain why
it permitted variability isn't likely to be taken seriously by
prospective users.

Ed <nospam@invalid.com> wrote:
> Andrew Haley wrote:
> > Ed <nospam@invalid.com> wrote:
> > > Andrew Haley wrote:
> > > > Ed <nospam@invalid.com> wrote:
> > > > ...
> > > > > 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.

> It should be a compliance issue. There's no reason for an IEEE
> compiler to numeric overflow errors.

But none of this has anything to do with IEEE. It's entirely
orthogonal to IEEE arithmetic. Trying to hook your personal
preference to an IEEE extension in this way is an abuse of the
process.

If you were to propose a change to Standard Forth that had this
effect, then I would support it. But it's got *nothing* to do with
IEEE, except for the fact that both concern floating-point. This is
not about the quality of a proposal, but its relevance.

Andrew.