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 eric@sourcegear.com