[sage-devel] COUNT (COmputations and their Uses in Number Theory) - CIRM, 27 Feb-3 Mar

; the deadline for the pre-registration is December 1st. Best regards, and looking forward to seeing you at COUNT, Peter Bruin (on behalf the organising committee) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this grou

[sage-devel] Re: Adèles and idèles

Dear Mathé, >From what I've seen, this is very high quality code, and in my opinion Part 1 is certainly useful enough to be included into SageMath. As other people have already mentioned, there are two possibilities: 1) try to get the code for adèles and idèles into SageMath itself; 2)

[sage-devel] Ticket #32250: definition of (magmatic) algebras

On https://trac.sagemath.org/ticket/32250 I propose a precise definition of (magmatic) algebras, since this is currently missing. This could help "systematizing" the implementation of algebras in the category hierarchy. Comments are welcome! Peter -- You received this message because you

[sage-devel] Re: lcalc.analytic_rank fails

Hi Barinder, On my system I get the same error messages as you (but no segmentation fault). This looks like a bug in PARI. It also happens with the built-in ellanalyticrank function in PARI: gp> A = -17737878703644595885728157881856/2195118875780412735240966796875; gp> B =

[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

[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.

[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

[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:

[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

[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

[sage-devel] Re: Catalog of algebras: the definition of an algebra

Hello, Travis Scrimshaw wrote: On #15635, we are trying to decide whether we want non-associative algebras to be included in the catalog of algebras. For a general mathematical software system such as Sage, I think it is overly restrictive to impose the rule that algebras are associative.

[sage-devel] Re: On MacDonald polynomials and pickling

Hello, There are indeed tons of problems with old pickles; see also http://trac.sagemath.org/ticket/16311 where I simply tried to get the string representation of all pickles in the jar. Peter The pickle jar is about old pickles, to test that they can be unpickled. So the pickles were

[sage-devel] Re: Fastest way to multiply vector with matrix?

Hi Simon, I have vectors (say, nx1 matrices) over finite fields, and I have nxn matrices, by which I want ot multiply the vectors. If I am taking the default matrix implementations for fields GF(2), GF(4), GF(5) and GF(25), the timings are considerably worse than when taking my age-old

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

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, My argument

[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

[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 group.

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 think that it

[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

[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 Euler the

[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 the

[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 is

[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 because there isn't one set

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 useless infinity value are *very* different

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 lines (ispower() followed by ispseudoprime

[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 be

[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(x) sage:

[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/sqrt(x)

[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: 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

[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 ---

[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

[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. my

[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. my

[sage-devel] Re: Power series normalisation

Hi Bill, Fredrik and I found the following in Sage 6.3. sage: R.x = PowerSeriesRing(ZZ) sage: S.y = 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

[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(13**5,

[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 they are

[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

[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,

[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't access

[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 with

[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

[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 actual

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

Hello, That's interesting, I asked myself exactly the same question in relation to http://trac.sagemath.org/ticket/16402. 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: setuptools install problem

Regards, On Tuesday, May 13, 2014 9:51:17 PM UTC+2, Peter Bruin wrote: 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

[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

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 pjb...@gmail.com javascript: [2014-05-13 01:23:56 -0700]: Here is my

[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

[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

[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 that doctest to ensure backwards compatibility of our

[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

[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

-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 pjb...@gmail.com javascript: wrote: To try this one has to apply #16300 and then run patchbot

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

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 pjb...@gmail.comjavascript: wrote: Oh yes you're right. Making it the base branch is necessary too. Something that worked

[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 to

[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 the

[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

[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

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

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

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 field.

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.

[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 without

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 by

[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 between

[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 class 'sage.sets.set.Set_object_enumerated_with_category' -- You received this message because you

[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 reasonable.

[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 for

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 special

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 does have

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 certainly

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 rule 1

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 the map

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 infinity.

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:

[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 the

[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 complex

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 since

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 object lives),

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 in

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:

[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,

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 getattr rather than

[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 quickdirty 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 about

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 that means there

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,

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 simply

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):

[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

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()? Currently

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

  1   2   >