[sage-devel] Weird ImportError with six

Hello, Can anybody explain (even better - fix ;-)) what is going on with this error with 7.2 and 7.3.beta0: sage: from sage.misc.remote_file import get_remote_file sage: get_remote_file('http://193.146.36.205:8080/GgbSageDirect/DiscoverGGB/DiscoverGGBAux/2015_11_24_fromGgbXMLString2Cons.sage')

[sage-devel] Re: Faulty comparison between elements of quotient of multivariate polynomial ring

On Monday, May 30, 2016 at 9:55:16 AM UTC-7, Alec Edgington wrote: > > On Monday, 30 May 2016 17:19:54 UTC+1, Nils Bruin wrote: >> >> Currently, u.__cmp__ uses the former to test equality, and it should >> probably use the latter. The reasoning is argued in the code. It looks like >> univariate

Re: [sage-devel] Re: Opinions on mostly superfluous refactoring

On Mon, May 30, 2016 at 6:50 PM, William Stein wrote: > On Mon, May 30, 2016 at 9:47 AM, Jori Mäntysalo wrote: >> On Mon, 30 May 2016, Erik Bray wrote: >> Imho many sage modules have grown too long, including but not limited to some 20kloc

[sage-devel] Re: Faulty comparison between elements of quotient of multivariate polynomial ring

On Monday, 30 May 2016 17:19:54 UTC+1, Nils Bruin wrote: > > Currently, u.__cmp__ uses the former to test equality, and it should > probably use the latter. The reasoning is argued in the code. It looks like > univariate polynomial ideals should just get a containment test implemented > Thanks,

Re: [sage-devel] Re: Opinions on mostly superfluous refactoring

On Mon, May 30, 2016 at 9:47 AM, Jori Mäntysalo wrote: > On Mon, 30 May 2016, Erik Bray wrote: > >>> Imho many sage modules have grown too long, including but not limited to >>> some 20kloc monsters. +1 to splitting things up! >> >> >> Yikes! I'm not sure I've even run

Re: [sage-devel] Re: Opinions on mostly superfluous refactoring

On Mon, 30 May 2016, Erik Bray wrote: Imho many sage modules have grown too long, including but not limited to some 20kloc monsters. +1 to splitting things up! Yikes! I'm not sure I've even run into any of those yet. 20kloc is definitely worth splitting up. ~4k is a lot more arguable I

Re: [sage-devel] Opinions on mostly superfluous refactoring

On Mon, May 30, 2016 at 6:42 PM, William Stein wrote: > On Mon, May 30, 2016 at 9:22 AM, Erik Bray wrote: >> Hi all, >> >> I recently needed to dive into the sage_setup.autogen.interpreters >> module in order to make some small changes. > > Quick link: >

Re: [sage-devel] Opinions on mostly superfluous refactoring

On Mon, May 30, 2016 at 9:22 AM, Erik Bray wrote: > Hi all, > > I recently needed to dive into the sage_setup.autogen.interpreters > module in order to make some small changes. Quick link:

[sage-devel] Re: Faulty comparison between elements of quotient of multivariate polynomial ring

On Monday, May 30, 2016 at 5:19:54 PM UTC+1, Nils Bruin wrote: > > On Monday, May 30, 2016 at 8:56:19 AM UTC-7, Alec Edgington wrote: >> >> >> >> It seems that there is a problem with the internal representations and in >> some cases equality is not being ascertained correctly. >> >> The problem

Re: [sage-devel] Re: Opinions on mostly superfluous refactoring

On Mon, May 30, 2016 at 6:29 PM, Volker Braun wrote: > Imho many sage modules have grown too long, including but not limited to > some 20kloc monsters. +1 to splitting things up! Yikes! I'm not sure I've even run into any of those yet. 20kloc is definitely worth

[sage-devel] Re: Opinions on mostly superfluous refactoring

Imho many sage modules have grown too long, including but not limited to some 20kloc monsters. +1 to splitting things up! On Monday, May 30, 2016 at 6:22:53 PM UTC+2, Erik Bray wrote: > > Hi all, > > I recently needed to dive into the sage_setup.autogen.interpreters > module in order to make

[sage-devel] Opinions on mostly superfluous refactoring

Hi all, I recently needed to dive into the sage_setup.autogen.interpreters module in order to make some small changes. The file is over 4000 lines long, which is a bit on the long side for your typical Python file, though not egregious by any means. That said, when trying to understand some

[sage-devel] Re: Faulty comparison between elements of quotient of multivariate polynomial ring

On Monday, May 30, 2016 at 8:56:19 AM UTC-7, Alec Edgington wrote: > > > > It seems that there is a problem with the internal representations and in > some cases equality is not being ascertained correctly. > > The problem seems to be this: sage: u=c*(d+e) sage: v=c*d+c*e sage:

[sage-devel] 3 graphics

Hello! I use the sage for virtualbox on windows when plot 3d graphics and I right-click other options except the console and java script does not work. How to fix this? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

[sage-devel] 3d graphics

Hello! I use the sage for virtualbox on windows when plot 3d graphics and I right-click other options except the console and java script does not work. How to fix this? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

[sage-devel] Faulty comparison between elements of quotient of multivariate polynomial ring

Hello, I've found an problem with comparison of elements in certain rings. Here is a piece of Sage to illustrate the issue: sage: R = PolynomialRing(GF(4), ('x', 'y')) sage: x, y = R.gens() sage: I = R.ideal([x^2 + y^2, x + y^3]) sage: S = R.quotient(I, 'ab') sage: a, b = S.gens() sage: c, d, e

Re: [sage-devel] Renaming generic curve classes

On Monday, May 30, 2016 at 6:02:27 AM UTC-7, Volker Braun wrote: > > > They are different implementations and not injected in the global > namespace. The global namespace only has factory functions that instantiate > these classes. As such they are implementation details and subject to > change

Re: [sage-devel] Re: weird output: show of FiniteField

Ah forgot about the existing ticket... On Monday, May 30, 2016 at 3:57:42 PM UTC+2, Daniel Krenn wrote: > > Why was > On 2016-05-30 15:51, Volker Braun wrote: > > This is now http://trac.sagemath.org/ticket/20711 > > created and code not attached to the existing > > > On Sunday, May 22, 2016

Re: [sage-devel] Re: weird output: show of FiniteField

Why was On 2016-05-30 15:51, Volker Braun wrote: > This is now http://trac.sagemath.org/ticket/20711 created and code not attached to the existing > On Sunday, May 22, 2016 at 11:47:50 AM UTC+2, Daniel Krenn wrote: > This is ticket http://trac.sagemath.org/ticket/20652 >

[sage-devel] Re: weird output: show of FiniteField

This is now http://trac.sagemath.org/ticket/20711 On Sunday, May 22, 2016 at 11:47:50 AM UTC+2, Daniel Krenn wrote: > > We have > > sage: show(FiniteField(2)) > \newcommand{\Bold}[1]{\mathbf{#1}}0 1 > > which is the list of elements and not $F_2$ (what I would expect). > > However, the

Re: [sage-devel] Renaming generic curve classes

On Monday, May 30, 2016 at 8:46:37 AM UTC+2, Johan S. R. Nielsen wrote: > > I'm a bit surprised at the naming scheme "_generic", etc. in the first > place. They are different implementations and not injected in the global namespace. The global namespace only has factory functions that

Re: [sage-devel] Re: Copyrights

On Fri, May 27, 2016 at 7:30 PM, rjf wrote: > The point is, if you don't claim authorship, someone else might, and (for > example) > restrict access, even by you. > > So you should claim authorship and copyright, and then declare that others > may > use it under whatever

[sage-devel] Renaming generic curve classes

Hi Grayson, I'm really looking forward to your GSoC on curves! > Currently, the plane curve classes do not inherit from the space curve > ... > It seems that it would be a lot clearer to have a different naming > scheme, such as having ProjectiveCurve_generic be called > ProjectiveCurve_plane,