in reply to losing precision reading numbers from file

Instead of using floats, you might consider using rationals (or bigrats). This will preserve the precision because you retain the number as-is. 1/3 remains as 1/3, not 0.333..., so you don't get that rounding problem. Converting to a floating representation is not difficult, if needed; often it's not needed because you are interested in the integer values for times.

  • Comment on Re: losing precision reading numbers from file

Replies are listed 'Best First'.
Re^2: losing precision reading numbers from file
by pg (Canon) on Nov 12, 2005 at 02:54 UTC

    Not all floats are rationals, for example sqrt(2). If you force it to a rational, the process itself reduces precision.

      Not all floats are rationals, for example sqrt(2). If you force it to a rational, the process itself reduces precision.

      What you say is mathematically true, but computationally false. The decimal representation of sqrt(2) requires an infinite number of digits, hence of memory, which would be very expensive. Almost all "floats" in computers are already approximations, and often they are bad ones. It is a simple matter to represent a rational number as a pair of ordered integers. 1/3 would be simply 1,3. In floating point, you'd get something like 0.3333333333333333, which is close, but inexact. This will come back and bite you if you don't take extraordinary precautions like keeping track of a delta and comparing equality as being within the range of the delta. This is awkward and often unnecessary.

      The OP's interest appeared to be in keeping track of dates, which can of course be represented as integers, even if only the integer number of seconds (or milliseconds, or whatever) between two events. Simple integer calculations could be performed to obtain more useful values of days, hours, minutes, etc.