Re: RfD: IEEE-FP

Aleksej Saushev <asau@xxxxxxxx> wrote:
Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:

Aleksej Saushev <asau@xxxxxxxx> wrote:
"David N. Williams" <williams@xxxxxxxxx> writes:

Please have a look, and offer criticisms, both general and
specific, and suggestions.

What I don't understand in all recent proposals is why they exist at
all. Where's the practice large enough to have all those in
standard?

Many Forth floating-point extensions support IEEE arithmetic

I don't see those "many," what are they?

Certainly gforth does, and AFAIK SwiftForth and iforth. None of these
are complete implementations of IEEE arithmetic, and we're exploring
what it might take to do a decent job of completing it.

Even when they use underlying IEEE FPN operations, what do they
support in particular?

IEEE 754, in its 1985 form, standardizes basic arithmetic and a bunch
of conversion operations, along with some standard number formats.
The Wikipedia page is quite nice if you don't have access to the
specification: http://en.wikipedia.org/wiki/IEEE_754-1985. Forths on
IEEE-compatible hardware support all the standard basic arithmetic and
many of the recommended functions and predicates. To the best of my
knowledge no Forth completes the full set.

IEEE 754 also requires directed roundings, which to the best of my
knowledge Forths do not support, and we're discussing wordsets that
might be useful to support them. If we can come up with something
reasonably sane we'll propose it to implementors. The same goes for
exceptions.

Can I see an overview? Where are those problems that arise from
difference between implementations? Inconsistency between them?

What is the purpose of standard?

The same as any language standard: it clarifies what is common, and
makes useful features available to developers to use portably. In the
case of floating-point arithmetic, it's hard to do a good job of
writing libraries without any knowledge of the properties of the
underlying floating-point model. This was made pretty clear to me
recently when I was writing approximations for erf.

What I see is that you're blocking future implementors from entering
the field, even when they are more sane and have more clear view of
what they are doing.

I don't really understand how codifying the very well-established
industry standard model of IEEE floating-point arithmetic is going to
be a barrier to entry. After all, whatever comes out of this process
will be an optional wordset.

The point of discussing this optional extension is to figure out a
useful common wordset. By the time we get to the end of the
discussion I think we'll have a reasonably small set of words that
will be not too difficult to implement on IEEE hardware, and will
be useful. It'll provide a common set of names for functions that
some Forth systems already support.

I think you confuse design and standartization. What you're doing is
effectively the design of a new, academic Forth, in contrast to
standardizing the practical one.

Well, you're welcome to that opinion, but I think you are wrong. IEEE
arithmetic has proved itself over the last twenty or so years to be
superbly practical, and Forth is a superbly practical language.

You'd better standardized practical things, like search order stack.

Let they who care about search order stacks write the proposal.

At the moment there is a bunch of wacky proposals being thrown around,
many of which may be abandoned. But there's no way to do without the
discussion process.

There _is_ a way to go without any discussion. You write a library,
make it the best in the field, win user acceptance, then the library
becomes standard without any doubt.

I can't think of any practical way to write this as a library. it
requires access to the underlying hardware, with interfaces not
provided by standard Forth. Most, if not all, of what we've been
discussing involves fairly small additions to existing floating-point
wordsets.

All this talk about rounding modes and exceptions is interesting, but
not key. It might well turn out that there's nothing that can be done
with them. The key part is standardizing the basic operations and
data formats, and this is common to may Forths already.

Andrew.
.

Relevant Pages

  • Re: cobol data format!!! urgent!!!
    ... misunderstood what "conformance to a standard" means. ... Cobol people 'know' binary floating-point is ... The quotation above is from IEEE 754. ... same as the IBM System/390 format which isn't the same as the Unisys MCP ...
    (comp.lang.cobol)
  • Re: cobol data format!!! urgent!!!
    ... Like most standard committees, the 10967 folk take the attitude 'if ... support it in hardware i.e. all except IBM and Unisys. ... A mandated IEEE 754 implementation ... "Two subsections are dedicated to the floating-point divide, ...
    (comp.lang.cobol)
  • Re: RfD: IEEE-FP
    ... If somebody has a link for the IEEE 754:1985 final draft, ... I guess a bound implementation to some ... standard makes it harder to support specific platforms. ...
    (comp.lang.forth)
  • Re: ieee_arithmetic
    ... I don't know when the IEEE ... support was added, but it was probably two or three years ago. ... XL Fortran provides several ways that allow you to query and control ... the floating-point status and control register of the processor ...
    (comp.lang.fortran)
  • Flexible Floating-Point Standard Proposal (was: Decimal ... JOSS)
    ... proposing is a standard for the following: ... A software floating-point support package for a computer that will ... Why is the committee dealing with IEEE ...
    (sci.math.num-analysis)