Re: [sage-devel] Re: *.math.washington.edu hardware resources

> that grant (e.g. for me, 3 person-months over 4 years which translates > into about 2 days per week) are required to keep time sheets so that What the hell. You too? It's even worse than I thought, basically everybody here has had a share of ODK's money and is thankful for it. Nathann -- You

Re: [sage-devel] Re: *.math.washington.edu hardware resources

On 17 September 2015 at 10:26, Nathann Cohen wrote: >> that grant (e.g. for me, 3 person-months over 4 years which translates >> into about 2 days per week) are required to keep time sheets so that That should read: 2 days per month (it is 1/16). > > What the hell. You

[sage-devel] Re: Coercion between finite fields

Hi! On 2015-09-17, Jeroen Demeyer wrote: > On 2015-09-16 16:43, Jean-Pierre Flori wrote: >> Hi, >> >> I guess one of the issue is that there is no canonical map between two >> different representations of the same finite field (so no coercion). > > The question is really:

Re: [sage-devel] Coercion between finite fields

Two comments: A) There is no such thing as "different finite fields of the same size with the same generator name" sage: GF(4, 'a') is GF(4, 'a') True sage: GF(4, 'a') is GF(4, 'b') False There is no way to cast finite field elements to other finite field elements apart from the prime

Re: [sage-devel] Re: Coercion between finite fields

On 17/09/15 06:53, Simon King wrote: Hi! On 2015-09-17, Jeroen Demeyer wrote: On 2015-09-16 16:43, Jean-Pierre Flori wrote: Hi, I guess one of the issue is that there is no canonical map between two different representations of the same finite field (so no

Re: [sage-devel] Re: Coercion between finite fields

Here is another discovery after 15 minutes of debugging: sage: K1 = GF(8,'x') sage: K2 = GF(8,'y') sage: K1(1) == K2(1) False Nathann On 17 September 2015 at 12:15, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > > > On 17/09/15 06:53, Simon King wrote: >> >> Hi! >> >> On 2015-09-17,

Re: [sage-devel] Re: Coercion between finite fields

Another instance of our non-transitive equality sage: K1 = GF(8,'x') sage: K2 = GF(8,'y') sage: K1.one() == 1 == K2.one() True On 17/09/15 07:19, Nathann Cohen wrote: Here is another discovery after 15 minutes of debugging: sage: K1 = GF(8,'x') sage: K2 = GF(8,'y') sage: K1(1) == K2(1) False

Re: [sage-devel] Coercion between finite fields

On Thursday, September 17, 2015 at 12:24:07 PM UTC+2, Jeroen Demeyer wrote: > > On 2015-09-17 11:56, Volker Braun wrote: > > Two comments: > > > > A) There is no such thing as "different finite fields of the same size > > with the same generator name" > > Of course there is: > > sage:

Re: [sage-devel] Coercion between finite fields

On 2015-09-17 12:32, Jean-Pierre Flori wrote: Don't we have a random keyword as well? Not a random keyword, but a modulus="random" argument (there are several more algorithms to choose a modulus) -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

Re: [sage-devel] Coercion between finite fields

On 2015-09-17 11:56, Volker Braun wrote: Two comments: A) There is no such thing as "different finite fields of the same size with the same generator name" Of course there is: sage: GF(8, 'a') is GF(8, 'a', modulus="adleman-lenstra") False -- You received this message because you are

Re: [sage-devel] Re: *.math.washington.edu hardware resources

On 16 September 2015 at 19:03, Dima Pasechnik wrote: > On 16 September 2015 at 10:36, Nathann Cohen wrote: >> Dima, >> >>> E.g. as far as I am concerned, it's thanks to ODK, which pays 50% of my >>> salary, that I can set aside time for this. >> >> You

Re: [sage-devel] Re: sage -n jupyter

On 2015-09-14 22:18, Volker Braun wrote: will be in the next beta ...if somebody reviews #19182. -- 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

Re: [sage-devel] Coercion between finite fields

On 2015-09-16 16:43, Jean-Pierre Flori wrote: Hi, I guess one of the issue is that there is no canonical map between two different representations of the same finite field (so no coercion). The question is really: is the map between representations of the same finite field, which differ only

Re: [sage-devel] Coercion between finite fields

> The question is really: is the map between representations of the same > finite field, which differ only in variable name, "canonical"? I would say that there is no big risk to do that, though I am not at all knowledgeable on those parts of the code. If it can be dangerous but can be detected,

Re: [sage-devel] Re: Coercion between finite fields

This one is also fun: sage: K = GF(8, 'a') sage: K(1) == ZZ(1) == QQ(1) True sage: K(1) == QQ(1) False -- 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

Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)

Same problem, nobody find a solution ? If yes, please can you tell me how ! Charles Le vendredi 11 septembre 2015 04:48:25 UTC+2, François a écrit : > > Hum, that symbol is in libpython2.7.dylib, operator.so is not linked to > that library. > I am guessing it is supposed to be dlopen-ed from

[sage-devel] Re: *.math.washington.edu hardware resources

I'm not an expert with configuring a cluster, but I've read good things about "Ansible". Do we have any ansible "experts" among us? I think, this tool is a good fit because it describes "goals" and it's extensible with custom modules (written in Python). My uneducated feeling is that we should

Re: [sage-devel] Info: installing packages

On 17 September 2015 at 16:16, William Stein wrote: > On Thu, Sep 17, 2015 at 7:48 AM, Jeroen Demeyer > wrote: >> Hello, >> >> the logic for installing packages in Sage has changed recently. Let me >> explain what changed: >> >> The command "sage -i

Re: [sage-devel] Info: installing packages

Hey John, > Is the non-existence of a dependencies file valid for a package with > none? I think so: I noticed that the optional package > database_cremona_ellcurve has no dependencies file (after I pulled in > the beta7 edition of the develop branch). But I also tried "sage -i >

Re: [sage-devel] Re: *.math.washington.edu hardware resources

> > > What the hell. You too? It's even worse than I thought, basically > everybody here has had a share of ODK's money and is thankful for it. > > Ahem - definitely not getting ODK money here :) nor are probably 95% (?) of Sage developers. But given that there seem to be few or no strings

[sage-devel] Info: installing packages

Hello, the logic for installing packages in Sage has changed recently. Let me explain what changed: The command "sage -i PKGNAME" now only supports new-style packages. The PKGNAME should be a bare package name (no version numbers or URLs or whatever). Packages are now installed *with*

[sage-devel] Re: Coercion between finite fields

On Thursday, September 17, 2015 at 2:54:15 AM UTC-7, Simon King wrote: > > The real problem here is that *conversion* gives rise to an error > that mentions *coercion*. > > sage: K. = GF(25) > sage: L. = GF(25) > sage: K(y) > Traceback (most recent call last): > ... > TypeError:

Re: [sage-devel] Re: Coercion between finite fields

On Thu, Sep 17, 2015 at 2:53 AM, Simon King wrote: > Hi! > > On 2015-09-17, Jeroen Demeyer wrote: >> On 2015-09-16 16:43, Jean-Pierre Flori wrote: >>> Hi, >>> >>> I guess one of the issue is that there is no canonical map between two >>> different

Re: [sage-devel] Info: installing packages

On Thu, Sep 17, 2015 at 7:48 AM, Jeroen Demeyer wrote: > Hello, > > the logic for installing packages in Sage has changed recently. Let me > explain what changed: > > The command "sage -i PKGNAME" now only supports new-style packages. The > PKGNAME should be a bare package

Re: [sage-devel] Re: Coercion between finite fields

Equals is not transitive in Sage. Addition (of floating point numbers) is not commutative either. And many, many other things that are different from our perfect abstractions when you try to model infinite objects in a finite machine. I definitely do not consider this a bug: sage: K1 =

Re: [sage-devel] Re: *.math.washington.edu hardware resources

On Thu, Sep 17, 2015 at 7:34 AM, kcrisman wrote: >> >> What the hell. You too? It's even worse than I thought, basically >> everybody here has had a share of ODK's money and is thankful for it. >> > > Ahem - definitely not getting ODK money here :) nor are probably 95% (?) of

Re: [sage-devel] Re: Coercion between finite fields

On Thu, Sep 17, 2015 at 8:00 AM, Nils Bruin wrote: > On Thursday, September 17, 2015 at 2:54:15 AM UTC-7, Simon King wrote: >> >> The real problem here is that *conversion* gives rise to an error >> that mentions *coercion*. >> >> sage: K. = GF(25) >> sage: L. = GF(25) >>

Re: [sage-devel] Info: installing packages

On 2015-09-17 17:47, John Cremona wrote: I think so: I noticed that the optional package database_cremona_ellcurve has no dependencies file (after I pulled in the beta7 edition of the develop branch). Let me first explain the two kinds of dependencies that "make" supports: there are normal

Re: [sage-devel] Re: *.math.washington.edu hardware resources

> > > > it would be useful to revive the discussion of a > > true SageMath Foundation, separate from SMCI of course, whether > incorporated > > in the US or Europe (or elsewhere), but it sounds like there wasn't > > currently enough interest in helping with the substantial paperwork >

Re: [sage-devel] Re: *.math.washington.edu hardware resources

On Thu, Sep 17, 2015 at 1:04 PM, kcrisman wrote: >> >> > it would be useful to revive the discussion of a >> > true SageMath Foundation, separate from SMCI of course, whether >> > incorporated >> > in the US or Europe (or elsewhere), but it sounds like there wasn't >> >

Re: [sage-devel] Problems with latest Xcode on OS X

Before starting a build myself I checked your logs. It looks like for ecm the problem was not new but only gave a warning before: /bin/sh ../libtool --mode=compile gcc -march=corei7 -mtune=corei7-avx -g -O3 -fPIC -c -o mulredc1.lo mulredc1.s libtool: compile: gcc -march=corei7

Re: [sage-devel] Re: *.math.washington.edu hardware resources

On 17/09/15 17:10, William Stein wrote: On Thu, Sep 17, 2015 at 1:04 PM, kcrisman wrote: it would be useful to revive the discussion of a true SageMath Foundation, separate from SMCI of course, whether incorporated in the US or Europe (or elsewhere), but it sounds like

[sage-devel] Problems with latest Xcode on OS X

I just updated my command-line tools and Xcode to version 7.0 (released today, I think). When I tried to build the latest beta of Sage from scratch, the following packages did not build: - ecm: log file http://www.math.washington.edu/~palmieri/Sage/ecm-6.4.4.log - gsl: log file

Re: [sage-devel] Re: *.math.washington.edu hardware resources

On Thu, Sep 17, 2015 at 6:05 PM, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > > > On 17/09/15 17:10, William Stein wrote: >> >> On Thu, Sep 17, 2015 at 1:04 PM, kcrisman wrote: > it would be useful to revive the discussion of a > true SageMath