[Patches] import floatdivision # 1/2==0.5
firstname.lastname@example.org (Skip Montanaro)
Tue, 13 Jun 2000 11:34:24 -0500 (CDT)
>> It will almost certainly not pass muster with Guido
Dave> Well, he called my previous proposal "kind of cute" and even "a
Dave> fine starting point" :)
Yes, it's a good starting point. Marc-Andre mentioned a "pragma" keyword,
which would be a useful addition for other things. My complaint is
basically that coopting import's semantics is wrong. Given that Guido
thinks your proposal is a good place to start, I still think the best
short-term approach is to teach your users about explicitly using floating
point numbers in division where they want floating point results.
(Short-term might be < six months. Once 1.6 is out, we can hash out
possible syntax and experiment with implementations.)
Dave> I chose to submit a patch for (3) because it involves no
Dave> inconvenience to others, and leaves the possibility of an even
Dave> better solution open.
Well, sort of. If it was adopted, it would get used. Taking stuff out of
the language is much harder than putting stuff into the language. If you
adopt "import floatdivision" today, then later implement a more universally
accepted pagma keyword, you'll be stuck with a wart on import's semantics
for a couple revisions anyway, since it takes time to deprecate existing
While it might be convenient for you and others today, I suspect you'll find
it inconvenient later if you have to modify your code to work with a
>> Also, while the patch provides a scoped solution, within a specific
>> scope there is no way to undo it (I suppose you could also recognize
>> "import intdivision"). What if, after executing "import
>> floatdivision" you wanted integer division later on (say, during some
>> loop arithmetic)? Your patch doesn't allow that behavior.
Dave> We do not intend to make use of scoped changes at all, though
Dave> others may. This is a way of making a language change available
Dave> to us, without forcing it on others or breaking library modules.
Dave> Changing the semantics of / constantly would be hideous
Dave> programming practice.
That your proposal restricts the change to the current scope is a good
thing, but immaterial to my argument. My point was that once your semantic
change is enabled, you can't disable it until you happen to pop out to a
wider scope. If you want to return floating point results for numeric
purposes, integer division (whose properties are very useful for loop
control), will be imprecise and can lead to subtle bugs which can be just as
hard to detect as the truncating effects of integer division.
Skip Montanaro, email@example.com, http://www.mojam.com/, http://www.musi-cal.com/
On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived
his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: