From owner-freebsd-hackers  Sun Jun  1 02:16:23 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id CAA14940
          for hackers-outgoing; Sun, 1 Jun 1997 02:16:23 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA14924
          for <hackers@FreeBSD.ORG>; Sun, 1 Jun 1997 02:16:06 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA16036; Sun, 1 Jun 1997 19:14:54 +1000
Date: Sun, 1 Jun 1997 19:14:54 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199706010914.TAA16036@godzilla.zeta.org.au>
To: bde@zeta.org.au, un_x@anchorage.net
Subject: Re: Borland 16bit bcc vs cc/gcc (float)
Cc: hackers@FreeBSD.ORG
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>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