[sage-support] A nice (minor ?) bug ?

Seen in 10.3.beta3 : sage: show_identifiers() :1: DeprecationWarning: Importing Euler_Phi from here is deprecated; please use "from sage.arith.misc import Euler_Phi" instead. See https://github.com/sagemath/sage/issues/30322 for details. show_identifiers()

[sage-support] Re: Possible serious bug : latexing an expression containing a held integral triggers its evaluation...

This is now Trac#30326 (with priority major, but not critical, notwithstanding the potential for session/notebook crash or stalling). HTH, ​ Le dimanche 9 août 2020 16:00:11 UTC+2, Emmanuel Charpentier a écrit : > > *Note : for once, this is a

[sage-support] Re: Possible serious bug : latexing an expression containing a held integral triggers its evaluation...

One more data point: calling latex (or show or view) on such an expression containing a held integral *in a hold context* gives a RecursionError. HTH, ​ Le dimanche 9 août 2020 17:38:10 UTC+2, Emmanuel Charpentier a écrit : > > On Cocalc >

[sage-support] Re: Possible serious bug : latexing an expression containing a held integral triggers its evaluation...

On Cocalc , I have checked that the problem can be reproduced on all available Sage kernels back to 8.2. Looks more like an error from me, rather than a bug… Suggestions most welcome ! ​ Le dimanche 9

[sage-support] Re: Possible serious bug : latexing an expression containing a held integral triggers its evaluation...

The problem can be reproduced on [sagecell]( https://sagecell.sagemath.org/?z=eJxVi0EKhDAMAO99SSKu4t5zEg-5-wFxQy2ILU1W8nx72cPCwMDAcKQ9KzgGNuI4pMsk1s0EvH-V1DeOfH5orV_BMCtNI7y7kjAsTrN2bKHUNsHZHgc2xL-weAu6RRluqZry9fMDXHAoTw===sage=eJyLjgUAARUAuQ==), which is currently at 9.1. HTH, Le dimanche 9

[sage-support] Re: A genuine bug in numerical evaluation ?

Oh, and Sage with Python 3 is in pretty good shape these days. Still some doctest failures, but I think it is mostly very functional. John On Thursday, June 6, 2019 at 3:20:25 PM UTC-7, John H Palmieri wrote: > > I can confirm that it works for me on OS X with Python 3, gives the error >

[sage-support] Re: A genuine bug in numerical evaluation ?

I can confirm that it works for me on OS X with Python 3, gives the error you described with Python 2. On Thursday, June 6, 2019 at 2:57:08 PM UTC-7, Emmanuel Charpentier wrote: > > According to Serge Lelièvre, the proble doesn't occur when ran under a > Python3-based Sage. He advises to run

[sage-support] Re: A genuine bug in numerical evaluation ?

According to Serge Lelièvre, the proble doesn't occur when ran under a Python3-based Sage. He advises to run such a Sage, hich seems a bit early, IMHO? Advice ? Le jeudi 6 juin 2019 11:04:27 UTC+2, Emmanuel Charpentier a écrit : > > This ask.sagemath question >

Re: [sage-support] Is this a bug?

nothing prevents Sagecell from predefining x, or even using Wfram alpha as the backend :-) -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [sage-support] Is this a bug?

> Users mistake FAR too often symbolics with polynomials Well, of course, and I'm sure rjf would say that Sage developers far too often mistake expressions for functions. But what percentage of users actually know the difference in any case? (Rhetorical.) -- You received this message because

Re: [sage-support] Is this a bug?

> I am mildly in favor of dropping this predefinition (FWIW). > > > Far be it for me to acquire the usual "hobgoblin of little minds" trope, but in this case consistency is probably good. This argument was had ~10 years ago in great detail, with several hilarious variants implemented one

Re: [sage-support] Is this a bug?

> On Feb 28, 2018, at 00:09, Dima Pasechnik wrote: > > I would be for dropping 'x' as the only "default" variable (defined at start > time). > Sage is unique in this sense AFAIK; there are CASes which don't require > declaration of any variable, > there are ones that don't

Re: [sage-support] Is this a bug?

On Mon, Feb 26, 2018 at 8:52 PM, Juan Luis Varona wrote: > In sagemath 7.5, we can use this code: > > t=var('t'); > M=matrix(4,[[0,0,5/4,2],[t,0,0,0],[0,1,0,0],[0,0,1,0]]); > P=charpoly(M); > P.substitute(x=1) > > Then, we get the correct answer >

[sage-support] Is this a bug?

In sagemath 7.5, we can use this code: t=var('t'); M=matrix(4,[[0,0,5/4,2],[t,0,0,0],[0,1,0,0],[0,0,1,0]]); P=charpoly(M); P.substitute(x=1) Then, we get the correct answer -13/4*t + 1 However, the same code gives an error with sagemath 8.2. A workaround that again gives

[sage-support] Re: Possible new bug of solve()

This is now Trac#23992 . HTH, -- Emmanuel Charpentier Le dimanche 8 octobre 2017 20:53:55 UTC+2, Emmanuel Charpentier a écrit : > > I'd vote for a bug : since Maxima, used standalone, *can* solve this > system, not being able to use it correctly

[sage-support] Re: Possible new bug of solve()

Yet another datapoint : our interface to mathematica *can* be used to get a solution. The problem I got was that the result can't be translated back to Sage : Mathematica express its results as "rules" (e.g "var -> expression" means "expression is a solution for var"). Manually translating

[sage-support] Re: Possible new bug of solve()

I'd vote for a bug : since Maxima, used standalone, *can* solve this system, not being able to use it correctly *is* a bug. Somewhere in our interface... Le dimanche 8 octobre 2017 14:26:00 UTC+2, Maarten Derickx a écrit : > > It deserves a ticket, the main question is more whether the ticket

[sage-support] Re: Possible new bug of solve()

It deserves a ticket, the main question is more whether the ticket should be a bug or an enhancement. But that is something that can still be changed later. -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and

[sage-support] Re: Possible new bug of solve()

Another datapoint : Sympy seems to be able to (slowly) solve this system, via : from sympy.solvers import solve as ssolve ssol=ssolve([e.rhs()-e.lhs() for e in [eq1,eq2,eq3]],[x,y,z]) The output can be converted to Sage via: Ssol=map(lambda S:map(lambda v,s:v==SR(repr(s)).simplify_full(),

[sage-support] Re: [forwarded from bug tracker]

Apologies, that was supposed to go to lmfdb-support. Ignore! John On 16 August 2017 at 08:48, John Cremona wrote: > This is a very minor comment about the description/definition of "GL_2 > type" in the genus 2 curve page (after clicking the "GL_2 type" link). > The last

[sage-support] Is this a bug in the FreeAlgebra Class?

Hi, I create a free algebra like such: R. = FreeAlgebra(Integers(2)) When I try to check if the constant polynomial 1 is in R, it returns false. But this should return true. i.e. 1 in R returns false It also returns false when I write the code 0 in R Is this a bug? -- You received

[sage-support] Re: integrate problem (bug?)

This is fixed in Sage 7.6.beta2: ┌┐ │ SageMath version 7.6.beta2, Release Date: 2017-02-01 │ │ Type "notebook()" for the browser-based notebook interface.│ │ Type "help()" for help.

[sage-support] division by zero bug in EllipticCurve rank()

A report from Lee Morgenstern using SageMathCell running Sage 6.9.beta6, but the same happens in 6.10: the following code produces NTLError: RR: division by zero m = 239; n = 48 X = 2*m*n; Y = m^2 - n^2; Z = m^2 + n^2 E = EllipticCurve([0, 2*(Z^2-X*Y), 0, (X*Y)^2, 0]) E.rank() The same error

Re: [sage-support] division by zero bug in EllipticCurve rank()

On Sun, Dec 27, 2015 at 12:05 PM, Andrey Novoseltsev wrote: > A report from Lee Morgenstern using SageMathCell running Sage 6.9.beta6, but > the same happens in 6.10: > > the following code produces > NTLError: RR: division by zero This curve has a very large conductor and

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Tuesday, 24 November 2015 11:12:13 UTC, Sergey Kirpichev wrote: > > On Monday, November 23, 2015 at 10:38:39 PM UTC+3, Ondrej Certik wrote: >> >> Note that William's result has one more zero in the answer... Which >> one is correct? >> > > Maxima's, of course. btw, sympy's answer is same:

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Monday, November 23, 2015 at 10:38:39 PM UTC+3, Ondrej Certik wrote: > > Note that William's result has one more zero in the answer... Which > one is correct? > Maxima's, of course. btw, sympy's answer is same: In [3]: limit(S(2)/5*((S(3)/4)**m - 1)*(a0 - 100) + S(1)/5*(3*(S(3)/4)**m

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Monday, November 23, 2015 at 3:43:02 AM UTC+3, William wrote: > > This definitely looks like a bug. In the meantime, a workaround is to > use sympy: > This is not a maxima bug: Maxima 5.34.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.12 (a.k.a. GCL)

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Tuesday, 24 November 2015 11:12:13 UTC, Sergey Kirpichev wrote: > > > On Monday, November 23, 2015 at 3:43:02 AM UTC+3, William wrote: >> >> This definitely looks like a bug. In the meantime, a workaround is to >> use sympy: >> > > > This is not a maxima bug: > > Maxima 5.34.1

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Tue, Nov 24, 2015 at 04:12:52AM -0800, Dima Pasechnik wrote: >If you first set domain to complex (and this is the setting Sage uses to >call maxima), you get the same error as from Sage. I have seen this post. My messages arrive too late due to moderation, so they a little dated.

Re: [sympy] Re: [sage-support] Fwd: [sage-release] Bug in limit?

(note, I am not on the sage list or gms list, so this probably won't make it there unless someone forwards it) SymPy's limit primarily uses the Gruntz algorithm, which is fairly capable. I'm not an expert on it, so others will be able to comment in more detail, but as far as I know, it's mostly

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Monday, 23 November 2015 00:43:02 UTC, William wrote: > > This definitely looks like a bug. In the meantime, a workaround is to > use sympy: > > sage: var('m a0') > (m, a0) > sage: x=2/5*((3/4)^m - 1)*(a0 - 100) + 1/5*(3*(3/4)^m + 2)*a0;x > 2/5*((3/4)^m - 1)*(a0 - 100) +

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Mon, Nov 23, 2015 at 12:20 PM, Dima Pasechnik wrote: > > > On Monday, 23 November 2015 00:43:02 UTC, William wrote: >> >> This definitely looks like a bug. In the meantime, a workaround is to >> use sympy: >> >> sage: var('m a0') >> (m, a0) >> sage: x=2/5*((3/4)^m - 1)*(a0

Re: [sage-support] Fwd: [sage-release] Bug in limit?

> > > I wonder -- to what extent should we be using maxima by default still > for limits, instead of sympy...? At some point, presumably sympy will > be uniformly better than maxima? > > > I've been wondering about this as well (also integrals) for some time. Unfortunately I haven't had

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Monday, 23 November 2015 19:38:39 UTC, Ondrej Certik wrote: > > On Mon, Nov 23, 2015 at 12:20 PM, Dima Pasechnik > wrote: > > > > > > On Monday, 23 November 2015 00:43:02 UTC, William wrote: > >> > >> This definitely looks like a bug. In the meantime, a workaround

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Mon, Nov 23, 2015 at 12:17 PM, Dima Pasechnik wrote: > > > On Monday, 23 November 2015 19:38:39 UTC, Ondrej Certik wrote: >> >> On Mon, Nov 23, 2015 at 12:20 PM, Dima Pasechnik wrote: >> > >> > >> > On Monday, 23 November 2015 00:43:02 UTC, William wrote:

Re: [sage-support] Fwd: [sage-release] Bug in limit?

On Monday, November 23, 2015 at 11:20:23 AM UTC-8, Dima Pasechnik wrote: > > the bug is not really in maxima, it's in Sage's interface to maxima: > > (%i7) limit(2/5*((3/4)^m - 1)*(a0 - 100) + 1/5*(3*(3/4)^m + > 2)*a0,m,inf); > (%o7) 40 > > The stack overflow

Re: [sage-support] Fwd: [sage-release] Bug in limit?

This definitely looks like a bug. In the meantime, a workaround is to use sympy: sage: var('m a0') (m, a0) sage: x=2/5*((3/4)^m - 1)*(a0 - 100) + 1/5*(3*(3/4)^m + 2)*a0;x 2/5*((3/4)^m - 1)*(a0 - 100) + 1/5*(3*(3/4)^m + 2)*a0 sage: limit(x, m=oo) [BAD] sage: limit(x, m=oo,

[sage-support] Fwd: [sage-release] Bug in limit?

Forwarded to the correct list -- Forwarded message -- From: G. M.-S. Date: Sun, Nov 22, 2015 at 4:34 PM Subject: [sage-release] Bug in limit? To: sage-rele...@googlegroups.com Hello. This is my first post, please be indulgent. Is the following a bug?

[sage-support] Re: [GAP Support] Bug in MinimumWeight ?

Simon: Thank you for your report. Joe Fields is the maintainer and probably has better recommendations than I can offer. My only comment is that the MinimumWeight function outputs the result of a C program written by someone who is no longer in academia. - David On Tue, Oct 20, 2015 at 3:54 PM,

Re: [sage-support] Re: [GAP Support] Bug in MinimumWeight ?

Hola, Using the very naive algorithms I wrote for the ticket #19345 [1] (in needs review) I got sage: F = VectorSpace(GF(2), 59) sage: gens = ... # the explicit generators below sage: gens = map(F, GG) sage: Vector_modn_dense_IteratorLex(F, gens).minimum_distance() 10 So at least I confirm

[sage-support] Is this a bug in Polyhedron class (RDF vs AA)?

Hi everyone, Is the following behavior normal: sage: P = polytopes.regular_polygon(5) sage: a_vertex = P.vertices()[0] sage: for facet in P.Hrepresentation(): print facet.contains(a_vertex), facet.interior_contains(a_vertex) True False True True True False True True True True sage: P =

[sage-support] Simplex not simplicial / bug in polyhedra code?

Hi, I've stumbled upon the following polyhedron on which sage gives contradictory answers. This is sage-6.8. Is this a bug? sage: Pw A 7-dimensional polyhedron in QQ^16 defined as the convex hull of 8 vertices sage: Pw.vertices() (A vertex at (1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0),

[sage-support] Re: a sage bug

On Sunday, July 12, 2015 at 2:34:56 PM UTC+2, Stein William wrote: -- Forwarded message -- From: ruiming zhang ruimin...@outlook.com Date: Sunday, July 12, 2015 Subject: a sage bug To: wst...@math.washington.edu ... e=x+1=x-2 e*(-1) -x-1=-x+2, This is known and has a

[sage-support] Fwd: a sage bug

-- Forwarded message -- From: *ruiming zhang* ruimingzha...@outlook.com Date: Sunday, July 12, 2015 Subject: a sage bug To: wst...@math.washington.edu Dear Professor Stein, If you try in sage 6.7 e=x+1=x-2 e*(-1) you get -x-1=-x+2, which is bad. Please forgive me to send it

[sage-support] Possible Sqrt Simplification Bug

Hello, I believe I found a bug in how radicals are simplified. The general idea is that sqrt(x^2)=abs(x), but sage simplifies sqrt(x^2) to x instead, even if x is negative. I've included a simple example below. sage: x = var('x') sage: assume(x0) sage: expr = sqrt(x^2) sage:

[sage-support] apparent numerical integration bug in sage

I have run the code var('x') f1(x)=1/sqrt(x^3+2) f2(x)=1/sqrt(x^4+2) r1=RR(integrate(f1(x),(x,1,10^(10 r2=RR(integrate(f2(x),(x,1,10^(10 s1=RR(integrate(f1(x),(x,1,10^(11 s2=RR(integrate(f2(x),(x,1,10^(11 integrals_for_comparison=[[r1,r2],[s1,s2]] integrals_for_comparison on Sage

[sage-support] Re: SR + QQbar bug?

Hi Guys was just wondering whether the algebraic coercion QQbar -- SR had been implemented in any form yet? I certainly cannot trick it into happening! ... eg I have a matrix in SR and I need its (diagonalization and) normalized eigenmatrix - that doesn't seem to work in SR (not that I

[sage-support] Re: There is bug with init.sage (and how to resolve it)

Hello! Sage 5.12 doesn't see init.sage file in $DOT_SAGE I found this bug in such way: import os os.environ['SAGE_STARTUP_FILE'] /home/andrei/.sage//init.sage The problem is in file $SAGE_ROOT/spkg/bin/sage-env There is line SAGE_STATUP_FILE = $DOT_SAGE/init.sage in this file I

[sage-support] Re: There is bug with init.sage (and how to resolve it)

On Saturday, October 19, 2013 11:46:17 AM UTC-7, Андрей Ширшов wrote: Hello! Sage 5.12 doesn't see init.sage file in $DOT_SAGE I don't see this behavior: Sage 5.12 sees my init.sage file perfectly, at least from the command line. I found this bug in such way: import os

[sage-support] is this a bug?

K.p,d,e,g,m,f,h,l,r,N = FractionField(PolynomialRing(QQ,10,'pdegmfhlrN')) R.s = K[] x = s + h/(4*l) G = e*l*x^4 - e*h*x^3 + (-3*e*l-e*r+N)*x^2 + 2*e*h*s + 2*e*l + 2*e*r-N print G The response looks fishy: e*l*s^4 + ((-30423614405477505635920876929024*e*h^2 -

Re: [sage-support] is this a bug?

Really? sage: x^4 s^4 + 4294967296*h/(4294967296*l)*s^3 + 29710560942849126597578981376*h^2/(79228162514264337593543950336*l^2)*s^2 + 17592186044416*h^3/(281474976710656*l^3)*s + h^4/(256*l^4) sage: 79228162514264337593543950336.factor() 2^96 so I think you just have some large powers of 2 in

[sage-support] Taylor Polynomial possible bug in return

Hiya, Probably I am just doing something wrong ... I have a cubic polynomial p(x) with regular coefficients and I wanted coefficients around e.g. (x-1). So I did p1=p.taylor(x,1,3). I get: x |-- 0.085*(x - 1)^3 - 0.255*(x - 1)^2 + 0.34*x + 1.23 The polynomial is correct, but look at the last

Re: [sage-support] Taylor Polynomial possible bug in return

On Thu, 10 Jan 2013 03:09:05 -0800 (PST) LFS lfahlb...@gmail.com wrote: Hiya, Probably I am just doing something wrong ... I have a cubic polynomial p(x) with regular coefficients and I wanted coefficients around e.g. (x-1). So I did p1=p.taylor(x,1,3). I get: x |-- 0.085*(x - 1)^3 -

Re: [sage-support] Taylor Polynomial possible bug in return

Hiya Burcin, Thanks for reply! For my cubic polynomials p0 and p1, I did get the following to work: p0=p.series(x==xD[0],4) p1=q.series(x==xD[1],4) print p0; p1 x |-- 1.0601 + 0.59497*x + (-0.08502)*x^3 x |-- 1.5698 + 0.34008*(x - 1)

Re: [sage-support] randint - Maybe one bug !

What I think very confusing is that 1/4 is the Sage division and not the Python standard one, so why it would be different for randint ? I'm a teacher and the problem is not from my point of view but it will be a tricky thing to explain to my students which are in french lycée (sorry, I don't

Re: [sage-support] randint - Maybe one bug !

On Wed, Sep 19, 2012 at 12:42 PM, Christophe BAL projet...@gmail.com wrote: What I think very confusing is that 1/4 is the Sage division and not the Python standard one, so why it would be different for randint ? It's not Sage division vs. Python division, it's Sage Integers vs. Python ints.

Re: [sage-support] randint - Maybe one bug !

I agree that this is a surprising and unfortunate wart in the was Sage is built. I would explain it like this: Python has an integer type int that has several surprising behaviors (from a mathematicians perspective, e.g. division). For this reason we created our own time, Integer, that behaves

Re: [sage-support] sage 5.0.rc0 bug! (in symbolic_sum)

On 2012-05-09 22:35, Kjetil brinchmann Halvorsen wrote: sage: k = var('k') sage: (1/k**4).sum(k,1,00) 0 sage: sum(1/k**4,k,1,00) Kjetil Are you confusing 00 with oo for infinity: sage: var('k') k sage: sum(1/k**4,k,1,oo) 1/90*pi^4 sage: sum(1/k**4,k,1,Infinity) 1/90*pi^4 -- To

Re: [sage-support] sage 5.0.rc0 bug! (in symbolic_sum)

On Wed, May 9, 2012 at 4:38 PM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2012-05-09 22:35, Kjetil brinchmann Halvorsen wrote: sage: k = var('k') sage: (1/k**4).sum(k,1,00) 0 sage: sum(1/k**4,k,1,00) Kjetil Are you confusing 00 with oo for infinity: Wow, I'm definitely going to

Re: [sage-support] sage 5.0.rc0 bug! (in symbolic_sum)

On Wed, May 9, 2012 at 4:38 PM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2012-05-09 22:35, Kjetil brinchmann Halvorsen wrote: sage: k = var('k') sage: (1/k**4).sum(k,1,00) 0 sage: sum(1/k**4,k,1,00) Kjetil Are you confusing 00 with oo for infinity: sage: var('k') k sage:

[sage-support] An AA field bug

The following code fails for me (on Ubuntu 10.10, 32 bit, Sage 4.8 compiled from source): m=sqrt(sin(pi/5)) AA(m).minpoly() I also fails on http://sagemath.org/eval.html /Håkan -- | Sage Version 4.8, Release Date: 2012-01-20

Re: [sage-support] An AA field bug

On Thu, Mar 22, 2012 at 7:55 AM, Håkan Granath hakan.gran...@gmail.com wrote: The following code fails for me (on Ubuntu 10.10, 32 bit, Sage 4.8 compiled from source): m=sqrt(sin(pi/5)) AA(m).minpoly() I also fails on http://sagemath.org/eval.html /Håkan

Re: [sage-support] An AA field bug

On Thu, Mar 22, 2012 at 8:14 AM, William Stein wst...@gmail.com wrote: On Thu, Mar 22, 2012 at 7:55 AM, Håkan Granath hakan.gran...@gmail.com wrote: The following code fails for me (on Ubuntu 10.10, 32 bit, Sage 4.8 compiled from source): m=sqrt(sin(pi/5)) AA(m).minpoly() I also fails on

Re: [sage-support] An AA field bug

On Thursday, 22 March 2012 12:23:50 UTC, William wrote: http://trac.sagemath.org/sage_trac/ticket/12727 There is now a patch up, waiting for somebody to review it! William Done. -- David -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this

Re: [sage-support] An AA field bug

On Thu, Mar 22, 2012 at 9:55 AM, David Loeffler dave.loeff...@gmail.com wrote: On Thursday, 22 March 2012 12:23:50 UTC, William wrote: There is now a patch up, waiting for somebody to review it! William Done. -- David Thanks! And let me take the time to advertise your work doctesting

[sage-support] Re: Number fields bug?

In gmane.comp.mathematics.sage.support, you wrote: On Feb 12, 2:40 am, Keshav Kini keshav.k...@gmail.com wrote: I guess his question is why Sage picks a (generic) as a generator name for QQ[2^(1/3)] but sqrt2 (hard-coded) for QQ[2^(1/2)]. -Keshav Thanks for the comments, but let me

Re: [sage-support] Re: Number fields bug?

I guess his question is why Sage picks a (generic) as a generator name for QQ[2^(1/3)] but sqrt2 (hard-coded) for QQ[2^(1/2)]. -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send

[sage-support] Re: Number fields bug?

On Feb 12, 2:40 am, Keshav Kini keshav.k...@gmail.com wrote: I guess his question is why Sage picks a (generic) as a generator name for QQ[2^(1/3)] but sqrt2 (hard-coded) for QQ[2^(1/2)]. -Keshav Thanks for the comments, but let me explain the question a bit more carefully. As the code

Re: [sage-support] Re: Number fields bug?

On 2012-02-01 06:28, Mike OS wrote: Why does sage handle the two examples: 2^(1/3) and 2^(1/2) differently? It doesn't treat them differently. Sage picks a as generator name which just happens to be the same letter you used. -- To post to this group, send email to

[sage-support] Sage Days 36--Bug days near Boston after Joint Meetings in January

We are pleased to announce Sage Days 36: http://wiki.sagemath.org/days36 to be held immediately after the Joint Mathematics Meetings, at Gordon College in Wenham, Mass. This will be, like Sage Days 19 and 27, a post-Joint Math Meetings Bug Days event. We expect the primary emphasis to be

[sage-support] Tracking down a bug(?) in Cython

I've written a bunch of functions (some organized in classes) to do some large computations in a particular finite field (always GF(2^n) for some odd n). This seems to work fine. I'd like the computation to be as fast as possible, so the first thing I did was to copy the .py file to a .pyx file.

Re: [sage-support] Tracking down a bug(?) in Cython

On Tue, Aug 2, 2011 at 11:09 AM, VictorMiller victorsmil...@gmail.com wrote: I've written a bunch of functions (some organized in classes) to do some large computations in a particular finite field (always GF(2^n) for some odd n).  This seems to work fine.  I'd like the computation to be as

Re: [sage-support] Tracking down a bug(?) in Cython

On Tue, Aug 2, 2011 at 11:29 AM, William Stein wst...@gmail.com wrote: On Tue, Aug 2, 2011 at 11:09 AM, VictorMiller victorsmil...@gmail.com wrote: I've written a bunch of functions (some organized in classes) to do some large computations in a particular finite field (always GF(2^n) for some

Re: [sage-support] abs(pi*i) Bug

Le 07/02/2011 13:05, Clemens Heuberger a écrit : I encountered the following bug: sage: abs(pi*I) I*pi I do not know how we define absolute value in Sage. Even in math in general, I'm not sure of what means the absolute value of a complex number. Depends on the data of a convex cone ? I

Re: [sage-support] abs(pi*i) Bug

On Mon, Feb 7, 2011 at 1:27 PM, Laurent moky.m...@gmail.com wrote: Le 07/02/2011 13:05, Clemens Heuberger a écrit : I encountered the following bug: sage: abs(pi*I) I*pi I do not know how we define absolute value in Sage. Even in math in general, I'm not sure of what means the absolute

[sage-support] Re: implicit_plot3d (potential bug?)

I'm not sure why nothing appears and no warning or error is raised. It may have to do with the type of v[1]. Try this: {{{ M = matrix(3,[1,-1,-1,-1,3,1,-1,1,3]); v=M.eigenvalues(); x,y,z = var('x,y,z') Q=implicit_plot3d(x^2+y^2+z^2==RDF(1/v[1]), [x,-3,3], [y,-3,3], [z,-3,3], opacity=0.5); Q }}}

[sage-support] Re: implicit_plot3d (potential bug?)

Yes, 1/v[1] is an AlgebraicNumber. I think this is a conversion failure in the ImplicitSurface class, for which I will file a ticket. For the moment your workaround seems like the best option. -Marshall Hampton On Jan 11, 3:47 pm, BFJ benjaminfjo...@gmail.com wrote: I'm not sure why nothing

[sage-support] Is this a bug?

Hi everyone In Sage 4.5.2 and Sage 4.5.3, I get the following error using partial_fraction_decomposition() sage: R.x = GF(3)[] sage: q = (x+1)/(x^3+x+1) sage: q.partial_fraction_decomposition() --- AttributeError

[sage-support] Re: Weird matrix bug

On Jul 23, 9:36 pm, Jason Grout jason-s...@creativetrax.com wrote: On 7/23/10 11:35 AM, VictorMiller wrote: There's abugin assigning 1 x 1 submatrices.  assigning any submatrices with dimensions bigger than 1 seems to work as expected: sage: A =matrix(GF(2),100,100) sage: C1

[sage-support] Re: Weird matrix bug

On 7/23/10 11:35 AM, VictorMiller wrote: There's a bug in assigning 1 x 1 submatrices. assigning any submatrices with dimensions bigger than 1 seems to work as expected: sage: A = matrix(GF(2),100,100) sage: C1 = matrix(GF(2),[[1]]) sage: C2 = matrix(GF(2),[[0,1],[1,0]]) sage: A[88:90,88:90]

[sage-support] Re: power series bug?

On May 18, 2:26 pm, Matt Bainbridge bainbridge.m...@gmail.com wrote: Is this a bug? sage: P.t = QQ[[]] sage: p = 1+O(t) sage: p(t) 1 sage: p(t^2) 1 My understanding is that p(q) is p composed with q, so the above output should be 1 + O(t) and 1 + O(t^2) respectively. I think it is a

Re: [sage-support] Re: power series bug?

On Tue, 18 May 2010 12:21:57 -0700 (PDT), John Cremona john.crem...@gmail.com wrote: I think it is a bug. sage: p.prec() 1 sage: p(t).prec() +Infinity sage: p(t^2).prec() +Infinity The precision of the composite is not being computed correctly. I hope someone more familiar with the

[sage-support] Re: sage-mode bug?

On Apr 14, 3:17 am, Dan Drake dr...@kaist.edu wrote: Hello sage-support (but mostly Nick Alexander), I'm starting to use Sage mode, and overall it seems quite nice but today it locked up my emacs session. I was using a run-sage (...) so, when point was at the u in exhau, I hit tab -- and

[sage-support] Re: SR + QQbar bug?

My vote, which is from a user's and not a developer's perspective, is to somehow coerce QQbar and AA into SR to preserve exact values and manipulate symbolic expressions such as QQbar(sqrt(2))*x. That sure would be helpful for my work. Is that problematic? Alex On Apr 8, 11:44 pm, Burcin

[sage-support] Re: SR + QQbar bug?

P.S. Burcin, thanks for all your work on Sage symbolics. I appreciate it. On Apr 8, 11:44 pm, Burcin Erocal bur...@erocal.org wrote: Hi again Alex, Many thanks for the report. On Wed, 7 Apr 2010 16:05:09 -0700 (PDT) Alex Raichev tortoise.s...@gmail.com wrote: Hi all: I ran into an

[sage-support] Re: SR + QQbar bug?

P.P.S. And thanks to everybody developing Sage :-) On Apr 9, 2:55 pm, Alex Raichev tortoise.s...@gmail.com wrote: P.S.  Burcin, thanks for all your work on Sage symbolics.  I appreciate it. On Apr 8, 11:44 pm, Burcin Erocal bur...@erocal.org wrote: Hi again Alex, Many thanks for the

[sage-support] Re: Fwd: sage bug report

perhaps problems expanding polynomials? even determinant of submatrix (0,0,5,5) is suprisingly slow. workaroud is to replace polynomials in your matrix by variables. var('x0 x1 x2 x3 x4 x5 x6 x7 a1 a2 a3 a4 a5 a6 a7 b1 b2 b3 b4 b5 b6 b7') m=matrix([[ 0, a1, a2, a3, a4, a5, a6, a7], [b1,

[sage-support] Re: Fwd: sage bug report

And another observation: maxima returns answer immediatelly (with a lag necessary to start maxima) m is the original matrix from x.py sage: m._maxima_().determinant().expand().sage() x0^2*x2^2*x3^2*x7^2 - 2*x0*x1*x2*x3*x4*x5*x6*x7 + x1^2*x4^2*x5^2*x6^2 Anyway, the answer is different from

[sage-support] Re: Fwd: sage bug report

On 17 dic, 11:48, ma...@mendelu.cz ma...@mendelu.cz wrote: And another observation: maxima returns answer immediatelly (with a lag necessary to start maxima) m is the original matrix from x.py sage: m._maxima_().determinant().expand().sage() x0^2*x2^2*x3^2*x7^2 -

Re: [sage-support] Re: Fwd: sage bug report

You evaluate it over ZZ[x1,...,xn] rather than GF(2)[x1,...,x4]. Anyways, it simply can't be *that* slow in any case: even: the (theoretically ) maximum number of monoms that can be in any expansion is less than a few thousands, so the upper limit for a naively implemented Gaussian elimination is

Re: [sage-support] Re: Fwd: sage bug report

The speed could be do to the inefficiency of fraction field arithmetic over the polynomial ring. Ideally, we should have fraction-free gaussian elimination. Also, easily invertable/small determinant may actually be worse--as it could be creating a lot of large intermediate values with

Re: [sage-support] Re: Fwd: sage bug report

It is impossible to come up with any reasonable explanation for this kind of slowdown. Even if you do extremely stupid things like summing all permutations and simplifying the expression at the end, you can't get that slow. Additionally, you cansee that the inverse is computed readily. If you

Re: [sage-support] Re: Fwd: sage bug report

On Thu, Dec 17, 2009 at 5:58 PM, Christian Szegedy christian.szeg...@gmail.com wrote: It is impossible to come up with any reasonable explanation for this kind of slowdown. Even if you do extremely stupid things like summing all permutations and simplifying the expression at the end, you can't

Re: [sage-support] Re: Fwd: sage bug report

On Dec 17, 2009, at 5:58 PM, Christian Szegedy wrote: It is impossible to come up with any reasonable explanation for this kind of slowdown. Even if you do extremely stupid things like summing all permutations and simplifying the expression at the end, you can't get that slow. No, but if

Re: [sage-support] abs exp simplify bug

Hi, On Sun, 29 Nov 2009 17:06:36 -0800 (PST) rych rych...@gmail.com wrote: var('y', domain='real') assume(y, 'real') abs(exp(y*I)).simplify() 1 abs(exp(1.1*y*I)).simplify() e^(1.1*I*y) The last result is incorrect. It seems simplify() doesn't like floating point? Thank you

[sage-support] abs exp simplify bug

var('y', domain='real') assume(y, 'real') abs(exp(y*I)).simplify() 1 abs(exp(1.1*y*I)).simplify() e^(1.1*I*y) The last result is incorrect. It seems simplify() doesn't like floating point? -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from

[sage-support] Piecewise Function gotcha - bug or feature?

Piecewise Function: endpoint gotcha - bug or feature? It seems that the piecewise function (which requires overlapping endpoints for the specified function intervals) does some unadvertised averaging for results for values at the endpoints. See the sage output from the input below. Rather than

[sage-support] sxrange / xsrange possible bug

Dan, Please start a new thread rather than change the subject line. Thanks! Mariah On Sep 16, 2:33 pm, Dan Aldrich daldr...@earthlink.net wrote: I've been using sagenb for a few weeks now and have the hang of most of the easy things. Is there a way to generate tables of a user defined

[sage-support] sxrange / xsrange possible bug

Perhaps I do not understand sxrange / xsrange correctly. The reference manual entries for them seem to be similar. Is there a difference? (If one is just an alias for the other, it would be best to say so. If they are different, the reference manual needs to emphasize the difference.) Also

[sage-support] Re: possible Polynomial_integer_dense_flint bug

Sorry, mistyped. Should be A = 2^(2^17+2^15) On Sep 10, 11:51 am, Mariah Lenox mariah.le...@gmail.com wrote: In sage-4.1.1 R.x = PolynomialRing(ZZ) A = 2^(2^17+s^15) a = A * x^31 b = (A * x) * x^30 a == b   # prints False ??? I believe A and 31 are minimal to exhibit the bug. Can

  1   2   >