proposed language change to int/int==float (was: PEP0238 lament)

Lloyd Zusman ljz at asfast.com
Wed Jul 25 20:16:54 EDT 2001


sburr at home.com (sburrious) writes:

> lomax at pumpichank.com (Frank "Cookie Jar" Lomax) wrote in message news:<mailman.996073073.17868.python-list at python.org>...
>> >   To many of us, programmers, 1/2 is 0 with 1 as a reminder:)
>>     > We are like children, and any child will say _for sure_ that 1
>>     > cookie for two children means one cookie for 1 child and 0
>>     > cookies for another:)
>> 
>> No, 1 cookie for 2 children always means no cookies for either child,
>> lots of crumbs for the dog to lick up, and years of therapy for the
>> entire family.
>> 
>> proof-that-integer-division-causes-thousands-of-disfunctional-families-
>>     per-year-and-must-be-abolished-ly y'rs, - frank
> 
> Unless you use the old trick of having one child divide the cookie and
> the other choose which piece he or she wants.
>
> would-there-were-such-a-solution-to-the-int-division-debate-ly y'rs,

Ah ... but there *is* such a solution:

One thread performs an arbitrary integer partitioning, and a second
thread chooses the value within the partition to return to the caller.

For example, to do 5/2, the first thread would arbitrarily pick one of
these 2-element partitions: [0,5], [1,4], [2,3].  It would pass this
partition to the second thread, which would also arbitrarily choose
one of the two numbers to return to the caller, with the other value
returned to the first thread.  E.g., if partition [1,4] happens to be
chosen by the first thread, the second thread could return either 1 or
4 to the caller, and the other value back to the first thread.

Not very efficient, not very accurate, not very useful, and not even
very desirable, but given intelligent threads operating under heavy
self-interest (in Python 6.0 maybe?), at least it would be fair.  :)


Actually, I'm very much in agreement with Guido's latest decision (to
wait until Python 3.0 before this change in division semantics goes
into full effect, tying it to _future_ in prior versions).  It's a
Solomonic solution, and I applaud your wisdom, Guido.


> sburrious

-- 
 Lloyd Zusman
 ljz at asfast.com



More information about the Python-list mailing list