On Fri, Jun 3, 2016 at 2:07 PM Jeroen Demeyer
wrote:
> On 2016-06-03 19:55, Simon King wrote:
> > Note that testing "a==1" goes through the coercion model as well.
>
> Sure, but that's not what you want to do. I propose to test something like
>
> (isinstance(a, int) and a == 1) or (type(a) is
With #20731 and #20777 merged I got the more interesting
sage: %timeit U(200,100)
1 loop, best of 3: 169 ms per loop
sage: %timeit V(200,100)
1 loop, best of 3: 196 ms per loop
sage: %timeit W(200,100)
1 loop, best of 3: 610 ms per loop
On 04/06/16 02:03, Nils Bruin wrote:
see #17692... and note that #20731 will speed up the second case.
On 04/06/16 02:03, Nils Bruin wrote:
Hopefully a little more robust benchmark:
sage: cython("""
: from sage.rings.integer import Integer
: from sage.rings.integer cimport Integer
: from sage.rings.rational import
Hopefully a little more robust benchmark:
sage: cython("""
: from sage.rings.integer import Integer
: from sage.rings.integer cimport Integer
: from sage.rings.rational import Rational
: from sage.rings.rational cimport Rational
: def U(a, n):
: cdef Integer A=a
:
On 2016-06-03 19:10, Vincent Delecroix wrote:
I am not sure we want to special case 1 in all multiplication/division.
Well, there are a lot of places in Sage where we use ~x currently. This
means that there is a lot of demand for computing 1/x.
--
You received this message because you are
On 2016-06-03 19:55, Simon King wrote:
Note that testing "a==1" goes through the coercion model as well.
Sure, but that's not what you want to do. I propose to test something like
(isinstance(a, int) and a == 1) or (type(a) is Integer and a == 1)
but then more efficiently. That should be
Am Freitag, 3. Juni 2016 19:11:01 UTC+2 schrieb vdelecroix:
>
> But using division or multiplication go through the coercion model. I am
> not sure we want to special case 1 in all multiplication/division. It is
> likely to slow even more our slow coercion model...
>
>
Note that testing
1 is already special cased in
sage: FreeGroup('ab')(1)
1
But using division or multiplication go through the coercion model. I am
not sure we want to special case 1 in all multiplication/division. It is
likely to slow even more our slow coercion model...
Vincent
On 03/06/16 18:43, mmarco
+1 to treating the 1/x as a special case in the coercion model.
It would also help with situations like
{{{
sage: F.=FreeGroup()
sage: 1/x
---
TypeError Traceback (most recent call last)
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 special-casing the 1/x case in __div__?
>
By analogy to __neg__ the new unary method
On Thu, Jun 2, 2016 at 1:33 PM, Volker Braun wrote:
> 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 special-casing the 1/x case in __div__?
According to my unscientific
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 special-casing the 1/x case in __div__?
Also, /x/ is a regular expression in JS. If Python ever wanted to support
that syntax then this would be stepping on
On Thursday, June 2, 2016 at 7:23:57 AM UTC-5, Samuel Lelievre wrote:
>
>
> 2016-06-02 14:01:16 UTC+2, Jeroen Demeyer:
>>
>> 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
2016-06-02 14:01:16 UTC+2, Jeroen Demeyer:
>
> 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.
>
>
14 matches
Mail list logo