<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Floating point is just wierd.<BR>
very large + very small = the same very large<BR>
I realize that is approximately correct, but approximations can be worrisome.<BR>
And it can be costly to avoid making them as well. Stuck.<BR>
<BR>
> Of course, if you compare a 32-bit integer to a 64-bit float, this<BR>> won't happen. But I think the 64-bit float should be compared to<BR>> a 64-bit integer.<BR><BR>
<BR>
Eh? A 64bit float cannot store all 64bit integer values.<BR>
Typically 64bit float has about 53bits of precision.<BR>
Local float.h:<BR>
<BR>
#define DBL_MANT_DIG 53 /* # of bits in mantissa */<BR> #define FLT_MANT_DIG 24 /* # of bits in mantissa */<BR><BR>
<BR>
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.<BR>
I was surprised to step through my hash table code and see floating point used. :)<BR>
<BR>
<BR> - Jay<BR> <BR>> Date: Mon, 19 Apr 2010 21:46:16 -0500<BR>> From: rodney_bates@lcwb.coop<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] INTEGER (and floating point)<BR>> <BR>> <BR>> <BR>> Mika Nystrom wrote:<BR>> > <BR>> > Modula-3 already uses floating point for this, which has the advantage<BR>> > you don't need to worry what the base is. <BR>> <BR>> The designers of Algol 60 gave us several good new ideas, but one place<BR>> they did a huge disservice was in renaming what had been called "floating<BR>> point" as "real". This was and still is a lie.<BR>> <BR>> One ugly property that floating point has is that the smallest interval<BR>> between representable values keeps getting larger as the value gets<BR>> larger. Moreover, for representations of equal bit counts, floating<BR>> will always eventually get to the point that it no longer can even represent<BR>> the integers. The interval eventually becomes two, then four, eight,<BR>> etc. (if the exponent is a power of two, as it usually is).<BR>> <BR>> There are places where you care about large value range *and* precision<BR>> down to the integers, and file sizes are likely to be one of them.<BR>> National budgets might be too. Ditto times. Sometimes you can stand<BR>> the erosion of precision in large values, but not always.<BR>> <BR>> Of course, if you compare a 32-bit integer to a 64-bit float, this<BR>> won't happen. But I think the 64-bit float should be compared to<BR>> a 64-bit integer.<BR>> <BR>> > Mika<BR>> > <BR> </body>
</html>