[M3devel] INTEGER (and floating point)

[Jay K]

Floating point is just wierd.

very large + very small = the same very large

I realize that is approximately correct, but approximations can be worrisome.

  And it can be costly to avoid making them as well. Stuck.

 

> Of course, if you compare a 32-bit integer to a 64-bit float, this
> won't happen. But I think the 64-bit float should be compared to
> a 64-bit integer.


 

Eh? A 64bit float cannot store all 64bit integer values.

Typically 64bit float has about 53bits of precision.

Local float.h:

 

  #define DBL_MANT_DIG    53   /* # of bits in mantissa */
  #define FLT_MANT_DIG    24   /* # of bits in mantissa */


 

Now, interestingly, the IA64 floating point registers are large enough, they do have at least 64bits of precision, and integer division/mod is implemented using floating point.

I was surprised to step through my hash table code and see floating point used. :)

 


 - Jay
 
> Date: Mon, 19 Apr 2010 21:46:16 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER (and floating point)
> 
> 
> 
> Mika Nystrom wrote:
> > 
> > Modula-3 already uses floating point for this, which has the advantage
> > you don't need to worry what the base is. 
> 
> The designers of Algol 60 gave us several good new ideas, but one place
> they did a huge disservice was in renaming what had been called "floating
> point" as "real". This was and still is a lie.
> 
> One ugly property that floating point has is that the smallest interval
> between representable values keeps getting larger as the value gets
> larger. Moreover, for representations of equal bit counts, floating
> will always eventually get to the point that it no longer can even represent
> the integers. The interval eventually becomes two, then four, eight,
> etc. (if the exponent is a power of two, as it usually is).
> 
> There are places where you care about large value range *and* precision
> down to the integers, and file sizes are likely to be one of them.
> National budgets might be too. Ditto times. Sometimes you can stand
> the erosion of precision in large values, but not always.
> 
> Of course, if you compare a 32-bit integer to a 64-bit float, this
> won't happen. But I think the 64-bit float should be compared to
> a 64-bit integer.
> 
> > Mika
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100420/80f1ae97/attachment-0002.html>