On Sat, 31 May 1997, J Wunsch wrote:
> Well, you should perhaps have posted the expected output... instead of
ok, without posting the code again, the output is below.
> 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())
what's non-standard about long double?
they're standard ANSI C types ... ? much of my software
relies on this precision - i can't do 64 bit int-to-string-to-int
conversions without them, at least not cleanly, and not without
alot of code re-writing.
> 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)?
i'm sorry - i'm lost. i know Borland 16-bit C uses 80-bit
long doubles. from gcc sizeof(), i get 96 bits for BSD doubles
(8 bytes), and 144 bits for BSD long doubles (12 bytes). so
even with BSD doubles, i should get better precision,
... i assume.
> > void main (unsigned char argc, unsigned char **argv) {
> Don't get caught in comp.lang.c with this. :) It's an invalid
> definition of main, thus the behaviour is implementation-dependant.
> gcc could have exited immediately without violating the standard.
ahhh! :) everyone says this - but exit() never returns, so main
never returns anything, so IMHO, main should always be type void.
> Also, your blatant use of unsigned char for everything doesn't look
> right. At least with gcc, using an unsigned char as a loop index
> counter isn't doing any good and is likely to slow down your code. It
> doesn't save space at all, since (i think) %dh, %dl, and %edx are all
> a single register for gcc, regardless of how many bits you're using.
yes, i know. but this is code i'm porting!
apple2 -> msdos -> bsd (it's been around :)
plus, there are other reasons (shifting, etc.)
i work on many systems, including embedded XT's.
> --
> cheers, J"org
thanks. as you can see below, DOS long doubles and powl()
keep all my accuracy ... whereas BSD can't even subtract 9
from 18446744073709551616.000000.
please help me! :)
> joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
BSD
- ffffffffffffffff 15.000000
- ffffffffffffffff 255.000000
- ffffffffffffffff 4095.000000
- ffffffffffffffff 65535.000000
- ffffffffffffffff 1048575.000000
- ffffffffffffffff 16777215.000000
- ffffffffffffffff 268435455.000000
- ffffffffffffffff 4294967295.000000
- ffffffffffffffff 68719476735.000000
- ffffffffffffffff 1099511627775.000000
- ffffffffffffffff 17592186044415.000000
- ffffffffffffffff 281474976710655.000000
- ffffffffffffffff 4503599627370495.000000
- ffffffffffffffff 72057594037927936.000000 <- loss of precision
- ffffffffffffffff 1152921504606846976.000000
- ffffffffffffffff 18446744073709551616.000000
+ 18446744073709551616.000000
+ 18446744073709551616.000000 (this should be the result above - 9)
- 0fffffffffffffff 18446744073709551616.000000
- 00ffffffffffffff 1152921504606846976.000000
- 000fffffffffffff 72057594037927936.000000
- 0000ffffffffffff 4503599627370496.000000
- 00000fffffffffff 281474976710656.000000
- 000000ffffffffff 17592186044416.000000
- 0000000fffffffff 1099511627776.000000
- 00000000ffffffff 68719476736.000000
- 000000000fffffff 4294967296.000000
- 0000000000ffffff 268435456.000000
- 00000000000fffff 16777216.000000
- 000000000000ffff 1048576.000000
- 0000000000000fff 65536.000000
- 00000000000000ff 4096.000000
- 000000000000000f 256.000000
- 0000000000000000 16.000000
- 00000000000000001 1.000000
10000000000000000
DOS
- ffffffffffffffff 15.000000
- ffffffffffffffff 255.000000
- ffffffffffffffff 4095.000000
- ffffffffffffffff 65535.000000
- ffffffffffffffff 1048575.000000
- ffffffffffffffff 16777215.000000
- ffffffffffffffff 268435455.000000
- ffffffffffffffff 4294967295.000000
- ffffffffffffffff 68719476735.000000
- ffffffffffffffff 1099511627775.000000
- ffffffffffffffff 17592186044415.000000
- ffffffffffffffff 281474976710655.000000
- ffffffffffffffff 4503599627370495.000000
- ffffffffffffffff 72057594037927935.000000
- ffffffffffffffff 1152921504606846975.000000
- ffffffffffffffff 18446744073709551615.000000
+ 18446744073709551616.000000
+ 18446744073709551605.000000
- ffffffffffffffff 18446744073709551615.000000
- ffffffffffffffff 1152921504606846975.000000
- ffffffffffffffff 72057594037927935.000000
- ffffffffffffffff 4503599627370495.000000
- ffffffffffffffff 281474976710656.000000
- ffffffffffffffff 17592186044415.000000
- ffffffffffffffff 1099511627775.000000
- ffffffffffffffff 68719476735.000000
- ffffffffffffffff 4294967295.000000
- ffffffffffffffff 268435455.000000
- ffffffffffffffff 16777215.000000
- ffffffffffffffff 1048575.000000
- ffffffffffffffff 65535.000000
- ffffffffffffffff 4095.000000
- ffffffffffffffff 255.000000
- ffffffffffffffff 15.000000
ffffffffffffffff
-------------------------------------------------------------------------
Sleep: a sign a caffeine deprivation ... http://www.anchorage.net/~un_x
-------------------------------------------------------------------------