Re: RfD: IEEE-FP
- From: "David N. Williams" <williams@xxxxxxxxx>
- Date: Tue, 16 Jun 2009 15:19:27 -0400
Andrew Haley wrote:
> David N. Williams <williams@xxxxxxxxx> wrote:
>> Marcel Hendrix wrote:
>
>> >> The syntax specification in DPANS94 12.3.7, "Text input
>> >> number conversion", shall be replaced by
>> >
>> >> Convertible string := { <significand><exponent> | <special> }
>> >> [**Separate RfD to allow
>> >> [<sign>]<digits0>.<digits> as well.]
>> >
>> > Note that currently " .666 " is a well-formed double number in many
>> > Forths.
>
>> Right. That's why its marked for a separate RfD. DPANS94
>> mentions only that a trailing decimal point means a double
>> number, which doesn't conflict with syntax above. DPANS94 seems
>> to be silent about embedded or leading decimal points in double
>> numbers, not even calling that an ambiguous condition.
>
> We have to distinguish between the syntax of the language, which
> doesn't need to change, and the sytax of I/O conversion, which does.
> We really don't need to be breaking double-numbers in the language!
What double-numbers in the language would be broken? AFAICT, the
only ones with decimal points in the langauge are those where it's
trailing.
>> There are at least two people (Ed and Marcel) who prefer having a
>> constant for NaN, and I'll add myself to the list.
>
> Add me to that list.
Good! Based on the results of previous CfV's that could be a
majority. :-)
>> What would people think of something like the following pair of
>> words, to be recommended, not required:
>
>> >NAN ( d -- f: nan)
>> NAN> ( f: nan -- s: d )
>
>> The first word leaves the quiet nan with the sign of d and
>> with load |d|. The second leaves the load as |d| and sign(d)
>> = sign(nan). It is an ambiguous condition if the input |d|
>> has too many bits to fit into the default float significand
>> fraction, or if the input load is too large for a signed,
>> double number. [**Note that d is large enough for binary32,
>> binary64, and binary80 loads.]
>
>> An alternative would be to leave out the sign.
>
> That seems a bit heavyweight. I think I understand the reasoning
> about propagating diagnostic information, but I can't recall ever
> seeing NaNs used for that.
>
> You know, I think that what we *really* need is something with the
> functionality of Java's doubleToRawLongBits
> <http://java.sun.com/javase/6/docs/api/java/lang/Double.html#doubleToLongBits(double)>
> and then people who really need all this stuff can get everything they
> need. It would surely be a lot easier to have one word that gets you
> all the bits rather than for us writing this appendix to try to guess
> what a user will want them for.
>
> Unfortunately, the width of the data stack varies across systems
> whereas the size of an IEEE double doesn't, so I can't immediately
> think of any sane way to make this work in Forth. We could, I
> suppose, insist that SF! and SF@ use some sort of well-known
> endianness.
The words >NAN and NAN> would face the same endianess problem,
especially any high-level reference version. I don't know of
any systems which are not either completely big endian or
completely little endian for higher precision fp. Are there
any?
If you do something like doubleToRawLongBits, it seems to me you
would have to have single and default versions as well. Or do I
misunderstand?
>> >> SF! ( f: r s: sf-addr -- )
>> >> SF@ ( sf-addr -- f: f )
>> >> DF! ( f: r s: df-addr -- )
>> >> DF@ ( sf-addr -- f: f )
>> >
>> > [..]
>> >
>> >> 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.
>> >
>> > No payload, please.
>
>> I'm less sure of this, just because of the reasonable "should"
>> in IEEE 6.2:
>> [...]
>
>> On the other hand, one can argue that propagation of diagnostic
>> information is hardly relevant for data exchange, which seems to
>> be the focus of SF!, etc.
>
> No, that's not the focus of SF!, etc. Single-precision storage is
> useful for saving space in array, databases, etc.
Humn! Saving space never crossed my mind!
> I can't understand why SF! etc should not preserve the payload. Is
> there some overhead I don't know about?
That's because the payloads for higher precision, like the
default will often be, are more than the 22 bits for
single-precision (they're the full fractional part of the
significand minus 1 bit). Unless I made a mistake:
load bits
binary32 22
binary64 51
binary80 62
binary128 111
I guess a language specification is allowed to specify a maximum
of 22 bits. Maybe that's a good idea.
-- David
.
- Follow-Ups:
- Re: RfD: IEEE-FP
- From: Elizabeth D Rather
- Re: RfD: IEEE-FP
- From: Andrew Haley
- Re: RfD: IEEE-FP
- References:
- Re: RfD: IEEE-FP
- From: David N. Williams
- Re: RfD: IEEE-FP
- From: Marcel Hendrix
- Re: RfD: IEEE-FP
- From: David N. Williams
- Re: RfD: IEEE-FP
- From: Andrew Haley
- Re: RfD: IEEE-FP
- Prev by Date: Re: If you were developing a database in Forth...
- Next by Date: Re: RfD: IEEE-FP
- Previous by thread: Re: RfD: IEEE-FP
- Next by thread: Re: RfD: IEEE-FP
- Index(es):
Relevant Pages
|
