This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] math.h fixes


On Thursday 02 April 2009 02:02:07 Howland Craig D (Craig) wrote:
> If I had realized that llrint() llrintf() were missing when I added
> the documentation, I would have supplied the functions as I did for
> llround.  (I had based my evaluation of whether functions existed or
> not on math.h, which is obviously the wrong way of checking.  I'll have
> to re-check for missing functions in a more vigorous way.)
>
> I have created llrint() and llrintf() from the existing lrint() and
> lrintf() functions.  They have been tested and compared against the
> RHEL5 library (GLIBCx) and pass almost all test cases.  llrint()
> fails a single test case, but lrint() fails exactly the same single
> case.  It actually appears to be an Intel problem, as the rounding is
> done by the floating point hardware, not in the s_llrint.c/s_lrint.c
> source code.  Because of these two reasons, I'm submitting it despite
> the one incorrect case.
>
> The specific case that fails is:
> 	double arg=1.5-LBDL_EPSILON;
> 	lrint( arg) and llrint( arg) return 2, and
> 	lrint(-arg) and llrint(-arg) return -2,
> when rounding is set to FE_NEAREST.
> The correct answers are 1 and -1.  The same value with the other 3
> rounding modes works fine.  The test case of 1.5+LDBL_EPSILON passes (in
> all rounding modes).
>
> Since my addition messes up Ken's patch, I've adjusted his patch
> (math.h.patch) and included it, too (skipping the qualifiers for
> llrint&llrintf).
>
> Craig

OK, thanks.
Ken


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]