X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Mon, 27 Mar 2000 14:10:38 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: Unnormals??? In-Reply-To: <200003260433.XAA26337@mescaline.gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, 25 Mar 2000, Eli Zaretskii wrote: > > So, yes, I'm now convinced we should treat unnormals like NaN, even though > the Intel/IEEE definition of a NaN doesn't really hold for them. > > I disagree. Making the unnormals stand out is a valuable debugging > aid, since an unnormal can never be a result of any meaningful > computation, unlike a NaN. Sure. I didn't meant to say that unnormals should be treated as indistinguishable from NaN, i.e. the distinction is to be kept, at least in situations like printf("%Lf"). But in the definition space provided by C99, we have only limited choices what to fpclassify() an unnormal as: infinite NaN normal subnormal zero An unnormal or pseudo-nan, as defined by intel/IEEE, fits none of these categories but 'NaN' or 'normal'. In arithmetic operations, with SIGFPE(invalid) blocked, as we do it, an unnormal automatically turns into a NaN. OTOH, unnormals and pseudo-nan can in principle be associated with a unique, normalized value that is either normal or subnormal, so we could classify them as such, too. If we follow this second route, the only problem is when and how to do that conversion. We'ld have to put in a SIGFPE default handler to do it for us, I think. > C99 leaves us no other practicable choice. > > Since C99 doesn't mention the unnormals, and since they aren't NaNs, I > don't see how the standard prevents us from reporting unnormals as such. The standard gives a fixed list of classes of floating point values. It seems to not allow for any extension of that list, either. Unnormals aren't covered by any of those classes, so we'll have to subsume them into one of them. NaN is the most natural choice, I think. I'm not voting against treating them specially in printf(), where the standard does leave us the choice to add explanatory text to the "nan" output. But for all other situations, our blocking of SIGFPE(invalid operation) effectively makes unnormals turn into NaN, already. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.