From owner-sc22wg5@open-std.org Fri Sep 14 08:32:20 2007 Return-Path: X-Original-To: sc22wg5-dom6 Delivered-To: sc22wg5-dom6@open-std.org Received: by open-std.org (Postfix, from userid 521) id 4145DDCBAA; Fri, 14 Sep 2007 08:32:20 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 2235 seconds by postgrey-1.18 at pingo.cv.ihk.dk; Fri, 14 Sep 2007 06:32:18 UTC Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by open-std.org (Postfix) with ESMTP id 5070AD75F6 for ; Fri, 14 Sep 2007 08:32:03 +0200 (CET DST) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=6100k-he-9) by ns.nag-j.co.jp with esmtp (Exim 4.50) id 1IW42F-0006f4-14 for sc22wg5@open-std.org; Fri, 14 Sep 2007 14:48:11 +0900 Date: Fri, 14 Sep 2007 14:54:52 +0900 To: "WG5 List" Subject: Re: (j3.2006) (SC22WG5.3482) what now, 754r? From: "Malcolm Cohen" Organization: Nihon Numerical Algorithms Group KK Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-2022-jp MIME-Version: 1.0 References: <20070914015221.16433D8610@open-std.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20070914015221.16433D8610@open-std.org> User-Agent: Opera Mail/9.02 (Win32) Sender: owner-sc22wg5@open-std.org Precedence: bulk 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 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.