RE: IP-block fees and ARIN

[Jim Fleming <JimFleming@doorstep.unety.net>]

On Monday, April 13, 1998 7:00 PM, Karl Denninger[SMTP:karl@mcs.net] wrote:
<snip>
@> 
@> Karl, whether it's owned or not, if we run out we could be in deep doodoo.
@
@But we're simply not going to.  This insane argument was used three years
@ago and the fact is that it just didn't happen.  Further, its not that it
@didn't happen due to aggregation either - that has a function on the routing
@table size, but it has nothing to do with the number of addresses IN USE.
@

This reminds me of a grahics system that I once worked on
that had fixed point binary numbers. The "binary point" was on the
LEFT and a number like .1011 was equal to 1/2+1/8+1/16 (.5+.125+.0625)
or .6875. Additional 0 digits could be added at the RIGHT, such as
.101100000 and not change the number.

Instead of addressing pixels as (50,60) we could use (20%, 40%) and
pixels on the screen could be added BETWEEN the other pixels to
grow the screen to various sizes.

People used to argue with me and claim that this all required a
floating point processor (which we did not have) to handle the math.
This was not the case, we just used integers and "assumed" the
binary point was in a certain position. It worked fine and was fast.

Also, people would claim that for various screen sizes we were wasting
resolution bits because there were zeroes on the right of the coordinate
values. They could not seem to get it. They got all wound up in how to
do floating point and how on earth pixels could be added between the
others as opposed to the top or sides of the screen.

After a point, it was not worth trying to explain the approach. People
were determined that bit growth as screen sizes grew should happen
from right to left as opposed to left to right. They could not imagine
putting all of the coordinate bits into play and defining the RIGHT
ones to be significant at a later date. They just could not get it...

...sometimes that happens...
-
Jim Fleming
Unir Corporation
IBC, Tortola, BVI