MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

Re: floating point numbers / decode_binary()



Followup to:  <3.0.1.32.19961216203209.006a04c4@pop.kaiwan.com>
By author:    Brack <slayer@kaiwan.com>
In newsgroup: local.moo
>
> I thought floating point numbers only had a precision up to like 15-17
> digits or so. It seems the largest floating point number I can use is
> 1.79769313486231e+308. But, if I put a real long float number, such as 
> ;1.79769313486231580793728971405303415079
> it will round off to 1.79769313486232e+308. But, I can't re-eval
> 1.79769313486232e+308 because it will give me an overflow. Also if I try
> 1.797693134862315807937289714053034150791 it gives an overflow tb as well.
> 

I presume that is 1.79....e+308 you have there?  It is indeed possible
for the normal output rounding to end up with a number that cannot be
read back in due to overflow; this can be circumvented by using
floatfmt() [or whatever the function is called again] using a very
large precision (such as 9999 - the MOO server will force it down to a
sane number.)  Unfortunately these types of effects are part of the
nature of floating point.

> 
> I also posted on Lambda while this list was down, I noticed if you try
> something like decode_binary("~80~03~90") I correctly get {128, 3, 144} but
> if I try decode_binary("~80~03~90", 1) it comes out as {-128, 3, -112}; I
> was told it was due to using signed integer types rather than unsigned in
> the server code.
> 

This is a sheer bug; this should be avoided by casting to
(unsigned char) before casting to (int):

	*n = (int) (unsigned char) (*ch);

[or whatever...]

	-hpa
-- 
PGP public key available - finger hpa@zytor.com
Key fingerprint: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
"The earth is but one country, and mankind its citizens."  --  Bahá'u'lláh
Just Say No to Morden * The Shadows were defeated -- Babylon 5 is renewed!!


References:

Home | Subject Index | Thread Index