Re: RfD: IEEE-FP

David N. Williams <williams@xxxxxxxxx> wrote:
Andrew Haley wrote:
> David N. Williams <williams@xxxxxxxxx> wrote:
>> Okay, the new draft is copied below.

> With a bit of care I reckon we should be able to do the whole thing
> with a small number of new required words.
>
> It's worth saying (with a "should") that implementations should
> separate the floating-point stack and the data stack. It's hard to
> write many phrases for the comparison operators without this
> assumption. I don't know that there are any implementations of Forth
> on IEEE-compliant hardware that share stacks.

That's my preference as well.

>> IEEE 754-2008 defines three basic binary fp formats, binary32,
>> binary64, and binary128, plus three corresponding extended
>> binary formats, whose parameters are shown in Tables 1 and 2
>> below.
>
> Why is it necessary to say all this? IEEE 754 is a reference document
> for this specification.

I don't feel strongly about it. It did take me some back and
forth to get straight the details of the formats most likely to
be implemented, so it was partly an aid to my failing memory.
And I wanted to emphasize that the most likely of all, binary80,
is allowed, although not given a name in IEEE. I was also
thinking that IEEE 754-2008 is not freely available.

True anough.

> It's worth saying here that FDUP x F! x F@ F= shall always return
> true. This ensures that the size of an FVARIABLE is big enough to
> hold a stack element.

Okay.

This one may be a bit controversial, I warn you. I think some Forths
use the full 80-bit FP stack but 64-bit F@ and F!. I think that's
broken, but that's just IMO.

I thought that omitting the .<digits> option for <significand> in
<significand><exponent> was probably an oversite in ANS94. At least
I can't see any reason not to allow it. The other option, to allow
a decimal point with at least one trailing digit and no <exponent>
would likely be controversial, because of the old practise that an
embedded dot means an integer double (IIRC), so it was marked for a
separate RfD.

I see.

>> Nan loads shall be encoded as if they are binary integers fitting
>> into the trailing significand field of the default fp format, with
>> corresponding least signficant bits. An ambiguous condition exists
>> if the input load is too large for the default format.
>
>> [**IEEE is not specific about the least significant bit, AFAICT,
>> but this makes sense to me.]
>
> Make them go to Inf, surely.

Maybe, but I don't see why a NaN of any sort should convert to
anything but a NaN of some sort.

Yes, I agree now. Thinko.

>> [**Separate RfD for some of this? If so, which part?]
>
>> 6.2 Hexadecimal input
>> ---------------------
>
>> IEEE requires a text format for numbers with a hexadecimal
>> significand,
>
> No it doesn't. It's just a "should".

Well...

---------
5.4.3 Conversion operations for binary formats 5.4.3.0

Implementations shall provide the following formatOf
conversion operations to and from all supported binary
floating-point formats; these operations never propagate
non-canonical floating-point results.
- formatOf-convertFromHexCharacter(hexCharacterSequence) See
5.12 for details.
- hexCharacterSequence convertToHexCharacter(source,
conversionSpecification) See 5.12 for details. The
conversionSpecification specifies the precision and
formatting of the hexCharacterSequence result.
---------
5.12 Details of conversion between floating-point data and
external character sequences
[...]
Implementations shall provide exact conversions from each
supported binary format to external character sequences
representing numbers with hexadecimal digits for the
significand, and shall provide conversions back that recover
the original floating-point representation, except that a
signaling NaN might be converted to a quiet NaN. See 5.12.1
and 5.12.3 for details.
----------

Indeed. I wish they'd make up their minds.

And 5.12.3 includes a bnf which appears to be the same as the
C99 hex significand plus radix 2 decimal exponent format.

Yes, but 5.12.3 doesn't matter so much because it's a "language
standards should."

>> 7 GLOSSARY
>
>
>> SF! ( f: r s: sf-addr -- )
>> SF@ ( sf-addr -- f: f )
>> DF! ( f: r s: df-addr -- )
>> DF@ ( sf-addr -- f: f )
>
>> The specification for these DPANS94 words is amended to
>> explicitly require conversion to or from the respective IEEE
>> binary32 or binary64 interchange formats, with exact conversion
>> in either direction for signed zero, signed infinity, and real
>> numbers to a wider format, and with roundTiesToEven for
>> conversion of real numbers to a narrower format (see IEEE
>> Sec. 5.4.2, formatOf-convertFormat). The conversion of nans
>> shall preserve the sign and signaling bit, shall not signal an
>> exception, and should treat payloads according to IEEE 6.2.3.
>
>> [**Should the current rounding mode be used, instead of
>> roundTiesToEven?]
>
> Yes, or it should be left undefined. Otherwise, we'd have to insert
> extra instructions to twiddle the rounding mode for every load and
> store.

I'm really not sure about this...

Well, I'm sure that requiring roundTiesToEven would require such
instructions to be inserted.

>> 7.6 Math functions
>> -------------------
>
>> The Forth words FABS, FMAX, FMIN, and FSQRT are covered
>> elsewhere.
>
>> The DPANS94 specification for the following words is extended to
>> adopt the corresponding IEEE behavior. See IEEE 9.2, "Recommended
>> correctly rounded functions", and 9.2.1, "Special values".
>
>> F** FACOS FACOSH FALOG FASIN FASINH FATAN FATAN2
>> FATANH FCOS FCOSH FEXP FEXPM1 FLN FLNP1 FLOG FSIN
>> FSINCOS FSINH FSQRT FTAN FTANH
>
> No no no no no! All that correctly rounding does is trade
> unpredictability in results for unpredictability in execution time.
> Given Forth's history, in many cases predicatble execution time is
> more imprtant than strict rounding.

Isn't "correct rounding" a measure not just of predictability but
of accuracy?

Yes. i.e. it's a predictably accurate result.

In any case I wouldn't object to shifting that emphasis to a set of
quality of accuracy tests.

I would object very much to quality of accuracy tests. :-)

> Anyway, it's only a "should" in IEEE.

Okay.

>> 7.8 Nearest integer functions
>> -----------------------------
>
>> FCEIL ( f: r1 -- r2 ) new
>> FLOOR ( f: r1 -- r2 )
>> FROUND ( f: r1 -- r2 )
>> FNEARBYINT ( f: r1 -- r2 ) new
>> FTRUNC ( f: r1 -- r2 ) new
>
>> These words correspond to the respective IEEE required
>> operations:
>
>> roundToIntegralTowardPositive
>> roundToIntegralTowardNegative
>> roundToIntegralTiesToEven
>> roundToIntegralExact
>> roundToIntegralTowardZero
>
>> See IEEE 5.3.1, "General operations" and 5.9, "Details of
>> operations to round a floating-point datum to integral value".
>> The names are based on C99. FTRUNC has already passed a CfV.
>> FNEARBYINT performs the function of whichever of the other
>> four corresponds to the current rounding mode [**IIUC].
>> No word is defined for IEEE roundToIntegralTiesToAway.
>
>> [**Separate RfD for the new words?]
>
> If we have settable rounding modes, I really can't see the point of
> all these words. FLOOR is just FLOOR-ROUNDING{ FNEARBYINT }ROUNDING
> Etc, etc.

I was sort of thinking FNEARBYINT could be removed instead! :-)
Seems like a fairly complicated word.

FNEARBYINT is often (usually?) just a single fround instruction.
FLOOR is

savemode; floor-rounding; fround; restore-rounding

Andrew.
.

Relevant Pages

  • Re: RfD: IEEE-FP
    ... You don't have to define new words for all the IEEE 754 operations. ... "Details of conversion between floating-point data ... into the trailing significand field of the default fp format, ... roundToIntegralExact ...
    (comp.lang.forth)
  • Proposal: String::Format::General
    ... It provides format string parsing and output assembly, you provide the code that implements the individual conversion characters. ... Format syntax is kind of a cross between sprintf and strftime, but how close it is to each of these depends on the semantics implemented by the user. ... Note that the following is pre-alpha documentation; the interface to the output conversion code has changed since yesterday, ... conversion character, and contain a number of optional fields which may ...
    (comp.lang.perl.modules)
  • Proposal: String::Format::General
    ... This should be considered pre-Alpha, since it has changed since yesterday, and I am seriously considering passing the format parameters to the output conversion code as a hash reference instead of a large number of arguments. ... Some limited heading capability is provided. ... This module provides a formatter class which allows its user to ...
    (comp.lang.perl.modules)
  • Proposal: String::Format::General
    ... It's almost a meta-formatter with the user providing individual conversion code behind a sprintf/strftime-like interface. ... A format is basically a string into which data are to be inserted. ... conversion character, and contain a number of optional fields which may ...
    (comp.lang.perl.modules)
  • Re: Proposal: String::Format::General
    ... It's almost a meta-formatter with the user providing individual conversion code behind a sprintf/strftime-like interface. ... A format is basically a string into which data are to be inserted. ... conversion character, and contain a number of optional fields which may ...
    (comp.lang.perl.modules)