[Curious] Integer division => fraction

Richard A. O'Keefe ok at cs.otago.ac.nz
Thu Jun 12 02:26:25 UTC 2003


	Just had an interesting discussion with Dean (over on e-Lang)
	about integer division semantics.  He pointed out (and I agree)
	that most people tend to find it it confusing that "3/4" results
	in a fraction rather than coercing to Float by default.
	
I an only suppose that the reason is that they are used to languages
that don't _have_ fractions (ratios).  Anyone who is used to
mathematical languages like Macsyma, Reduce, Maccauley, &c would
definitely expect integer division to be mathematically exact, and
so would anyone used to Common Lisp or Scheme.

I don't see any merit in kicking compatibility with ANSI and other
Smalltalks out of a 20th-storey window just because people who have
not bothered to inform themselves about Smalltalk arithmetic are
confused.  There will be PLENTY of other things to confuse them
until they take the trouble to read one of the many Smalltalk books
around.  When they have read a textbook, if they are _still_ confused,
_then_ we have reason to consider a change.

	My questions: What do you think about this issue?

I think Smalltalk gets it exactly right.
I heartily wish that more programming languages got it right too,
and I would fight tooth and nail to preserve the wonderful
property "Smalltalk integer arithmetic always gives you right
answers if there is enough memory left."

	Are you personally surprised if you get a fraction back?

Never.  Pleased is the word.

	Has it bitten you in unexpected places?

Never.

	Have you actually ever had the need for coercing to fractions
	instead of floats?

But it *doesn't* "coerce to fractions".  It just gives the right answer.
When the exact right answer of an integer division is an integer, that's
what you get.  When it isn't, you get the exact right ratio.

Converting to to float, now THAT would be coercion.  THAT would be
giving wrong answers.

	Can you think of "typical" applications that would be
	harmed by coercing to floats?
	
Yes.  Ones that are intended to be portable.  23+ years of Smalltalk-80
definition and tradition, and 5 years since the ANSI Smalltalk standard
came out, say clearly and unambiguously what Integer/Integer is supposed
to do.  Break that, and who knows _what_ chaos might ensue?

Can you think of "typical" applicatinos that would be harmed by
leaving #/ compatible with other Smalltalks?

If you use a Fraction where a Float is *required*, then it will
quietly turn into a Float.  For example,

    (3/4) sqrt

doesn't say "you idiot, you gave me a Fraction but I need a Float",
it answers 0.8660254037844385.



More information about the Squeak-dev mailing list