From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,70016ed51014902d
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: IEEE fp & Java
Date: 1996/12/02
Message-ID: <dewar.849554220@merv>#1/1
X-Deja-AN: 201935709
references: <01bbdcb5$7500ab30$24af1486@pc-phw> <E1nLxo.Ly3@world.std.com>
 <dewar.849319316@merv> <E1o04r.D0F@world.std.com> <dewar.849366601@merv>
 <Pine.SUN.3.95.961202015240.14089B-100000@eskimo.com>
organization: New York University
newsgroups: comp.lang.ada
Date: 1996-12-02T00:00:00+00:00
List-Id: <comp.lang.ada>


Clayton said

"Wasn't there a long cross-posted thread back in winter '93-'94 about an
ambiguity in the IEEE fp standard that left parts of the standard
implementation-defined re: rounding intermediate results? I don't recall
the details, perhaps someone else reading here does. Was that ambiguity
a factor in the Alpha and Mips fp designs?"


That involves a very subtle point regarding rounding in some unusual cases,
where indeed there is a one-bit ambiguity depending on where rounded is
done in the denormal case. However, this has nothing whatsoever to do with
DEC's anbd SGI's decision not to proper support denormals *at all*.