[sage-devel] Re: The 2013 Spies Prize winner is...

Gefeliciteerd, Jeroen! -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@goo

[sage-devel] Re: RFC: a good name the category of algebras that are not necessarily associative nor unital

an algebra. If any > additional > axiom holds, then the algebra should be called commutative, associative, > unital, > noetherian, lie, finite-dimensional, or whatever you like. But don't > mention the > *absence* of axioms! > Best regards, Peter Bruin -- You r

Re: [sage-devel] Re: Products of permutations use nonstandard order of operation

Hi Marco and all, I had Darij's problem as well, and many others probably did as well. > In a right action, I would prefer p(1) to give a warning. In a right > action, I would want some notation where p is on the right, preferably > 1^p (1 hat p). > That would make sense (except that I don't

[sage-devel] Motivation for ElementMethods in categories

Hello, A discussion was just started at http://trac.sagemath.org/ticket/15192about the reason why categories in Sage have a class ElementMethods. In this ticket, Julian Rüth moved the method is_unit from RingElement to Rings().ElementMethods to fix a certain bug. I thought this wasn't the on

[sage-devel] Re: Motivation for ElementMethods in categories

ut that non-square matrices *do* currently inherit from RingElement! This should clearly be fixed. Shouldn't there be a class SquareMatrix for methods like is_invertible() and determinant()? Thanks again, Peter Op vrijdag 13 september 2013 20:23:21 UTC+1 schreef Peter Brui

[sage-devel] Re: Motivation for ElementMethods in categories

Hi all, Simon King (replying to my question) wrote: > - Do the methods coming from ElementMethods always take priority over > > (override) those from the base classes? > > No, it is the other way around. > Right, and if I now understand correctly, it is because Element.__getattr__() changes th

Re: [sage-devel] Re: not trusted anymore ?

Hello, Robert Bradshaw wrote, It's live, but you'll need to go to a closed ticket of yours and add > ?force to the url (something like > http://patchbot.sagemath.org/ticket/13657/?force ) so it picks up the > 'resolution' field even though the page didn't change. (I'll run a > script to updat

[sage-devel] Re: Motivation for ElementMethods in categories

Hi Simon, We seem to be talking past each other, I'm afraid. I could reply point-by-point to what you wrote, I think it is more productive to emphasise the question that I would really like to see answered: I am looking for a concrete example demonstrating why categories ought to have Element

Re: [sage-devel] Re: Motivation for ElementMethods in categories

Hi Robert, This dates back to before the category framework, when (normal) > inheritance was the only way to get things like this. Yes, it should > be fixed! > I'll open a ticket for it. > Shouldn't there be a class > > SquareMatrix for methods like is_invertible() and determinant()? > > Cur

Re: [sage-devel] Re: Motivation for ElementMethods in categories

> > Here's a concrete example: where should the generic implementation for > Euclid's operation live for computing e.[x]gcd(e)? It seems that it > makes the most sense to place this in the category rather than the > (many) element implementations (unless, of course, there are > compelling perf

Re: [sage-devel] Re: Motivation for ElementMethods in categories

Hi Robert, > I would expect the category framework to figure out that if R is an > object > > in EuclideanDomains, then R.element_class should dynamically inherit > from > > both EuclideanDomainElement and IntegralDomainElement. > > It already does. R need not descend from EuclideanDomain, it

Re: [sage-devel] Re: Motivation for ElementMethods in categories

I don't think I said that I wanted more static inheritance. Basically, you want > > class IntegralDomainElement(Element): > ... > > class IntegralDomain(Parent): > ... > > class EuclideanDomainElement(IntegralDomainElement): > def xgcd(self, other): >

Re: [sage-devel] Re: Motivation for ElementMethods in categories

Hi Robert, >> Also, this seems like a > >> lot of busywork--we should be able to automatically generate these > >> classes for any matrix type when nrows == ncols. But this is exactly > >> what the category framework gives you (though it could have done so > >> with a more sophisticated getatt

[sage-devel] Re: pari questions

Hello John, It would be good to have more people interested in the pari/Sage > interface attending their workshop in early January. > I am definitely interested in going to the workshop. It is clear that the interface between PARI and Sage is very important; there are many things that either

[sage-devel] Re: pari questions

Hello Volker, I talked to Pascal in Bristol fwiw, and apparently the bnr stuff isn't > wrapped in Sage. We created at quick&dirty Cython wrapper for LMFDB, but it > would probably be nice to push that into Sage. > Yes, that is a good example. > On a related note, Jeroen started a thread abou

Re: [sage-devel] Re: Motivation for ElementMethods in categories

Hello Travis, So the proposed change isn't really that big after all, just a >> renaming and the addition of one level of nesting. >> >> class MyCategory(Cagetory_singleton): >> class Object: >> ... >> class Element: >> ... >> >>I'm against this because t

Re: [sage-devel] Re: compilation error on debian

Op woensdag 18 september 2013 10:22:04 UTC+1 schreef Jeroen Demeyer: > > On 2013-09-18 07:20, Dima Pasechnik wrote: > > accoring to http://www.python.org/dev/peps/pep-0263/ > > $SAGE_LOCAL/bin/hg might benefit from the 2nd line saying > > # -*- coding: latin-1 -*- > > (or # -*- coding: utf-8 -*

Re: [sage-devel] Re: compilation error on debian

> PEP 0263 says explicitly that the encoding magic can occur either on the > first or on the second line, presumably for cases like this, so it looks > like it is worth trying. > (If it already tries to decode the first line before looking at the second line to see if it specifies an encoding

[sage-devel] Re: Motivation for ElementMethods in categories

Hi Simon, >From my perspective, the only potential issue is speed. Even a Python > function returning the constant "True" is quite slow. But I think, if > speed matters, it should be possible to have a separate Cython module > providing a class, say, > sage.categories.element_methods.FieldElem

[sage-devel] Re: imag(CC(infinity)) is 0?

> > Out of curiosity, I decided to ask sage what it thought the imaginary part > of infinity was. I'm not quite sure that this should return 0. > Mathematica returns Indeterminate, which seems like a better answer to me. > It is strange that infinity can apparently be converted into a comp

Re: [sage-devel] imag(CC(infinity)) is 0?

Hello, > I guess my follow up question would be do we want infinity to be real in > this sense or is that just a byproduct of its implementation? I don't know > all the uses for infinity that other sage users have, but certainly from > the perspective of the Riemann sphere it's a bit odd sin

Re: [sage-devel] imag(CC(infinity)) is 0?

> > > So I would say that the current behaviour of Sage (Infinity in RR giving > > True and any similar suggestion that infinity is a real number) is > > mathematically wrong and must be changed. It also contradicts the > > documentation of the infinity "ring" (in which Sage's "Infinity" objec

Re: [sage-devel] imag(CC(infinity)) is 0?

Hello, RR isn't named "Real numbers"; it is named "real field with 53 bits > precision" > And, fair enough, the docstring of RR starts as follows: An approximation to the field of real numbers using floating point numbers with any specified precision. Answers derived from calculations

Re: [sage-devel] imag(CC(infinity)) is 0?

Hello, from the perspective of the Riemann sphere it's a bit odd since > CC(infinity,0), CC(0, infinity) and CC(infinity, infinity) are all distinct > in sage, giving us 3 different complex infinities. > Here is another case of unexpected behaviour: sage: CC(I)+CC(Infinity)==CC(2*I)+CC(Infini

[sage-devel] Re: Trac editor sucks

Hello, Or more precisely, I find it extremely annoying that *while* I'm typing > the browser suddenly jumps to a totally unrelated location of the page, > so that I have to choose between typing blindly and "scroll back to the > text window for a few seconds until it jumps off again". > I have

Re: [sage-devel] imag(CC(infinity)) is 0?

Hello, > The implementation of RR and CC in Sage are a very direct wrapping of > > MPFR, which is the most well-thought out efficient implementation of > > floating point real numbers I've ever seen. It is worth visiting > > http://www.mpfr.org/mpfr-current/mpfr.html and searching for > > "in

Re: [sage-devel] imag(CC(infinity)) is 0?

Hi Marco, I read that comment, but it looks like the coercion framework does what it > should. RR(oo) == oo is evaluated by coercion to InfinityRing, where > positive infinity equals positive infinity: > > sage: oo > +Infinity > sage: oo.parent() is InfinityRing > True > sage: InfinityRing.has_c

Re: [sage-devel] imag(CC(infinity)) is 0?

Hi Nils, In my experience it often seems like it often seems desirable to have a > "field" R that tries to behave a little closer to being a field, but upon > closer inspection, the nasty implementation details of floating point > numbers will require for any somewhat serious application a spec

Re: [sage-devel] imag(CC(infinity)) is 0?

Hi Marco, - making the "in" keyword treat infinity as a special case. >> > > Either Sage's RR has an infinity element or it does not. And in this case > the coercion framework correctly recognizes this and gives the output > accordingly. > I think it is more subtle than that. The current RR do

Re: [sage-devel] imag(CC(infinity)) is 0?

Hello, > So it seems that sage.categories.pushout.pushout(Zmod(m), Zmod(n)) is > > Zmod(gcd(m,n)) unless m and n are coprime, in which case it raises an > error. > > > > This looks like a rather inconsistent choice to me. > > I agree, and anyone who knows enough to ever type "pushout" will >

Re: [sage-devel] imag(CC(infinity)) is 0?

> 2) to evaluate "a in B": if A is the parent of a, and P is the push-out of > A and B, then "a in B" yields True if and only if the following hold: > -- a can be converted into an element of B, say b = B(a); > -- the images of a, b in P are equal *and* B maps injectively into P > (similar to r

Re: [sage-devel] imag(CC(infinity)) is 0?

> I may be misunderstanding where you're going with this, but are you > proposing that > > sage: Mod(1,5) == 1 > False # your proposal? -- since ZZ-->GF(5) is not injective > No, my criterion is that *at least one* of the maps from the two rings to the push-out is injective. Here it is t

[sage-devel] Re: Fp algebraic closure and eigenvalues of matrices

Hello, > I would like to fix .eigenvalues() for matrices in order to work over > finite fields. Currently > {{{ > sage: K = GF(3) > sage: m = MatrixSpace(K,5).random_element() > sage: m.eigenvalues() > Traceback: most recent call (last) > ... > NotImplementedError: eigenvalues() is not implemented

[sage-devel] Re: Conversions without mathematical sense between polynomial rings

Jean-Pierre Flori wrote: > Currently one can obtain surprising results in Sage when converting > polynomial over finite fields (or elements of quotient rings of univariate > polynomial ring even though tht's not the primary concern of the ticket). > See http://trac.sagemath.org/ticket/11239 >

[sage-devel] Re: Conversions without mathematical sense between polynomial rings

Hi Simon, Warning: I am partially playing "advocatus diavoli" here. > That can be very useful! > > so let me just say here that I think this > > principle (that conversions need not be canonical) shouldn't be pushed > > further than reasonable. > > Yes, but for a rather relaxed notion of "

Re: [sage-devel] Re: Conversions without mathematical sense between polynomial rings

Hello John, What I don't like is this: > > sage: GF(7)(ZZ(GF(11)(7))) > 0 > > where the convenient lifting function from GF(p) to ZZ is done > automatically instead of via the functions lift() and centerlift() > It is even possible to completely obscure the fact that this conversion is done

[sage-devel] Re: Conversions without mathematical sense between polynomial rings

Hi Simon, > I'd say this is (close to) a bug. > It is a bug, without qualification. > So, we should think of being more precise, introduce "Set of partial maps > from > R to S", and use it as parents of partial maps that aren't maps. > Similarly, one should more consistently distinguish b

[sage-devel] Re: Conversions without mathematical sense between polynomial rings

New ticket: #15618 (convert_map should not be a map) I also found another bug: sage: A=Set([]) sage: A.convert_map_from(ZZ) ... RuntimeError: BUG in coercion model, no element constructor for -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To u

[sage-devel] Re: Conversions without mathematical sense between polynomial rings

Hi Nils, > Given how few properties a "conversion map" is actually guaranteed to > have, wouldn't it be sufficient to just have a callable represent the > conversion and not demand it's a map? > This sounds like a good idea if conversion remain the low-level things it is (i.e. possibly with

Re: [sage-devel] Re: Precision problems in taking determinant?

> > Would it be proper to autoconvert matrices over RR to RDF in case of the > default precision, so that the more stable numerical algorithms from RDF > can be used? I had proposed one such change in #13660 ( > http://trac.sagemath.org/13660 ) in case of eigenvalue/eigenvector > computations.

Re: [sage-devel] polynomials are power series?

Hi Ralf, I understand precision as being independent from element properties (as it > is in Pari). > In Sage, there are two kinds of precision: the precision of an individual element and the default precision of the power series ring. The same power series ring can contain elements that are r

Re: [sage-devel] Re: polynomials are power series?

Hi Travis, so it looks like the 0*O(x^20) is just suppressed from the output in the > (formal) power series ring. > If you mean that this is suppressed when printing FPS(f): no, actually FPS(f) has infinite precision, even though its parent FPS has a finite default precision. Only when comput

Re: [sage-devel] Re: Precision problems in taking determinant?

Hi Dima, Is the default choice of the algorithm the right one? > One can see that > sage: A.determinant(algorithm="hessenberg") > 16801.7979988558 > is quite good... > The PARI documentation of the function charpoly() says: "If flag=2, uses the Hessenberg form. Assumes that the base ring is a

[sage-devel] Re: Sage/Gp interface space efficiency issue

Hello, This looks very much like a bug I fixed recently (Trac ticket #15446). Could you check if the bug still exists in the latest development version? Peter I'm trying to find asymptotic bounds for the number of polynomials of > degree $n$ and height $\leq N$ with a specific Galois group

[sage-devel] Re: Sage/Gp interface space efficiency issue

Hello, The problem still occurs in version 6.2.beta1 (the version currently > running in SMC). Unfortunately, I am not able to access a machine > with/download to my current machine the most current development branch (I > believe its at 6.2.beta5 right now). Sorry I can't be of more help at th

[sage-devel] Sage 6.2.beta5: matplotlib fails to build due to a freetype header not being found

Hello, After the matplotlib upgrade (#14993), typing 'make' fails with the following error message (see attachment for the full matplotlib build log). ... building 'matplotlib.ft2font' extension creating build/temp.linux-x86_64-2.7 creating build/temp.linux-x86_64-2.7/src creating build/temp.li

[sage-devel] Re: Make fails after upgrading to 6.2.beta5

Hello John, The matplotlib problem is #16002. Peter Op woensdag 26 maart 2014 11:44:28 UTC schreef John Cremona: > > Just when I thought that I had got the hang of git-based development, > sincething fails which makes me realise that I have no idea what is > happening... > > After upgrading

[sage-devel] Re: who runs patchbot debian/.../selmer?

That is me. I just discovered that out of the most 10 recent patchbot build failures, 6 are caused by failing to install setuptools (on different machines). I was just about to write a post about this, but thanks for the notification anyway. Peter Op woensdag 7 mei 2014 10:30:10 UTC+1 schre

[sage-devel] Re: setuptools install problem

To try this one has to apply #16300 and then run patchbot with the resulting branch as the base branch, is that correct? Op woensdag 7 mei 2014 10:05:32 UTC+1 schreef Ralf Stephan: > > http://trac.sagemath.org/ticket/16300 > > People running patchbot with errors on setuptools install please try

Re: [sage-devel] Re: setuptools install problem

ms, maybe also sage -f setuptools, and then use that as base. > I had no problems in two runs after that but more data is needed. > > This goes back as far as the first commit after 6.1.1 > On 7 May 2014 12:04, "Peter Bruin" > wrote: > >> To try this one ha

Re: [sage-devel] Re: setuptools install problem

> > Oh yes you're right. Making it the base branch is necessary too. > Something that worked for me is making the changes without committing them; then the patchbot won't undo those changes. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To uns

Re: [sage-devel] Re: setuptools install problem

OK, I see, this has now happened to my patchbot on #15316. Op woensdag 7 mei 2014 17:18:17 UTC+1 schreef Ralf Stephan: > > On Wed, May 7, 2014 at 5:08 PM, Peter Bruin > > wrote: > >> Oh yes you're right. Making it the base branch is necessary too. >>> >&g

[sage-devel] Testing the pickle jar more thoroughly (many objects in it are broken after unpickling)

Hello sage-dev, While working on something else, I found out that although there is a doctest that unpickles all objects in the pickle jar, it does not do any kind of sanity check on the resulting objects. This means that unpickling many of these objects has become completely broken over time.

[sage-devel] Re: Testing the pickle jar more thoroughly (many objects in it are broken after unpickling)

Hi Volker, > On Friday, May 9, 2014 5:57:09 PM UTC+2, Peter Bruin wrote: >> >> I just opened a ticket <http://trac.sagemath.org/ticket/16311>, but I >> thought I'd also send a message to sage-devel to advertise the fact that we >> can't rely on tha

[sage-devel] Re: Unpickling dictionaries with unhashable keys

Here is my solution to a similar problem in #15158: def __setstate__(self, state): """ Needed to unpickle old Spec objects. The name-mangled attribute ``__R`` used to be in a class called ``Spec``; we have to translate this mangled name. TESTS:: sage: S = Spec(QQ) sage: loads(dumps(S)) Spectrum

Re: [sage-devel] Re: Unpickling dictionaries with unhashable keys

unhashable are silently dropped. Do we have to create special hashable subclasses of previously-hashable-but-now-unhashable types? Peter Op dinsdag 13 mei 2014 12:46:56 UTC+1 schreef Julian Rüth: > > Thanks for your answers. > > * Peter Bruin > [2014-05-13 01:23:56 > -0700]: >

[sage-devel] Re: setuptools install problem

I started a patchbot based on 6.3.beta1, and the problem has unfortunately popped up again with the new setuptools version: http://patchbot.sagemath.org/log/16348/debian/wheezy/sid/x86_64/3.2.0-57-generic/selmer/2014-05-13%2019:57:47%20+0100 Op woensdag 7 mei 2014 10:05:32 UTC+1 schreef Ralf St

[sage-devel] Re: setuptools install problem

>> that the setuptools problem can be postmortemed. I have stopped >> making pull requests at robertb/patchbot. >> >> https://github.com/rwst/patchbot >> >> Regards, >> >> On Tuesday, May 13, 2014 9:51:17 PM UTC+2, Peter Bruin wrote: >>> >&

[sage-devel] Re: [sage-release] Re: Sage 6.3.beta2 released

Hello, John Palmieri recently helped me with a ticket (#16350) where the > spkg-install > of a package was changed but that was not enough to trigger the necessary > rebuild. That could be accomplished by adding '.p0' to the > package-version.txt > because patch level changes don't change the ac

[sage-devel] Re: Modules(ZZ) vs CommutativeAdditiveGroups()

Hello, That's interesting, I asked myself exactly the same question in relation to . Something like this does work correctly for modules over a field: sage: Modules(QQ) Category of vector spaces over Rational Field I was wondering if it would be easy to

[sage-devel] Re: pari tries to allocat 256gb in is_square over a quadratic field

Hello John, This appears to be a bug in PARI's nffactor(). As you noted, PARI's factor() returns the factorisation instantaneously, and the same is true for factornf(). However, Sage does not call either of these functions, but nffactor(). Normally nffactor(nfinit(g), f) should be practically e

[sage-devel] Re: FiniteDimensionalAlgebra does not check associative

Hello, > I want to use FiniteDimensionalAlgebra to check if a given table of > multiplicayion can form a associative algebra. But the function > FiniteDimensionalAlgebra do not check for association. A FiniteDimensionalAlgebra can be very general: any finite-dimensional vector space A equipped wi

[sage-devel] Re: flint revert_series

Hi Jonas, >> Another idea (perhaps for a separate update) would be to add a sage >> implementation of flint's algorithm for reversion over generic base >> ring. This is Algorithm 1: "Fast Lagrange inversion" in >> http://www.ams.org/journals/mcom/-000-00/S0025-5718-2014-02857-3/ >> (if you can

[sage-devel] Re: Difficulties with resultant

Hi Bill, This bug was only fixed two weeks ago (Trac tickets #15061 and #16360), so it only works in the most recent beta versions of Sage. The reason why PARI gives the wrong answer has to do with variable ordering; for example, f is translated to f = Mod(-3*y^2*x^2 + (-y^2 - 3*y + 1)*x - 2, x^

[sage-devel] Re: Equality, hashing and polynomial rings

Hi Jean-Pierre, I'm currently wrapping FLINT fq modules into new Sage classes for finite > fiels and got strange coercion errors when running non trivial code. > Indeed, the polynomial ring constructors use a dictionary and so relies on > the hash of finite fields (the parents). > By some chance

[sage-devel] Re: Equality, hashing and polynomial rings

Hi Jean-Pierre, > I'm not sure I understand correctly; do you mean that the problem is > caused by fields comparing equal even if the implementations are > different? I think we should in any > > Not sure. > I seem to be able to produce things with different hashes but equal... > sage: GF(1

[sage-devel] Re: Equality, hashing and polynomial rings

Hi Simon, >> I'm not sure I understand correctly; do you mean that the problem is >> caused by fields comparing equal even if the implementations are >> different? I think we should in any case make FiniteField inherit >> from WithEqualityById, so two instances compare equal if and only if >> the

[sage-devel] Re: RuntimeError: ECL says: Module error: Don't know how to REQUIRE MAXIMA.

Bonjour Sébastien, > I get the below regression with 6.3 (compare to 6.3.beta3). Strange > error no? This kind of error can happen when ECL is upgraded but Maxima is not reinstalled. In that case, "sage -f maxima" will probably solve it. Peter -- You received this message because you are subs

[sage-devel] Re: issues with pushout construction?

Hi Jonas, > When I implemented Modular forms rings/spaces for Hecke triangle groups > I ran into some issues with pushout / functors / constructions > (correct me if I missunderstood something): > > Apparently the pushout construction implicitely assumes that > there exists a coercion from the "co

[sage-devel] Re: help tracking bug with polynomials over finite fields

Hello Vincent, You are probably right that it is the PARI -> Sage conversion that is causing the bug. I added the following debugging statements: diff --git a/src/sage/rings/polynomial/polynomial_element.pyx b/src/sage/rings/polynomial/polynomial_element.pyx index 4fe2d5c..b0676d7 100644 --- a/

[sage-devel] Re: issues with pushout construction?

Hi Simon, >> - A = some graded ring, B = some homogeneous component of A >>Adding elements of A and B should give an element of A > > Here you have a coercion from B to A, and thus no construction functor > or pushout construction is involved. At least in the general setting of submodules and

[sage-devel] Re: issues with pushout construction?

Hi Jonas, > What if there is no coercion in either direction? > E.g. (base_ring, cusp forms ring) Maybe #16507 would make this work too if the CuspForms construction were implemented as a composition: ModularForms followed by CuspidalSubspace, where CuspidalSubspace would be a special case of Sub

[sage-devel] Re: issues with pushout construction?

Hi Jonas, > I just realized that my example was maybe a bad one. But imagine the > same example for a space where the base ring _does_ coerce into the > space. A base-changed base ring would then not coerce, so the pushout > construction would be used and it would return the wrong space, > resp.

[sage-devel] Re: issues with pushout construction?

Hi Jonas, >>> I just realized that my example was maybe a bad one. But imagine >>> the same example for a space where the base ring _does_ coerce into >>> the space. A base-changed base ring would then not coerce, so the >>> pushout construction would be used and it would return the wrong >>> spa

[sage-devel] Re: Power series normalisation

Hi Bill, > Fredrik and I found the following in Sage 6.3. > sage: R. = PowerSeriesRing(ZZ) > sage: S. = PowerSeriesRing(R) > sage: x + O(x^4) + y + O(y^4) > x + O(x^4) + y + O(y^4) > sage: y + O(y^4) + x + O(x^4) > x + y + O(y^4) > I guess this comes from Pari defining: > 0 == O(x^4) > to be true.

[sage-devel] Re: Change in simplification of combined abs & sqrt in Sage 6.3

Hello, > I've noticed the following change in simplifications between Sage 6.3 and > preceeding versions: > > In Sage 6.2 (and preceeding): > > sage: simplify( abs(sqrt(x)) ) > sqrt(x) > sage: simplify( abs(1/sqrt(x)) ) > 1/sqrt(x) > while in Sage 6.3: > > sage: simplify( abs(sqrt(x)) ) > sqrt(

[sage-devel] Re: Change in simplification of combined abs & sqrt in Sage 6.3

Hello, > PS: in the above code, I've simply cut and paste lines from > Expression._maxima_(). In the present case, the super is not necessary > and the code can be simplified to > > In Sage 6.2: > > sage: from sage.calculus.calculus import maxima > sage: abs(1/sqrt(x))._interface_(maxima) > 1/sqr

[sage-devel] Re: Change in simplification of combined abs & sqrt in Sage 6.3

PS: the following message from the Maxima mailing list (found via a different sqrt-related report in the Maxima bug tracker) is quite useful: https://www.ma.utexas.edu/pipermail/maxima/2011/025213.html >From that page: * abs is a mathematical function which has simplification rules. It assumes

[sage-devel] Re: Deprecations for changed behaviour

Hello, William Stein wrote: > I pasted my docstring in from "Sage Version 6.2.rc2, Release Date: > 2014-05-04", but with sage-6.3 the "This always returns 1." appears. > So this docstring was *just* changed a month ago (by [1]). > > If it said "This always returns 1." for a long time, that would

[sage-devel] Re: Diverging PARI from upstream (#16997)

Hi Jeroen and sage-devel, The upstream situation with PARI has always been somewhat difficult. The > don't easily accept patches written by people which are not in their > inner circle. That, plus the importance of PARI inside Sage, is probably > also one of the reasons that PARI in Sage has so

[sage-devel] Re: Diverging PARI from upstream (#16997)

Hi Volker, If upstream keeps refusing additions like ispseudoprimepower then we could > collect them into a separate shared library that we install separately, but > its not worth the effort right now. > I don't think there is a possibility of this happening. To avoid the impression that it i

[sage-devel] Re: Diverging PARI from upstream (#16997)

Op vrijdag 26 september 2014 11:58:44 UTC+2 schreef Volker Braun: > > On Friday, September 26, 2014 10:46:08 AM UTC+1, Peter Bruin wrote: > >> To be honest, I tend to agree with this argument. Once you start >> defining arithmetic with infinity, you are asking for trouble be

Re: [sage-devel] Re: Diverging PARI from upstream (#16997)

Op vrijdag 26 september 2014 13:40:36 UTC+2 schreef Jeroen Demeyer: > > On 2014-09-26 13:18, Peter Bruin wrote: > > It is completely sensible for valuation(0) > > to result in an error (or a "useless" infinity return value) > Raising an error and returning a &qu

Re: [sage-devel] Re: Diverging PARI from upstream (#16997)

Op vrijdag 26 september 2014 13:58:06 UTC+2 schreef Travis Scrimshaw: > > > On 2014-09-26 11:46, Peter Bruin wrote: >> > Why write a new function for something >> > that doesn't seem to be _that_ widely useful, and can easily be >> > implemented in two l

[sage-devel] Re: Group of units in Z_n

Hello, After more than 5 years, there is now a ticket implementing a unit_group() method for IntegerModRing: http://trac.sagemath.org/ticket/17317 (needs review). Peter Op zaterdag 19 september 2009 05:14:57 UTC+2 schreef Rob Beezer: > > Sage-Devel, > > I've got it in my head to implement th

[sage-devel] Re: When/by who/how was the "code of conduct" initiated ?

Lectoribus salutem! Emmanuel Charpentier scripsit: Alternative : make the majestuous Latin of Leonard Euler the lingua franca > of sage- lists/groups. That would give us the added benefit of having > grammatically well-built posts much more frequently... > Haec propositio approbationem meam h

[sage-devel] Re: When/by who/how was the "code of conduct" initiated ?

die XXVII mensis Novembris anni MMDCCLXVII ab urbe condita Emmanuel Charpentier scripsit: 7 Frimaire an 223 de la Révolution die, scribit Volker Braun : >> >> On Thursday, November 27, 2014 7:20:42 PM UTC, Emmanuel Charpentier wrote: >>> >>> Alternative : make the majestuous Latin of Leonard Eule

Re: [sage-devel] abs(matrix)

Hello, > >> abs(matrix) is currently returning the determinant (and this goes back > >> to the early implementation in 2006!). If anybody contests the fact > >> that it should return the matrix whose entries are the absolute value > >> of the initial matrix, please tell me. > > > > I don't

[sage-devel] Re: Finite fields coercion bug

Hello John, > I think this is a bug. In one Sage session: > > sage: F4 = GF(4) > sage: F16 = GF(16) > sage: F4.gen() in F16 > True > sage: F16.has_coerce_map_from(F4) > True > > -- all is well. But in a new session: > > sage: F4 = GF(4, names='a') > sage: F16 = GF(16, names='b') > sage: F4.gen()

[sage-devel] Re: Finite fields coercion bug

Hello, Kwankyu Lee wrote: > On Thursday, October 13, 2016 at 9:59:50 PM UTC+2, David Roe wrote: > > In order to create finite fields with arbitrary variable names that fit > into a lattice of fields, one possibility would be able to give an > algebraic closure explicitly as an argument to G

[sage-devel] Re: bug report: error when computing cardinality of point sets

Hello, Ursula Whitcher wrote: > Asking Sage to compute the cardinality of point sets of projective > varieties over finite fields produces an infinite recursion error. > This is weird, since the count_points() function works just fine > (albeit slowly) in this situation. This is very likely the

[sage-devel] Re: Suggestion for GSoC project: Polynomials - Rewriting and relinking

Hello, Johan S. H. Rosenkilde wrote: > Our current polynomial implementation has severe issues: > > - Our speed for GF(2^e)[x] is abysmal. > > - For other cases we are probably not linking to the currently fastest > libraries. > > - We don't have multi-point evaluation or fast Lagrange interpo

[sage-devel] Re: Running 'make' twice triggers a gcc rebuild

Hello, John H Palmieri wrote: > Anyone seen this? On one OS X machine, with two different > installations of Sage 6.9.rc0 (one built by upgrading earlier > versions, one built from a fresh tarball), if I do this: > > $ make distclean > $ make > $ make > > then the second time, although it should

[sage-devel] Re: bug in pari interface for roots over finite fields

Hello, > In sage 7.2 and 7.3, the sequence of commands below produces an error in > sage. A It looks like it is calling pari for the computation. A Doing the > analogous commands directly in pari works, so the error is in sage dealing > with the pari output (assuming some integer has to be small).

[sage-devel] Re: Building Maxima spkg fails

The build failure should be fixed by http://trac.sagemath.org/ticket/17525 Peter Op vrijdag 19 december 2014 12:54:37 UTC+1 schreef Simon King: > > Hi! > > With the latest develop, "make start" fails to build maxima. The log is > at > http://sage.math.washington.edu/home/SimonKing/logs/maxima

[sage-devel] Re: Building Maxima spkg fails

Hi Simon, Sigh. Even after installing automake 1.13.4, the maxima spkg refuses to > build. However, sage still starts. > Yes, one annoying thing is that you specifically need Automake 1.11. Peter -- You received this message because you are subscribed to the Google Groups "sage-devel" gro

Re: [sage-devel] GF(3) but GF(9,'x')

Hello, My argument against making the 'name' argument for FiniteField optional was that it hides the fact that the generator of a finite field is not canonical. On the other hand, once an algebraic closure of GF(p) has been fixed, there is a unique subfield of p^n elements for every n. Hence

[sage-devel] Re: GF(3) but GF(9,'x')

Just to clarify, typing GF(p, n) would not insert the name 'z' + str(n) into the global namespace, it would just mean that elements are printed using this variable name. One would still have to do something like sage: F, z5 = GF(3, 5).objgen() to be able to use z5 on the command line. Peter

Re: [sage-devel] GF(3) but GF(9,'x')

I just created two tickets for this: http://trac.sagemath.org/ticket/17568 (Allow syntax FiniteField(p, n)) http://trac.sagemath.org/ticket/17569 (Allow creating finite fields without a variable name) Peter Op dinsdag 30 december 2014 11:12:32 UTC+1 schreef Peter Bruin: > > Hello,

Re: Fwd: [sage-devel] trivial Artin symbols

Hi Djordjo, It turns out that in your example the decomposition group is represented internally as a permutation group on the wrong number of elements. I am now testing a fix; see http://trac.sagemath.org/ticket/17664 . Peter > -- Forwarded message -- > From: Djordjo Milovic >

  1   2   >