On 10/29/11 10:24 PM, kcrisman wrote:
On Oct 29, 10:40 pm, Jason Grout<[email protected]> wrote:
On 10/29/11 10:35 AM, David Joyner wrote:
I would suggest that this "feature" in Python, was "fixed" in Python 3.0.
Sage has not yet upgraded to 3.0.
Luckily, Python includes a time machine to import things from the future ;)
sage: from __future__ import division
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: len(E)/len(S)
0.16666666666666666
Yeah, but won't that screw up some other stuff in Sage?
I don't think it would screw up internal stuff.
Plus, the "right" answer is 1/6, not n(1/6), and I think it's
reasonable to want to show that answer without needing to use Integer
or 1* (though perhaps not currently possible).
Most likely, we aren't going to change len() to return Sage Integers, so
we're stuck with the Python integer, which is to return floating point
division in this case.
What about the cardinality being an int instead of an Integer? Just
curious what you think.
I'm curious about the combinat people's reasons. I don't have an
opinion on that yet, since I know those guys think long and hard about
most issues, so I'm sure there must be a good reason.
Thanks,
Jason
--
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.
