Re: [sage-devel] PEP idea: unary division

Eric says *I'm all for more operators supported by syntax* This sounds like a terrible idea to me. I assume you do not endorse ALL operators. Just look at the machine-level operations available in a typical CPU. Also look at the kinds of syntax freely invented by physicists, chemists, and

Re: [sage-devel] PEP idea: unary division

On Sun, Aug 12, 2018 at 11:31 PM Saul Schleimer wrote: > > Dear all - > > Just for the record, I started using flipper in sage and immediately got > bitten by this. I'll vote for ~n meaning some version of bit flipping > (preferably python's). Another possibility--since we're talking about

Re: [sage-devel] PEP idea: unary division

Dear all - Just for the record, I started using flipper in sage and immediately got bitten by this. I'll vote for ~n meaning some version of bit flipping (preferably python's). best, saul On Monday, June 6, 2016 at 6:13:19 AM UTC-4, Jeroen Demeyer wrote: > > On 2016-06-06 10:39, Erik

Re: [sage-devel] PEP idea: unary division

On 2016-06-06 10:39, Erik Bray wrote: But then you have to deal with the usual mess of ensuring that the __rdiv__ method handles division for those objects. FYI: __rdiv__ does not exist in Cython (__div__ is always used), so there is not so much mess. -- You received this message because

Re: [sage-devel] PEP idea: unary division

On Thu, Jun 2, 2016 at 4:22 PM, Jeroen Demeyer wrote: > On 2016-06-02 15:52, Erik Bray wrote: >> 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

Re: [sage-devel] PEP idea: unary division

On 3 June 2016 at 15:25, William Stein wrote: > > > On Friday, June 3, 2016, Samuel Lelievre wrote: >> >> >> >> Le jeudi 2 juin 2016 22:33:45 UTC+2, Volker Braun a écrit : >>> >>> I'm guessing that this won't fly with upstream ;-) >>> >>> Is it really

Re: [sage-devel] PEP idea: unary division

On Friday, June 3, 2016, Samuel Lelievre wrote: > > > Le jeudi 2 juin 2016 22:33:45 UTC+2, Volker Braun a écrit : >> >> I'm guessing that this won't fly with upstream ;-) >> >> Is it really faster? A new __unary_div__ method everywhere? Is it really >> faster than

Re: [sage-devel] PEP idea: unary division

On 2016-06-02 17:17, William Stein wrote: have an explicit method (e.g., .multiplicative_inverse())? That's bad for several reasons: 1. Python types won't support it. This new operator is meant to increase compatibility between Sage and Python. I think it's very unlikely that Python types

Re: [sage-devel] PEP idea: unary division

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.

Re: [sage-devel] PEP idea: unary division

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

Re: [sage-devel] PEP idea: unary division

On Thu, Jun 2, 2016 at 2:01 PM, Jeroen Demeyer wrote: > Summary: Python should have a unary division operator (a.k.a. reciprocal), > written "/x", analogous to unary subtraction (a.k.a. negation), written > "-x". And then "~x" should be what is intended by Python, namely

[sage-devel] PEP idea: unary division

Summary: Python should have a unary division operator (a.k.a. reciprocal), written "/x", analogous to unary subtraction (a.k.a. negation), written "-x". And then "~x" should be what is intended by Python, namely bitwise negation. Rationale: Mark Bell gave a talk at Sage Days 74 and he