Karl Ramberg <karl.ramberg at chello.se> wrote:
	I'v mostly been bitten by fractions in points.
	Points do not like fractions: why ?

Why indeed.  As originally conceived, Points were (I believe) for
representing points on the display, so it made sense for the x and
y coordinates to be SmallIntegers (at that time, 14 or 15 bits, I think).

But why I ask why is "what actually goes wrong?"

Point creation and accessing don't mind Fractions.
Point arithmetic doesn't mind Fractions.
Point truncation and rounding doesn't mind Fractions.
 (Why is there no Point>>roundTo: ?)
Point comparison doesn't mind Fractions.
Point converting doesn't mind Fractions.
Point copying doesn't mind Fractions.
Point polar coordinates doesn't mind Fractions.
Point printing doesn't mind Fractions.

For things like Point>>#to:intersects:to: and #interpolateTo:at:
it is essential NOT to convert Fractions to Floats.

In a quick test of several dozen Point operations, I haven't found any
that doesn't like Fractions.

So tell us exactly what goes wrong, and let's FIX it!

	It would be nice if classes that don't like fractions would
	convert the fraction to float or integers as needed, and not bug
	the user about this kind of stuff.
	
Indeed, and there's a fair bit of code in Point to do that, when
appropriate.  If some such code is missing, let's fix it, but for
some geometric applications it is vital NOT to convert Fractions to Floats.