Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Dec 2003 00:51:54 -0800
From:      David Schultz <das@FreeBSD.ORG>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject:   Re: Implementing C99's roundf(), round(), and roundl()
Message-ID:  <20031201085154.GA74618@VARK.homeunix.com>
In-Reply-To: <20031201182219.O4431@gamplex.bde.org>
References:  <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> <20031201182219.O4431@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 01, 2003, Bruce Evans wrote:
> And we really shouldn't do arithmetic on the NaNs.  ceilf() should return
> its arg for a NaN, but it's not clear what happens for -x.  Well, I checked
> what happens starting with the QNaN x= 0.0 / 0.0.  Almost everything is
> broken:
> - gcc miscomputes 0.0 / 0.0 at compile time.  It gives a positive NaN, but
>   the npx would give a negative NaN ("Real Indefinite" = the same one except
>   with the opposite sign).
> - gcc invalidly optimizes -x by ORing in the sign bit (even without -O).
>   It should do the same as the npx (which is to not change anything).
> - printf() doesn't print the sign bit for NaNs.
> - C99 requires printf() to misspell "NaN" as "nan"

I thought about that, but I didn't know that the distinction
between positive and negative NaN mattered to anyone.  If you
ignore these distinctions, then any amount of arithmetic on a NaN
does nothing, save the possibility of raising an exception.

In this case, swapping the sense of the 'if' ought to fix the
problem, although an isnan() check could be added instead to be on
the safe side.

> All the other corner cases need to be checked.  It's possibly to check
> all 2^32 cases for floats (once you know the correct results).

If I had a better way to compute the correct results, I'd commit
that instead.  ;-P  (Okay, actually, I could just use the npx.)

> Other things to check: setting of exception flags.  I'm not sure if the
> settings by ceil() are the right ones and the only ones.

What little POSIX says about flags seems to be identical for
ceil() and round().



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031201085154.GA74618>