[sage-support] Re: Bug in integrals

2021-12-17, Juan Luis Varona: > > Thanks! > > It is clear that it is a bug provided by Maxima. > I have checked already in the developer trac > the already known Maxima bugs in integrals > and I have not found similar errors, so I have > opened a ticket. > > Juan Luis Thanks for opening a ticket a

[sage-support] Re: Bug in integrals

Thanks! It is clear that it is a bug provided by Maxima. I have checked already in the developer track the already known Maxima bugs in integrals and I have not found similar errors, so I have opened a ticket. Juan Luis El jueves, 16 de diciembre de 2021 a las 19:21:03 UTC+1, Emmanuel Charpent

[sage-support] Re: Bug in integrals

A nice one, indeed. Here, Sage seems to use Maxima’s integrator : sage: table([[u,(f(x)-g(x)).integrate(x,algorithm=u)] for u in ["maxima", "sympy", "giac", "fricas", "mathematica_free"]], header_row=["Algorithm", "Indefinite integral"]) Algorithm Indefinite integral +--

[sage-support] Re: Bug in integrals

Le mercredi 15 décembre 2021 à 20:43:07 UTC+1, juanlui...@gmail.com a écrit : > See this example: > > f(x)=(x+sin(3*x))*exp(-3*x*I) > g(x)=f(x).expand() > integral(f(x)-g(x),(x,0,2*pi)) > > The answer is I*pi, but it should be 0. > Huh ? f has no poles ; therefore, the value of the integrate be

Re: [sage-support] Re: bug in CirculantGraph(10,[2,4])?

On Mon, Jun 29, 2020 at 2:04 PM John H Palmieri wrote: > According to wikipedia, graphs.CirculantGraph(n, [j_1, j_2, ...]) is > connected if and only if gcd(n, j_1, j_2, ...) = 1. In this case, the gcd > is 2. If Sage's definition is correct, it's defined as having 10 vertices, > and vertex i is

[sage-support] Re: bug in CirculantGraph(10,[2,4])?

According to wikipedia, graphs.CirculantGraph(n, [j_1, j_2, ...]) is connected if and only if gcd(n, j_1, j_2, ...) = 1. In this case, the gcd is 2. If Sage's definition is correct, it's defined as having 10 vertices, and vertex i is connected to vertices i+2, i-2, i+4, i-4, then even vertices

[sage-support] Re: Bug (inconsistent behaviour) of graph6_string/sparse6_string

OK, I nearly forgot about the following: sage: K2=graphs.CompleteGraph(2) sage: P=K2.cartesian_product(K2) sage: print(P.graph6_string()) sage: print(P.sparse6_string()) Cr :CoKN However, my installation of nauty (and older installation of sage) claims, that to graph6_string "Cr" corresponds

[sage-support] Re: bug in simple limit

This is now https://trac.sagemath.org/ticket/27311 (this is my first ticket, I hope everything is OK). On Sunday, 17 February 2019 12:28:47 UTC+1, Emmanuel Charpentier wrote: > > You are right. Did you file a ticket ? > > Le jeudi 14 février 2019 22:37:21 UTC+1, list...@gmail.com a écrit : >> >>

[sage-support] Re: bug in simple limit

You are right. Did you file a ticket ? Le jeudi 14 février 2019 22:37:21 UTC+1, list...@gmail.com a écrit : > > > Hello. > > I have found the following bug in limit. > > ┌┐ > > │ SageMath version 8.6, Release Date: 2019-01-15

[sage-support] Re: BUG report

On Friday, August 17, 2018 at 1:48:30 AM UTC+3, Laurent Bakri wrote: > > Hi all, > as indicated in the crash message, I email you the crash report. > we need to know how you installed Sage, and something about your OS (what Linux distribution and what version it is). > > Cheers, > *

[sage-support] Re: Bug report-Sage

PS: Found using the following trac query: https://trac.sagemath.org/query?order=id&desc=1&summary=~abs(sin -- 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 sage-

[sage-support] Re: Bug report-Sage

Sun 2018-02-11 21:55:14 UTC, Andrey Novoseltsev: > > I got this bug report and it seems that I have seen something similar > in the past but can't find it. Is it already known/tracked? > > show(integral(abs(sin(pi*x)), x, 0, 1)) > plot(abs(sin(pi*x)), 0, 1) > > The value of the integral is incorrec

[sage-support] Re: Bug report-Sage

It's the pattern sqrt(f(x)) with f containing trigonometric functions. Use giac for such integrals. sage: integral(abs(sin(pi*x)), x, 0, 1, algorithm='giac') 2/pi There is no meta ticket for this, you can find integration tickets at https://trac.sagemath.org/wiki/symbolics#Integrationtickets I

[sage-support] Re: Bug report: Kernel dies after 1 hour while dividing polynomials

I will close this "error report thread" here, since I got a perfect answer at https://ask.sagemath.org/question/40935/bug-report-kernel-dies-after-1-hour-while-dividing-polynomials/ The workaround is not to create the quotient ring. It is better to work in polynomial rings and to use the "lift"

[sage-support] Re: Bug report: Kernel dies after 1 hour while dividing polynomials

Nils, thank you very much for your answer. (1) You are right when you say that the division of polynomials can't always be done in ideals. In my special case I deal with meromorphic functions on the general elliptic curve with 17-torsion point P=(0,0) and basepoint O and know the divisors of all

[sage-support] Re: Bug report: Kernel dies after 1 hour while dividing polynomials

On Monday, February 5, 2018 at 9:11:44 AM UTC, Patrick Reichert wrote: > > I want to submit an *error report* for SAGE 7.0 and 8.0: > > The division of two polynomials in an ideal causes an *kernel death* > after one hour of computation. > Singular performs the calculation in about *one second*. >

[sage-support] Re: Bug in graphs.WheelGraph(3).show().

It is easy to see why the plot is off for n<4, by looking at the implementation: sage: graphs.WheelGraph?? the plotting layout is computed in the 1st 6 lines of the implementation: pos_dict = {} pos_dict[0] = (0,0) for i in range(1,n): x = float(cos((pi/2) + ((2*pi)/(n-1))*(i

[sage-support] Re: Bug in BooleanFunction: truth_table(format="hex") is wrong

I have now reported this suspected bug as https://trac.sagemath.org/ticket/24282 -- 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 sage-support+unsubscr...@google

[sage-support] Re: Bug report.

The relevant line is ImportError: libgfortran.so.3: cannot open shared object file: No such file or directory You need to install libgfortran. For this, run this command in a terminal: sudo apt-get install libgfortran -- You received this message because you are subscribed to the Goog

Re: [sage-support] Re: Bug(?) in the division of polynomials with the TermOrder('neglex')

I think the problem was not in Singular but in the Sage code for division of polynomials. There is a ticket, https://trac.sagemath.org/ticket/17638. I may help but my skills are not enough to solve the problem. El martes, 22 de noviembre de 2016, 19:18:07 (UTC+1), Justin C. Walker escribió: > >

Re: [sage-support] Re: Bug(?) in the division of polynomials with the TermOrder('neglex')

On Nov 22, 2016, at 05:40 , Dima Pasechnik wrote: > > On Tuesday, November 22, 2016 at 12:19:37 PM UTC, Sho Takemori wrote: >> >> Thank you very much for your explanation. I have seen your post at >> sage-devel before, but completely forgot it. >> >> I guess it would be better to raise an err

[sage-support] Re: Bug(?) in the division of polynomials with the TermOrder('neglex')

On Tuesday, November 22, 2016 at 12:19:37 PM UTC, Sho Takemori wrote: > > Thank you very much for your explanation. I have seen your post at > sage-devel before, but completely forgot it. > > I guess it would be better to raise an error or print a message than to > return a wrong result, if it i

[sage-support] Re: Bug(?) in the division of polynomials with the TermOrder('neglex')

Thank you very much for your explanation. I have seen your post at sage-devel before, but completely forgot it. I guess it would be better to raise an error or print a message than to return a wrong result, if it is a known bug and not fixed yet. Sho Takemori 2016年11月22日火曜日 19時27分58秒 UTC+9 Enr

[sage-support] Re: Bug(?) in the division of polynomials with the TermOrder('neglex')

This is an old bug affecting polynomials with local or semilocal orders. The problem is that at some point, the definition of the division by a polynomial checks first if the polynomial is a unit and in that case it identifies it with the constant term. This works for global orderings, but it c

[sage-support] Re: bug in hyperelliptic curve point counting

This issue is #20391 on trac, and was supposed to have been resolved by #18916 (which is fixed in sage 7.4). But it looks like it's not, even though the similar test case: sage: x = polygen(GF(4099)) sage: H = HyperellipticCurve(x^6 + x + 1) sage: H.count_points(1) that I had been using does n

[sage-support] Re: Bug report : function Matrix.set_block() may not work correctly with extension fields

On Monday, May 23, 2016 at 9:22:35 AM UTC-7, Guillaume Holler wrote: > > I don't know if this is the right place to submit bugs. > It's a reasonable place to start. > I have consistently reproduced the following bug: > I have tried and was unable to reproduce your results on 7.2. Can you give

[sage-support] Re: Bug in g.character_table()

On Wednesday, April 27, 2016 at 2:00:42 PM UTC+1, Peter Mueller wrote: > > sage: AlternatingGroup(12).character_table() > File "", line 2 > -zeta35**Integer(27)-zeta35**Integer(29)-zeta35**Integer(33) > ^ > IndentationError: unexpected indent > > Looking into the function character_tabl

[sage-support] Re: Bug in integrate

On Tuesday, April 26, 2016 at 7:41:44 AM UTC-7, Laurent Decreusefond wrote: > > > What does mean log(-1+e^(-2*t)) since the argument is negative ? > For t<0 that expression takes real values, so there the answer even makes sense in a real setting. The answer is generally correct for complex valu

Re: [sage-support] Re: bug in numerical evaluation of symbolic expression

On 25/04/16 17:49, William Stein wrote: On Mon, Apr 25, 2016 at 12:06 PM, Volker Braun wrote: Presumable its because the RR nan doesn't correctly convert to the SR nan: sage: NaN.is_zero() False sage: SR(RR('nan')).is_zero() True Related and confusing/wrong/inconsistent: sage: RR('nan').is_

Re: [sage-support] Re: bug in numerical evaluation of symbolic expression

On Mon, Apr 25, 2016 at 12:06 PM, Volker Braun wrote: > Presumable its because the RR nan doesn't correctly convert to the SR nan: > > sage: NaN.is_zero() > False > sage: SR(RR('nan')).is_zero() > True Related and confusing/wrong/inconsistent: sage: RR('nan').is_zero() True sage: RR('nan') == 0

[sage-support] Re: bug in numerical evaluation of symbolic expression

Presumable its because the RR nan doesn't correctly convert to the SR nan: sage: NaN.is_zero() False sage: SR(RR('nan')).is_zero() True On Monday, April 25, 2016 at 7:40:39 PM UTC+2, William wrote: > > For a problem set I'm making today, I made up a random symbolic function, > then evaluated i

[sage-support] Re: bug in == operator?

On Monday, July 13, 2015 at 7:24:36 PM UTC+2, Volker Braun wrote: > > I suppose __nonzero__ should try to cast to QQbar and AA first before > trying maxima. > Fixed and needs review: http://trac.sagemath.org/ticket/18896 With this Sage would also pass one more test from Wester's paper. Regards

[sage-support] Re: bug in == operator?

Which boils down to sage: sage.symbolic.relation.test_relation_maxima(SR(m) == SR(m1)) True Which comes from $ sage --maxima ;;; Loading #P"/home/vbraun/Code/sage.git/local/lib/ecl/sb-bsd-sockets.fas" ;;; Loading #P"/home/vbraun/Code/sage.git/local/lib/ecl/sockets.fas" ;;; Loading #P"/home/vbrau

[sage-support] Re: bug in == operator?

This is IMHO a bug in SR __nonzero__ only. Ginac/Pynac seems to handle the comparison just fine: sage: RealField(300)(m) > RealField(300)(m1) True sage: RealField(300)(m) < RealField(300)(m1) False sage: cmp(SR(m), SR(m1)) -1 sage: cmp(RealField(100)(m), RealField(100)(m1)) -1 sage: bool(SR(m)

[sage-support] Re: bug in == operator?

Hi William, On 2015-07-13, William Stein wrote: > Despite what other people are saying in this thread, I definitely 100% > consider the above a bug. My impression is that all participants of this thread agree that it is a bug. > Doing m == m1, should first coerce both to > SR, then compare ther

[sage-support] Re: bug in == operator?

On Monday, July 13, 2015 at 4:11:05 PM UTC+2, Simon King wrote: > > In other words: If one *can* avoid symbolic expressions, then one *should* > avoid symbolic expressions. > That's just not going to fly for the casual/novice user: sage: sqrt(2) sqrt(2) sage: QQbar(sqrt(2)) 1.414213562373095?

[sage-support] Re: bug in == operator?

Hi all, On 2015-07-13, Nathann Cohen wrote: >> PS Testing over QQbar certainly does give False, as it would for m*sqrt(1/2) >> and n for any pair of integers (m,n) not (0,0), since sqrt(2) is irrational! > > Wouldn't it be better to compare 'exact types' in an exact ring? Here > we compare two ex

Re: [sage-support] Re: bug in == operator?

> PS Testing over QQbar certainly does give False, as it would for m*sqrt(1/2) > and n for any pair of integers (m,n) not (0,0), since sqrt(2) is irrational! Wouldn't it be better to compare 'exact types' in an exact ring? Here we compare two exact types in a non-exact field. Nathann -- You rec

Re: [sage-support] Re: bug in == operator?

Since m1.nbits() is 178, work to higher precision: sage: R = RealField(200) sage: R(m)==R(m1) False sage: R(m)-R(m1) 0.89272832870483398437500 This seems to be what is wanted. I agree that it is bad that m==m1 gives True: m is in the Symbolic Ring (check m.par

Re: [sage-support] Re: bug in == operator?

> Is there a way to force a more exact equality test? It works "as intended" over QQbar: sage: QQbar(m) == QQbar(m1) False Nathann -- 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 i

[sage-support] Re: bug in == operator?

> > This is in SageMath Version 6.6, Release Date: 2015-04-14 running on a > MacBook. The following lines print 'equal', even though m and m1 do not > appear equal to me! > It seems that this equality is an equality over 'double' floats. So not all digits of your numbers are taken into accoun

[sage-support] Re: bug: adding a number to matrix

When working with nxn matrix, writing a scalar (= a number if you name "numbers" matrix elements) like 'a' is the same than writing 'aI' where I is identity matrix with 1 in diagonal and 0 for other elements) or writing the diagonal matrix with a in diagonal and 0 for other elements) addition

[sage-support] Re: bug: adding a number to matrix

Hi Avi, On 2015-07-12, avi kaur wrote: > Hello > > I figured out that when we add a number to a matrix, It adds this > number to all the elements at diagonal of matrix. for example: That's the expected behaviour. If R is a commutative ring and M is the ring of all nxn matrices over R, then we ca

[sage-support] Re: (Bug?) conjugate ignored by solve()

On Monday, May 25, 2015 at 10:23:28 AM UTC+2, gschi...@gmail.com wrote: > > > sage: sage: var('z'); conjugate(z+i) > conjugate(z) - I > # (as expected) > > # But: > conjugate(z+i==0) > z + I == 0 > # expected: conjugate(z) - I == 0 > > Here's another example showing that the conjugate is simply d

[sage-support] Re: (Bug?) conjugate ignored by solve()

On Sunday, May 24, 2015 at 4:23:59 PM UTC+2, Ralf Stephan wrote: > > Thanks for the report. I have opened > http://trac.sagemath.org/ticket/18488 > > Regards, > Thanks! I'd like to add that some more experimentation with the complex conjugate in relation to equations and equalities made me r

[sage-support] Re: (Bug?) conjugate ignored by solve()

Thanks for the report. I have opened http://trac.sagemath.org/ticket/18488 Regards, -- 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 sage-support+unsubscr...@go

[sage-support] Re: bug report with Rubik's cube functions

I have just realized that CubeGroup().faces("U") also goes counterclockwise ! what a mess ! On Thursday, March 19, 2015 at 1:07:12 PM UTC+1, Pierre wrote: > > Hi, > > I have just realized this, and thought it would be helpful to know for > anyone playing with Sage's Rubik's cube abilitites. H

Re: [sage-support] Re: bug report

On Feb 21, 2015 1:48 PM, "kcrisman" wrote: >> >> >> I'm constantly getting basic calculus bug reports because of >> SageMathCloud.We don't have a "sage-bugs" list, and even I'm not >> sure where to send these bug reports... >> > > Sage-support seems reasonable to me. Unless we have a way to m

[sage-support] Re: bug report

> > > I'm constantly getting basic calculus bug reports because of > SageMathCloud.We don't have a "sage-bugs" list, and even I'm not > sure where to send these bug reports... > > Sage-support seems reasonable to me. Unless we have a way to make it easier to use Trac (no reg process), but

[sage-support] Re: bug report

On Sat, Feb 21, 2015 at 11:42 AM, William Stein wrote: > From a user: > > I verified that Sage does what he claims [1]. I guess this is a bug > in Maxima really. Follow-up: One can also get a different incorrect answer using algorithm='sympy' sage: limit(csc(x),x=0, algorithm='sympy') +Infi

Re: [sage-support] Re: bug in graph embedding?

Hi Nathan, thanks for fixing this. For the next two weeks or so I expect to be very busy. I can do some reading and try to figure out how the process works, but I'm not sure how much time I'll have to spare. Realistically I may have some time in mid February. Nikos On Wed, Jan 21, 2015 at 2:2

Re: [sage-support] Re: bug in graph embedding?

Hello again!!! > You're riight. After looking carefully at my definition of cy (the cyclic > order of the non zero group elements that give the cyclic order of the edges > around each vertext) I noticed that instead of A*C^-1 I had AC^1. Once I > corrected that everything works. Cool. Mystery so

[sage-support] Re: bug in graph embedding?

On Wednesday, January 21, 2015 at 8:11:23 AM UTC-5, Nathann Cohen wrote: > > Hello, > > I'm looking at embeddings of complete gaphs and I think I've found a bug: >> I defined the complete graph k12 as a (sort of) Cayley graph of the group >> Z₂²× Z₃ as follows: >> > > First, it seems that the P

[sage-support] Re: bug in graph embedding?

Hello, I'm looking at embeddings of complete gaphs and I think I've found a bug: I > defined the complete graph k12 as a (sort of) Cayley graph of the group > Z₂²× Z₃ as follows: > First, it seems that the Python code you copy/pasted in your message lost its indentation. Thus, I have no way t

Re: [sage-support] Re: Bug in solve?

> > >> Only 2 years later, and I found a way around segmentation faults due to > >> memory problems. It seems that my looping functions fill up memory over > time > >> and lead to segmentation faults at random stages. I now define such > >> functions using the @fork decorator and then they don

Re: [sage-support] Re: Bug in solve?

On Wed, Jan 7, 2015 at 8:34 AM, kcrisman wrote: > >> Only 2 years later, and I found a way around segmentation faults due to >> memory problems. It seems that my looping functions fill up memory over time >> and lead to segmentation faults at random stages. I now define such >> functions using the

[sage-support] Re: Bug in solve?

> Only 2 years later, and I found a way around segmentation faults due to > memory problems. It seems that my looping functions fill up memory over > time and lead to segmentation faults at random stages. I now define such > functions using the @fork decorator and then they don't seem to cause

[sage-support] Re: Bug in solve?

Only 2 years later, and I found a way around segmentation faults due to memory problems. It seems that my looping functions fill up memory over time and lead to segmentation faults at random stages. I now define such functions using the @fork decorator and then they don't seem to cause crashes

[sage-support] Re: Bug in symbolic integral

Hello, This appears to be a bug in the evaluation of the incomplete Gamma function in the older PARI version(s) used by Sage up to and including 6.3. The computation is correct in the newly released Sage 6.4, which uses the recent stable PARI release 2.7.1. (See also http://trac.sagemath.org/

[sage-support] Re: Bug in symbolic integral

> > Hmm, I can't reproduce this problem. I am working w/ Maxima 5.34.1. > > (%i1) display2d : false $ > (%i2) foo : 1/log(x)^2 $ > (%i3) integrate (foo, x, 2, 3); > (%o3) gamma_incomplete(-1,-log(3))-gamma_incomplete(-1,-log(2)) > (%i4) %, numer; > (%o4) 1.273097216447114 > (%

[sage-support] Re: Bug in symbolic integral

On 2014-11-12, Johannes Lippmann wrote: > *symbolic way* > (I think this is wrong) > > sage: N(integral(1/log(x)^2,(x,2,3))) > *0.536566859259958* Hmm, I can't reproduce this problem. I am working w/ Maxima 5.34.1. (%i1) display2d : false $ (%i2) foo : 1/log(x)^2 $ (%i3) integrate (foo, x

[sage-support] Re: Bug in symbolic integral

> > *numerical way* > (double checked by Wolfram Alpha > > > and Maple): > > sage: numerical_integral(1/log(x)^2,2,3) > > (*1.273097216447114*, 1.4134218422857824e-14) > > *symbolic way* > (I think this is

Re: [sage-support] Re: BUG - Sage Version 6.3, Release Date: 2014-08-10

In addition, every load must fail gracefully if you want your software to work. Anything that can throw exceptions (like loading files or unpickling) must be in a try/except block. Ideally you add the try/except when you write the method the first time, not some time later after it caused a pro

Re: [sage-support] Re: BUG - Sage Version 6.3, Release Date: 2014-08-10

On 2014-11-05 16:16, Nicolas M. Thiéry wrote: For the record, my students got this error a couple times, on a relatively recent Ubuntu, with Sage 6.3, probably recompiled on site. Usually, this is due to Sage dying brutally (typically when they close the terminal where they launched the notebook)

[sage-support] Re: BUG - Sage Version 6.3, Release Date: 2014-08-10

I think that Jan had some similar things happen, and may have some advice... > For the record, my students got this error a couple times, on a relatively > recent Ubuntu, with Sage 6.3, probably recompiled on site. Usually, this is > due to Sage dying brutally (typically when they close the t

[sage-support] Re: BUG - Sage Version 6.3, Release Date: 2014-08-10

For the record, my students got this error a couple times, on a relatively recent Ubuntu, with Sage 6.3, probably recompiled on site. Usually, this is due to Sage dying brutally (typically when they close the terminal where they launched the notebook). Removing the corrupted empty "users.pickle"

[sage-support] Re: Bug in Polyhedron from equations in number field

I've moved this to trac. See: http://trac.sagemath.org/ticket/17197#ticket -- 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 sage-support+unsubscr...@googlegroups.

Re: [sage-support] Re: BUG - Sage Version 6.3, Release Date: 2014-08-10

Hello. Is it possible to download the previous binary distribution of Sage 6.2 for Ubuntu 14? Christophe BAL -- 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] Re: BUG - Sage Version 6.3, Release Date: 2014-08-10

Yes, that's it. Christophe BAL Le 16 août 2014 14:58, "Dima Pasechnik" a écrit : > On 2014-08-16, Christophe Bal wrote: > > --089e013cba22d420490500bb2fa6 > > Content-Type: text/plain; charset=UTF-8 > > > > Hello. > > > > Under Ubuntu 14, the latest version 6.3 contains some files not goood > E

[sage-support] Re: BUG - Sage Version 6.3, Release Date: 2014-08-10

On 2014-08-16, Christophe Bal wrote: > --089e013cba22d420490500bb2fa6 > Content-Type: text/plain; charset=UTF-8 > > Hello. > > Under Ubuntu 14, the latest version 6.3 contains some files not goood EOF. Do you mean the binary distribution of Sage 6.3 for Ubuntu 14? And you get this by typing 'not

[sage-support] Re: Bug report - solve([sin(cos(x))/cos(x)==0],x) gives wrong result

On Friday, June 27, 2014 5:26:36 PM UTC-4, Christoph Jentzsch wrote: > > Hi there, > > solve([sin(cos(x))/cos(x)==0],x) gives: > > [x == 1/2*pi] > which is wrong. There is no solution. > > Thanks for reporting this. > > See plot(sin(cos(x))/cos(x),(-pi,pi)) > > > Well, in any case solve is

Re: [sage-support] Re: bug in comparison of function field elements

On Tue, Apr 29, 2014 at 10:57 PM, Robert Bradshaw wrote: > On Tue, Apr 29, 2014 at 9:07 AM, Volker Braun wrote: >> On Tuesday, April 29, 2014 3:58:14 PM UTC+1, Simon King wrote: >>> >>> Yes there is! The hook is the hash function. >> >> >> CPython implementation detail and subject to change... re

Re: [sage-support] Re: bug in comparison of function field elements

On Tue, Apr 29, 2014 at 9:07 AM, Volker Braun wrote: > On Tuesday, April 29, 2014 3:58:14 PM UTC+1, Simon King wrote: >> >> Yes there is! The hook is the hash function. > > > CPython implementation detail and subject to change... really Python makes > no guarantee that __hash__() is called at any

[sage-support] Re: bug in comparison of function field elements

On Tuesday, April 29, 2014 3:58:14 PM UTC+1, Simon King wrote: > > Yes there is! The hook is the hash function. CPython implementation detail and subject to change... really Python makes no guarantee that __hash__() is called at any particular point. Its of course safe to normalize elements the

Re: [sage-support] Re: bug in comparison of function field elements

On 29 April 2014 16:17, Nils Bruin wrote: > On Tuesday, April 29, 2014 7:47:39 AM UTC-7, Volker Braun wrote: >> >> Always putting things in canonical form will be slow (there is no hook for >> "you are about to be put into a set") and/or not possible (fp group >> elements). > > > I disagree in thi

Re: [sage-support] Re: bug in comparison of function field elements

On Tuesday, April 29, 2014 7:47:39 AM UTC-7, Volker Braun wrote: > > Always putting things in canonical form will be slow (there is no hook for > "you are about to be put into a set") and/or not possible (fp group > elements). > I disagree in this particular case. Making the denominator monic is

Re: [sage-support] Re: bug in comparison of function field elements

On 29 April 2014 15:56, John Cremona wrote: > > I will open a ticket... #16268 (see http://trac.sagemath.org/ticket/16268) > > John > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails f

Re: [sage-support] Re: bug in comparison of function field elements

On Tuesday, April 29, 2014 3:35:55 PM UTC+1, John Cremona wrote: > > On 29 April 2014 15:16, Volker Braun > > wrote: > > s and t are not the same expression, so they have different hashes. We > break > > Python by letting them compare equal. Hence the outcome of putting them > into > > sets i

[sage-support] Re: bug in comparison of function field elements

Hi Volker, On 2014-04-29, Volker Braun wrote: > Always putting things in canonical form will be slow (there is no hook for > "you are about to be put into a set") Yes there is! The hook is the hash function. If you need a hash (i.e., if you put it into a set or dict) then you need a canonical f

Re: [sage-support] Re: bug in comparison of function field elements

On 29 April 2014 15:47, Volker Braun wrote: > On Tuesday, April 29, 2014 3:35:55 PM UTC+1, John Cremona wrote: >> >> On 29 April 2014 15:16, Volker Braun wrote: >> > s and t are not the same expression, so they have different hashes. We >> > break >> > Python by letting them compare equal. Hence

[sage-support] Re: bug in comparison of function field elements

Hi John, On 2014-04-29, John Cremona wrote: > That is a *very* unsatisfactory explanation for anyone actually > wanting to use Sage to do mathematics. +1 > That > function could easily be amended to do the second step, which would > make it more useful. ... and it should be used in the hash m

Re: [sage-support] Re: bug in comparison of function field elements

On 29 April 2014 15:16, Volker Braun wrote: > s and t are not the same expression, so they have different hashes. We break > Python by letting them compare equal. Hence the outcome of putting them into > sets is undefined. In CPython: if the hash collides, you get one element. If > the hash does n

[sage-support] Re: bug in comparison of function field elements

s and t are not the same expression, so they have different hashes. We break Python by letting them compare equal. Hence the outcome of putting them into sets is undefined. In CPython: if the hash collides, you get one element. If the hash does not collide, you get two elements. On Tuesday, A

[sage-support] Re: bug in comparison of function field elements

Hi John, On 2014-04-29, John Cremona wrote: > sage: s==t > True > sage: Set([s,t]) > {(27*u^2 + 81*u + 243)/(27*u - 81), (u^2 + 3*u + 9)/(u - 3)} Internally, a set would first distribute the given elements in "hash buckets". Elements in different hash buckets will not be compared by "==". And he

[sage-support] Re: bug on error reporting in sage notebook?

On Monday, March 3, 2014 4:20:22 PM UTC-5, Fred Gruber wrote: > > In the sage 6 notebook , if I type the following R code (in R mode) > myfunc2<-function(x){ > print(x) > if (x>1){ > print('x larger than 1') > } > > > where there is a missing bracket I do not get any errors from sage. It

[sage-support] Re: bug/feature in subs() for polynomials in a polynomial ring over a polynomial ring

On 2014-02-17, Marc Mezzarobba wrote: > Dima Pasechnik wrote: >> sage: r0=QQ['a1,a2'] >> sage: a1,a2=r0.gens() >> sage: r=r0['x1,x2'] > [...] >> I am using such a ring as I want to treat ai as parameters, i.e. I >> would like monomial expansions in xi alone. >> Perhaps there is a better way to acc

[sage-support] Re: bug/feature in subs() for polynomials in a polynomial ring over a polynomial ring

Dima Pasechnik wrote: > sage: r0=QQ['a1,a2'] > sage: a1,a2=r0.gens() > sage: r=r0['x1,x2'] [...] > I am using such a ring as I want to treat ai as parameters, i.e. I > would like monomial expansions in xi alone. > Perhaps there is a better way to accomplish this? The best I can think of is p.map_

[sage-support] Re: bug with variety(): order of the variables seem to matter!

Hi, I can reproduce the OP's problem on Sage Version 6.0, Release Date: 2013-12-17 on Ubuntu 13.10, 3.8.0-35-generic. In fact, I ran into the same problem. The reason seems to be that the polynomial ring is over QQ, while the the root-extraction in the variety(ring=QQbar) command is over QQbar.

Re: [sage-support] Re: Bug in genus of an ideal

On Mon, Jan 27, 2014 at 05:29:37AM -0800, kroe...@uni-math.gwdg.de wrote: > This is probably a late comment, > > but genus() in Singular is also known for containing bugs, > see tickets > http://www.singular.uni-kl.de:8002/trac/ticket/259, > http://www.singular.uni-kl.de:8002/trac/ticket/469 > >

Re: [sage-support] Re: Bug in genus of an ideal

This is probably a late comment, but genus() in Singular is also known for containing bugs, see tickets http://www.singular.uni-kl.de:8002/trac/ticket/259, http://www.singular.uni-kl.de:8002/trac/ticket/469 Jack Am Dienstag, 23. November 2010 11:56:20 UTC+1 schrieb Martin Albrecht: > > On Tuesd

Re: [sage-support] Re: Bug in primary decomposition of (1) ideal: the primary decomposition should be empty

The output is also as you report with Sage-6.0. Generally speaking it is a good idea to check with a recent version, preferebaly the lastest, before reporting a problem. Version 5.12 is prehistoric! Of course your point is still valid. In th Sage function , all the work is done by Singular. My

[sage-support] Re: Bug in primary decomposition of (1) ideal: the primary decomposition should be empty

Version: 'Sage Version 5.2, Release Date: 2012-07-25' OS: Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 On Wednesday, December 18, 2013 10:58:31 PM UTC-8, Matthias Goerner wrote: > > Ideal(PolynomialRing(RationalField(),['x','y']),-1).prima

[sage-support] Re: Bug in product of polyhedra

Thanks, this is now http://trac.sagemath.org/ticket/15253 On Friday, October 4, 2013 7:00:45 PM UTC+1, Victor Miller wrote: > > > The cartesian product of two polyhedra doesn't work if their dimensions > are different: > > Consider the following (just run on sagenb.org): > > sage: B1 = Polyhedron

[sage-support] Re: Bug? in n() function for vectors?

By the way, following Jason's reasoning above, by re-defining ZZ (which I have just realised was a bad choice of variable name sorry!) as ZZ = diagonal_matrix([exp(2*pi*I/4)^ii for ii in range(0,4)]).dense_matrix() the problem does indeed go away. So there is a temporary workaround ... On Satu

[sage-support] Re: Bug? in n() function for vectors?

Dear Jason, thank you very much. Re the patch: sadly, I tried (thanks to Basu's infinitely patient hints) to get involved with amending the docs a few months ago, but failed miserably and even put up an ad for someone to help me with SAGE/computing here at Imperial (!) but got nowhere with tha

[sage-support] Re: Bug? in n() function for vectors?

On 8/16/13 5:34 PM, Jason Grout wrote: entries=dict([(e[0],e[1].n(prec, digits)) for e in self._entries.iteritems()]) if len(self)-1 not in entries: entries[len(self)-1]=0 vector(entries, sparse=True) It could be shortened by using the setdefault method: entries=dict([(e[0],e[1].n(prec,

[sage-support] Re: Bug? in n() function for vectors?

On 8/16/13 4:40 PM, GaryMak wrote: Hi all I hesitate to declare a <>, since it's probably something I cannot find in the help, but the following is very strange The following code always seems to output many vectors "quad" of length 4 each of whose numerical approx "quad.n()" is a vector w

[sage-support] Re: Bug? in n() function for vectors?

PS sorry I forgot to mention this happens in 5.7 and 5.11 on a Mac OSX 5.6.8 On Friday, August 16, 2013 10:40:25 PM UTC+1, GaryMak wrote: > > Hi all > > I hesitate to declare a <>, since it's probably something I cannot > find in the help, but the following is very strange > > The following

[sage-support] Re: Bug in evaluation of Maxima numbers? Or where? Or not a bug at all?

On Monday, July 22, 2013 6:36:04 PM UTC+2, Jesus Torrado wrote: > > So the "b" as an exponential sign is treated as a variable, producing some > funny behaviour: > > sage: maxima("2*bfloat(2e-4)").sage() > 4.0*b - 4 > sage: 2*maxima("bfloat(2e-4)").sage() > 4.0*b - 8 > That's inde

[sage-support] Re: Bug in evaluation of Maxima numbers? Or where? Or not a bug at all?

Hi all, Coming from: https://groups.google.com/forum/#!topic/sage-support/vv6yvZMVFAQ Thanks, Rob! So it seems Sage does not interpret correctly some Maxima numbers. In particular, I have noticed two issues: 1) Big floats: sage: maxima("bfloat(2e-4)") 2.0b-4 sage: maxima("bfloat(

  1   2   3   4   5   >