An earlier topic on the same problem is http://groups.google.com/group/sage-devel/browse_thread/thread/2821c770f3c62efd
Apparently True*2 was fixed (now returns 2), but True*SR(2) wasn't (still returns 1). I think Robert Bradshaw made the patch back then, so he knows how to fix this (something to do with coercion). It was also discussed whether implicit coercion from booleans to integers (or other numbers) was to be allowed at all. There were votes for following python convention, which is what was done back then. I like the TypeError here to avoid bugs, but don't mind following python convention either. Marco On 25 jul, 00:44, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Sat, Jul 24, 2010 at 2:29 PM, Burcin Erocal <bur...@erocal.org> wrote: > > Hi, > > > At Sage Days 24, I learned that Python allows the user to do arithmetic > > with bools: > > > In [1]: 5+True > > Out[1]: 6 > > > In [2]: True + False > > Out[2]: 1 > > > In [3]: 5+False > > Out[3]: 5 > > > Sage seems to follow this convention as well: > > > sage: 5 + True > > 6 > > sage: 5. - True > > 4.00000000000000 > > > I can't see any use cases for this convention. I believe all these > > examples should just raise a TypeError. IMHO, code relying on this > > feature is very likely to be buggy. > > > Apparently the symbolic ring doesn't handle things so well [1], but I'm > > not decided what the "fix" should be. :) > > > [1]http://trac.sagemath.org/sage_trac/ticket/9560 > > > Any comments? > > For whatever reason, bools subclass int, > > sage: isinstance(True, int) > True > > so to accept ints and reject bools, we'd have to do a lot of special > casing. This is useful, for example > > sage: sum(is_prime(p) for p in range(100)) > 25 > > - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
