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

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 :

[sage-devel] Re: Users can permanently modify GF(5).list()

On Friday, June 3, 2016 at 3:54:57 PM UTC-4, Nils Bruin wrote: > > It could be that the undecorated code is bug-free > That is obviously fine, just don't decorate it with a memoization operator. But don't code that is manifestly wrong with a memoziation operator but then fixed by a subtle

[sage-devel] Re: Users can permanently modify GF(5).list()

On Friday, June 3, 2016 at 12:42:29 PM UTC-7, Volker Braun wrote: > > > I understood what you want, but I'm saying that its bad to have a bug in > the code that is then worked around by a decorator. Just don't put the bug > in the code to begin with. Apart from being the right thing to do, its

[sage-devel] Re: Can we still not get canonical labels and graph isomorphisms from nauty?

On Friday, June 3, 2016 at 8:09:29 PM UTC+1, Christian Stump wrote: > > The title says it all: Is it still state of the art that we cannot get > canonical labels and graph isomorphisms from nauty? > > I found this post from last year > >

[sage-devel] Re: Users can permanently modify GF(5).list()

On Friday, June 3, 2016 at 11:02:53 AM UTC-7, Simon King wrote: > > > But my second suggestion was: Add an option to @cached_method, so that one > can request copy-on-return. > > -1 for bug trap. We don't know what the correct interpretation of "copy" is. Most of the time, shallow copy will be

[sage-devel] Re: Users can permanently modify GF(5).list()

On Friday, June 3, 2016 at 2:02:53 PM UTC-4, Simon King wrote: > > But my second suggestion was: Add an option to @cached_method, so that one > can request copy-on-return. > I understood what you want, but I'm saying that its bad to have a bug in the code that is then worked around by a

[sage-devel] Re: Sage 7.2 compilation from source fails on Debian 8.4

On Friday, June 3, 2016 at 3:52:32 PM UTC+1, Adetokunbo Arogbonlo wrote: > > Thanks. How could you tell? I thought with gcc came with g++ by default. > well, there are messages in your config.log regarding the absence of c++ compiler. And no, gcc suite of compilers has quite a few languages

[sage-devel] Can we still not get canonical labels and graph isomorphisms from nauty?

The title says it all: Is it still state of the art that we cannot get canonical labels and graph isomorphisms from nauty? I found this post from last year https://groups.google.com/d/topic/sage-devel/mKZ1Ar1lJG0/discussion I just checked the vertex-facet incidence graph of the 24-cell,

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

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

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

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

[sage-devel] Re: Users can permanently modify GF(5).list()

Am Freitag, 3. Juni 2016 19:19:27 UTC+2 schrieb Volker Braun: > > IMHO we shouldn't slow down cached_method just to allow you to write > incorrect code (and caching a returned list is a bug). If anything, > cached_method should print a warning if the result is mutable so people can > fix their

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

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

[sage-devel] Re: Users can permanently modify GF(5).list()

IMHO we shouldn't slow down cached_method just to allow you to write incorrect code (and caching a returned list is a bug). If anything, cached_method should print a warning if the result is mutable so people can fix their code. On Friday, June 3, 2016 at 1:10:25 PM UTC-4, Simon King

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

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

[sage-devel] Re: Users can permanently modify GF(5).list()

Hi All, I know it would considerably slow down @cached_method, but what about the following: - When a new item for the cache is first computed, test whether it is hashable. - Along with the item, store whether it is hashable or not (so that there's no need to test hashability again). - If an

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

+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)

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] Users can permanently modify GF(5).list()

On Friday, June 3, 2016, Volker Braun wrote: > On Thursday, June 2, 2016 at 5:41:59 PM UTC-4, William wrote: >> >>X.list() >> might very well return a tuple of four *mutable* 2x2 matrices. Then >> this X.tuple() is still very much mutable, and the original problem >>

Re: [sage-devel] Users can permanently modify GF(5).list()

On Thursday, June 2, 2016 at 5:41:59 PM UTC-4, William wrote: > >X.list() > might very well return a tuple of four *mutable* 2x2 matrices. Then > this X.tuple() is still very much mutable, and the original problem > has not been solved.I guess that's my point. > But that has is

[sage-devel] Re: Sage 7.2 compilation from source fails on Debian 8.4

Thanks. How could you tell? I thought with gcc came with g++ by default. On Saturday, June 4, 2016 at 12:25:50 AM UTC+10, Dima Pasechnik wrote: > > > > On Friday, June 3, 2016 at 3:14:20 PM UTC+1, Dima Pasechnik wrote: >> >> Oh, I see. You need c++ compiler (g++) installed, and you do not have

[sage-devel] Re: Sage 7.2 compilation from source fails on Debian 8.4

On Friday, June 3, 2016 at 3:14:20 PM UTC+1, Dima Pasechnik wrote: > > Oh, I see. You need c++ compiler (g++) installed, and you do not have it. > in fact http://doc.sagemath.org/html/en/installation/source.html#prerequisites says: # debian sudo apt-get install binutils gcc g++ gfortran

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

[sage-devel] Re: Sage 7.2 compilation from source fails on Debian 8.4

Oh, I see. You need c++ compiler (g++) installed, and you do not have it. The error message could be better. On Friday, June 3, 2016 at 3:09:32 PM UTC+1, Adetokunbo Arogbonlo wrote: > > Hi Dima, > Here are the commands and outputs > ~$ which cpp > /usr/bin/cpp > > ~$ file /lib/cpp > /lib/cpp:

[sage-devel] Re: Sage 7.2 compilation from source fails on Debian 8.4

Hi Dima, Here are the commands and outputs ~$ which cpp /usr/bin/cpp ~$ file /lib/cpp /lib/cpp: symbolic link to /etc/alternatives/cpp ~$ file /etc/alternatives/cpp /etc/alternatives/cpp: symbolic link to /usr/bin/cpp ~$ cpp -v Using built-in specs. COLLECT_GCC=cpp Target: x86_64-linux-gnu

[sage-devel] Re: Sage 7.2 compilation from source fails on Debian 8.4

what is the output of `which cpp`? normally, /lib/cpp (what pops up in your error message) should be a symbolic link to /etc/alternatives/cpp ` like this: $ file /lib/cpp /lib/cpp: symbolic link to `/etc/alternatives/cpp' $ file /etc/alternatives/cpp /etc/alternatives/cpp: symbolic link to

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

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

Re: [sage-devel] Users can permanently modify GF(5).list()

On 2016-06-03 10:53, John Cremona wrote: > If the method was called something else such as F.elements() +1 (and maybe deprecate .list() as it does not give you an idea what this list contains) The objects (as GF(5)) are and should be still iterable, thus one can use list(GF(5)) and

Re: [sage-devel] Users can permanently modify GF(5).list()

Surely one problem with having a list method as in F.list() is that the informal meaning of "give me a list of the elements of F so that I do stuff with it" is being confused with a technical computing term "list" which has certain properties, such as mutability. If the method was called

Re: [sage-devel] Users can permanently modify GF(5).list()

Alternative idea to sidestep the whole list/tuple discussion: implement a new type immutable_list which inherits from list. It is yet another container type, but it is less confusing (the thing really behaves like a list except that it cannot be modified). Jeroen. -- You received this

Re: [sage-devel] Users can permanently modify GF(5).list()

As others, I think that having X.list() returning a tuple will be really misleading for many users. Le 02/06/2016 22:39, Volker Braun a écrit : The ones that understand the difference between list and tuple also understand why a cached_method can't return a list. I think this is completely

Re: [sage-devel] Users can permanently modify GF(5).list()

On Thu, Jun 2, 2016 at 11:01 PM, Jori Mäntysalo wrote: > Why do we have cached results? > > Beginners do something like > > for x in small_list: > if x in SimpleThing(42).list(): > echo("Found!", x) > > Advanced users should know how to do > > temp =

Re: [sage-devel] Users can permanently modify GF(5).list()

Why do we have cached results? Beginners do something like for x in small_list: if x in SimpleThing(42).list(): echo("Found!", x) Advanced users should know how to do temp = ComplicatedThing(10^6).list() matches = [x for x in big_list if x in temp] So when is caching results