Hi, Obviously I screwed up and just assumed, as a mathematician, that a method called
__invert__ would be for computing the inverse of something. There is no sense in which the bitwise version of that is the mathematical inverse of an *integer*, so I didn't even consider that possibility. I see now in the docs [1] that indeed __invert__ is "the bitwise inverse of the number obj." So I think we should change __invert__ for Sage integers to bitwise inverse, since it was simply a mistake (by me) to do otherwise in the first place. Obviously, this would be painful, but it's clearly the right thing to do. In my defense, when I implemented __invert__ on integers, I had no idea anybody but me would ever use Sage. Regarding, adding a new operator, I'm not convinced that's necessary -- surely we can just make 1/ efficient or have an explicit method (e.g., .multiplicative_inverse())? William On Thu, Jun 2, 2016 at 7:22 AM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > On 2016-06-02 15:52, Erik Bray wrote: >> >> 1. If flipper makes heavy use of bitwise negation then to prevent >> errors should explicitly cast values to a type where ~x means bitwise >> negation and not reciprocal (or anything else) in the first place. > > > No because it's not only in the Flipper program itself, it's also in their > user interface. > > But it's not just Flipper: ~x is an important difference between Sage > Integers and Python ints. Ideally, Integer and int should be compatible as > much as possible. > >> 2. I know this is probably anathema to mathematicians, but couldn't >> "1/" be viewed as a two character unary operator meaning reciprocal? >> :) > > > Sort of, but keep in mind efficiency. Often, taking the reciprocal is more > efficient than coercion followed by a general division. > > Second, there might be structures where reciprocal makes sense but not > division in general. I cannot immediately think of something, but it might > exist. > >> 3. Even if you managed to get / added as a unary operator in Python >> wouldn't you still have to support ~ for reciprocal for the >> foreseeable future if Sage is already using it that way? > > > I'm sure that every other problem is trivial compared to getting Python > accept this :-) > Anyway, you can use the preparser plus deprecations to deal with that. > >> 4. Before going through the hazard that is adding new syntax to >> Python, would this be easier to implement just in the Sage interpreter >> as syntactic sugar instead? > > > No, because we really want this in Python code, not just the Sage command > line. Currently, ~x is used a lot in the Sage library. > > > Jeroen. > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
