Date: Sun, 1 Jun 1997 19:14:54 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, un_x@anchorage.net Cc: hackers@FreeBSD.ORG Subject: Re: Borland 16bit bcc vs cc/gcc (float) Message-ID: <199706010914.TAA16036@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>i don't have a man page for fpsetprec() (2.2.1).
>how do i find out about it?
Look for it in the header files. It is the same as fpsetround() except
it sets precision stuff instead of rounding stuff. fpsetround() is
documented.
>and if i set "long double"
>precision, will pow/fmod, etc, work as powl/fmodl ?
No. That would be broken. pow/fmod only accept double precision args
and return a double precision result.
>> Printing of long double values with full precision is not
>> supported in FreeBSD. This is why the same value is printed
>> for `ld-9' as for `ld'.
>
>are there plans to? why shouldn't it?
It's behined a few thousand other things in my list of FreeBSD things
to do.
> do { *p++ = itoan(fmod(val, base)); printf("- %s %Lf\n", s, val);
> val/=base;
> ^^^^^^^^^
>> Bug. The fractional part needs to be subtracted somewhere, perhaps
>> using `val = floor(val / base);' here.
>
>actually, speed is too important to call floor() each time.
If speed is important, use a better (probably machine-dependent) algorithm.
>i don't see why i should have to, i find precision always
>rounds down (in fact, that's why i do the .49999999 thing).
>i've been using the code for years, and it works fine with
>64 bit string-int conversions, (under DOS ...).
fmod() rounds towards 0. Perhaps floor() is only necessary for debugging
if fmodl() is used. When fmod() is used, rounding to nearest (even) in
the conversion from long double to double always rounds up for the value
in the example.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706010914.TAA16036>