> I vote for integer arithmetic in a higher resolution. Of course I'm biased,
> being a Forth programmer.
Wow! My general aversion to floating point also arises from my Forth
experience, but I was unwilling to admit it. I was sure that I would
be able to hear the laughing from several hundred miles away.
I compliment you on your taste in arcane programming languages, and on
your courage. :-)
--
> I vote for integer arithmetic in a higher resolution. Of course I'm biased,
> being a Forth programmer.
>
> Let's say we use twips. Then a piece of paper 100 inches on a side would be
> 1440000 twips. This is well within one cell. If we need to increase the
> resolution to accommodate units that aren't multiples of a twip, we can do it.
>
> One millimeter is 5/127 inch. If our unit is 1/127 twip, then a millimeter is
> also an integral number of units. The huge piece of paper is now 182880000
> units, which is still a single-precision number, though it is an order of
> magnitude short of overflow. It might not be safe to do this.
>
> A millimeter is 56+88/127 twips. If we use 1/3 twip as our unit, the error is
> 10/127 units. Over a meter of paper, that is 10000/127 units, or 26 twips. This
> is about half a millimeter. Is anyone going to notice?
>
> Scaling is done in Forth with the operator */ , which multiplies the first two
> numbers, giving a double-length (8 bytes, in our case) result, which is then
> divided by the third number. When calculating distances, I use double-length
> numbers to hold the squares.
>
> 4-byte floats do not have the precision of 4-byte integers. Only three bytes
> are mantissa. If we use floats (for instance to take a square root - I convert
> a double to float, take its square root, and convert to integer), they should
> be eight bytes.
>
> phma
--
Eric W. Sink, Software Craftsman
SourceGear Corporation
[EMAIL PROTECTED]
