Comment on PEP-0238

[Marcin 'Qrczak' Kowalczyk]

Fri, 06 Jul 2001 16:30:34 GMT, Guido van Rossum <guido at python.org> pisze:

> Here's my plan, "new division in four phases":

I like it.

> 1. First we introduce a new function div() and a future statement that
>    makes integer division return a float result for a specific module.

Please aim at some replacement for floats here in the future.

Recently I needed exact calculations on fractional numbers.
The program renders texts in an artificial script (see
<http://qrczak.ids.net.pl/vi-001.gif> for a sample - resolution
is for printing at 300 dpi).

Conversion of a vectorized form of a character (lines, quarters
of ellipses and dots) into a bitmap needs reliable equality of
coordinates, to check whether lines meet or not, to produce proper
corners and ends, and to fit the shape into character size.

Coordinates here are rational by nature. A computed shape consisting
of evenly distributed lines is stretched vertically to fit into
character size.

I could do it on floats instead of rationals and test for equality
by comparing abs(difference) with a small epsilon, but it would be
ugly. The problem doesn't have intrinsic inaccuracies: it's digital,
not analog. Unambiguously either there is a horizontal line at the
top of the character or there is not. Lines either meet or not.

It would not work well on floats without changes also for another
reason. When a horizontal line of an integral width is positioned
such that after rounding to whole pixels it could be equally well
one pixel higher or lower, my code is careful to round coordinates
of its higher and lower outline in the same direction, so the line
has the correct width. Floating-point inaccuracies could make some
lines one pixel narrower or wider than others.

Unfortunately the program is not written in Python. I promise to
reimplement it in Python when it supports rationals, i.e. when it
guarantees that 1/3+1/6 == 1/2 :-)

This would also be another use for generators, but I don't need to
ask for them - they are going in anyway. This is another example
when generators or lazy lists are very useful: several stages of
processing should be pipelined, to not hold everything in memory as
pages of output are produced.

> I currently favor div(x, y) over x//y and x div y.

I like div(x, y) and x div y equally well. x//y is not as clear.

Don't you want to borrow Haskell's turning of an arbitrary binary
function into an operator thus: x `div` y? :-)  OCaml recently did.

> Maybe also add mod(x, y) for symmetry

Sure. This would remove the overloading of %, leaving it for sprintf.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK