From owner-freebsd-hackers Sat May 31 13:53:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12110 for hackers-outgoing; Sat, 31 May 1997 13:53:23 -0700 (PDT) Received: from iceberg.anchorage.net. (root@iceberg.anchorage.net [207.14.72.150]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA12088 for ; Sat, 31 May 1997 13:53:18 -0700 (PDT) Received: from aak.anchorage.net (ai-131 [207.14.72.131]) by iceberg.anchorage.net. (8.6.11/8.7.3) with SMTP id LAA00517; Sat, 31 May 1997 11:49:47 -0800 Date: Sat, 31 May 1997 12:42:33 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net To: Bruce Evans cc: freebsd-hackers Subject: Re: Borland 16bit bcc vs cc/gcc (float) In-Reply-To: <199705310930.TAA08679@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, Bruce Evans wrote: > This code needs to use nonstandard long double math functions > (powl() and fmodl()) to work for values > DBL_MAX. FreeBSD > does not support these functions. > This code also requires long double precision to actually work. > Long double precision is not the default in FreeBSD. You can > set it using fpsetprec(). i don't have a man page for fpsetprec() (2.2.1). how do i find out about it? and if i set "long double" precision, will pow/fmod, etc, work as powl/fmodl ? > 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? > >I'm not much surprised that the use of non-standard components (long > >double) produces unexpected results. You multiply a long double with > >a double (result of pow()), so who tells you whether the compiler does > >it by first extending the result of pow() to long double format (thus > >`inventing' missing precision digits), or by first truncating the long > >double (although i wouldn't expect this)? > > The ANSI C standard :-). However, the standard doesn't specify that > long double precision is strictly more precise than double precsision > or the amount of precision of double precsision. right. and sizeof() tells me there is a difference. float = 4 bytes double = 8 bytes long double = 12 bytes it seems a little silly to have long doubles, and not to be able to make good use of them! :) you can't use them with math functions ... you can't print them ... /*****************************************************************************/ unsigned char *ftous (unsigned char *s, long double val, unsigned char base) { /* float to unsigned string */ /* if base>10 adjust */ unsigned char *p=s; /* to alpha numeral */ if ( val < 0 ) val = -val; /* val+=0.49999999; <- needed for Borland C */ ^^^^^^^^^^^^^^^ Shouldn't be necessary. The algorithm requires `val' to have no fractional part. 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. 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 ...). } while ( val >= 1 ); *p = 0; return( strrvs(s, 0) );} /*****************************************************************************/