(j3.2006) (SC22WG5.3484) what now, 754r?

Malcolm Cohen malcolm
Fri Sep 14 01:54:52 EDT 2007


Please don't send to both J3 and WG5: J3 is already on the WG5 list.
(It's bad enough getting two copies of all WG5 messages, I don't want
a third one.)

On Fri, 14 Sep 2007 09:51:10 +0900, Dan Nagle <dannagle at verizon.net> wrote:
> Both J3 and WG5 should now be pondering what to do
> in the face of various scenarios regarding
> either the substantial delay
> or eventual withdrawal of 754r.

Why?

Standardisation of 754r is proceeding.  Contrary to your earlier
post, it has not "failed", they're just restarting the review
process with a fresh document (because the change bars got too
onerous with the old one).

I appreciate that IEEE don't do things the same way that ISO does
and this might be confusing to some committee members, but really
nothing tragic is unfolding here, it's just (very roughly!) the
IEEE equivalent of noting that there were large changes after
the first CD ballot, after the second CD, and going for a third CD
ballot to continue to resolve the differences.  Just as in the
ISO process where having an extra CD ballot doesn't imply the
standard is going to fail, in the IEEE process restarting the
whatever-they-call-this-ballot-level ballot with a new document
doesn't imply imminent destruction.

There's really no story here.  754R isn't yet finished.  That's it.
It is, IMHO, slightly *less* likely to crash and burn now than
at various other points over the last few years.

In fact the ballot restart is probably good news as much as it is
bad news, since it gives interested parties another chance to become
involved.  (Yes, it is bad news to the extent that they haven't
finished yet, but I wouldn't want to play it up for much more than that.)

> Do we want to try to keep what we've got,
> or remove it and hope for a more stable target
> at some point in the future?

By all means let's get rid of c14 entirely.
Oh wait, that wasn't what you meant?

It has nothing to do with the radix argument to selected_real_kind,
which is in any case independently useful: there have been F90/95
implementations on non-binary-fp machines, and dual binary/nonbinary
machines.  Since decimal hardware is slated to hit the market in the
near future (according to a TLA's press releases anyway) removing this
would be very short-sighted.

> I'm asking now so as to allow time for considered views
> to be expressed before the meetings when action will be required.

Why is action going to be required?

We ALREADY "gutted" the 754R support feature.
None of the cute things that are in 754R (recent drafts) that
were not in 754 have been added to F2008.

Make no mistake, the 754R document is a better document than 754
in many ways, and as a standard even as it is now it would be a
much better standard in many ways - even though some/many/all agree
that it's gone toofar/notfarenough/toperfection in other ways.

And it's almost certain to become a standard before F2008, maybe even
before F2008 reaches FCD status.

If it gets massively delayed beyond that, or dropped altogether, that
is the time to remove RADIX= from IEEE_SELECTED_REAL_KIND (note *NOT*
removal from SELECTED_REAL_KIND).  No debate is required, because that
is simply what we would have to do (since we cannot reference nonexistent
features in standards).

That time seems quite a long way off right now.

Cheers,
-- 
Malcolm Cohen, Nihon Numerical Algorithms Group KK, Tokyo, Japan.



More information about the J3 mailing list