On Sun, Oct 30, 2011 at 11:15 AM, john_perry_usm <[email protected]> wrote:
> On Oct 29, 10:09 am, michel paul <[email protected]> wrote:
>> Here's a relatively minor issue that might not be minor for someone new to
>> Sage.
>>
>> In illustrating very simple probability as len(outcomes)/len(sample_space),
>> integer division occurs, so the probability becomes 0.
>
> The origin of this behavior is that the designers of the C language
> (RIP DMR) decided to use the slash to compute the quotient of integer
> division. Not all computer languages do this; Pascal used DIV, while
> Eiffel used a double slash (//). Python's designer, Guido van Rossum,
> mostly followed C syntax with operators, a choice which is nice for
> things like +=, understandable for != and the distinction between =
> and ==, and (as you have discovered) infelicitous for integer
> division.
>
>> Easy enough to correct - but it prompts discussion of why do we even have to
>> bother with that?
>
> Efficiency. Let me slightly change your example with E and S:
>
> sage: %timeit for each in xrange(100000): len(S)/len(E)
> 25 loops, best of 3: 27 ms per loop
> sage: %timeit for each in xrange(100000): float(len(S))/len(E)
> 5 loops, best of 3: 49 ms per loop
> sage: %timeit for each in xrange(100000): float(len(S))/float(len(E))
> 5 loops, best of 3: 60.1 ms per loop
> sage: %timeit for each in xrange(100000): 1.0*len(S)/len(E)
> 5 loops, best of 3: 959 ms per loop
>
> The answer is _correct_ each time for this problem. Notice that doing
> it with int's is much, much faster: your fix, for example, is 40 times
> slower than just using int's, because you're using
> sage.rings.real_mpfr.RealLiteral, which has a lot of software
> overhead. Dividing int's and float's is mostly hardware.
>
> For a lot of computations, efficiency is a sufficient concern that you
> want to stick with int's. Computing the quotient from integer division
> is actually useful behavior. You don't want to switch to floats.
>
> As others have noted, Python 3.0 is fixing this by, apparently,
> introducing Eiffel's // for the integer quotient. ;-)
>

// is in Python 2.x for integer quotient.  That's what we should
always use for floor division of integers in the Sage library.  It'll
continue to work fine *when* we transition to Python 3, which I see
happening during 2012.

I would to clarify something.  When you wrote above that the reason we
don't have / being int floor division by default is "Efficiency.",
that might suggest that having it be anything else would be slower.
However, that is definitely not the case.  See below, where when we
switch to division giving floats, the benchmark is unchanged (i.e.,
just as fast).

sage: S = [(die1, die2) for die1 in [1..6] for die2 in [1..6]]
sage: E = [throw for throw in S if sum(throw) == 7]
sage: timeit('len(E)/len(S)')
625 loops, best of 3: 278 ns per loop
sage: len(E)/len(S)
0
sage: from __future__ import division
sage: timeit('len(E)/len(S)')
625 loops, best of 3: 272 ns per loop
sage: len(E)/len(S)
0.16666666666666666

I was in a talk that Guido Van Rosum gave at Scipy 2006 in P3k, and
somebody (me?) asked him about Python using floor division for integer
division by default, and he humbly called it a design mistake on his
part.

> regards
> john perry
>
> PS: For some reason this reminds me of 
> http://www.elsop.com/wrc/humor/unixhoax.htm
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-edu" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/sage-edu?hl=en.
>
>



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
You received this message because you are subscribed to the Google Groups 
"sage-edu" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-edu?hl=en.

Reply via email to