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

[Peter Bruin]

Dear all,
We are very pleased to announce the conference COUNT, COmputations and 
their Uses in Number Theory, that will take place at CIRM, France, February 
27th - March 3rd:

https://conferences.cirm-math.fr/2805.html
The conference will be devoted to explicit and computational methods in 
number theory and arithmetic geometry in a broad sense. The format will 
include scientific talks as well as time for informal collaboration and for 
coding projects related to PARI/GP, SageMath, Magma, OSCAR or the 
L-Functions and Modular Forms Database.

Some support funding is available; 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 group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4951d091-ea55-44e7-944b-271705bd94a6n%40googlegroups.com.

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

[Peter Bruin]

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) continue maintaining it as an individual package and make it as easy as 
possible to install (which probably means via pip).

The thing that makes it slightly harder to decide which is better is the 
current effort to "modularise" the SageMath library, see 
.  The goal is to break the library 
up into several (pip-installable) packages, but to keep the existing 
SageMath source tree.  On the one hand, this is no obstacle to including 
the package (at least for Part 1) in the main SageMath source; on the other 
hand, if SageMath will become piecewise pip-installable in the future, then 
presumably people will also become more used to install packages (like 
yours) via pip.  I guess it is up to you, as the author, to choose whether 
to go for 1) or 2).

Best wishes,

Peter
Op vrijdag 13 augustus 2021 om 12:07:25 UTC+2 schreef m.c.h...@gmail.com:

> Hello everyone,
>
> As a master's mathematics student I (allmost) finished my thesis, for 
> which I implemented adèles and idèles in SageMath. I have written the code 
> with the aim of including it into SageMath. It is well documented, 
> following the SageMath guidelines, and personally I think the package fits 
> well into SageMath.
>
> The package can be found at GitHub: https://github.com/mathehertogh/adeles
> .
> You can find all information on it there (as well as the thesis which it 
> is based on).
> Installing should be easy (if not: let me know!). I invite anyone 
> interested to do this and discover the functionality by reading the 
> documentation and experiment with the code in SageMath.
>
> The README file and documentation index explain the four parts the package 
> consists of:
> Part 1 - Implementation of adèles and idèles
> Part 2 - Profinite functions and graphs
> Part 3 - Adèlic matrix factorization
> Part 4 - Hilbert class field computations
>
> I would suggest to include Part 1 into SageMath. Moreover I think Part 2 
> would be nice to include into SageMath as well. Parts 3 and 4 are very 
> specialized and probably do not belong into the SageMath standard library 
> (but if you disagree: let me know).
>
> My main two questions for you are:
> 1. Do you agree on adding Part 1 to SageMath? (assuming the code is good)
> 2. Do you think adding Part 2 is a good idea? (assuming  the code is good)
>
> Given at least one affirmative answer, the code should be uploaded to trac 
> and reviewed. As it is quite some code, my plan would be to create a 
> separate trac-ticket for each file of Part(s) 1 and/or 2. So one file would 
> be reviewed per trac-ticket. Do you think this is a good idea?
>
> This would require (I think) trac-tickets that depend on each other. I see 
> a "dependencies" field when creating a new trac-ticket, so I guess this is 
> possible. Any advice, tips or references on this would be appreciated. Also 
> any suggestions regarding the inclusion of my code into SageMath in general 
> would be much appreciated: this is my first contribution.
>
> I am very interested in what you all have to say about this project and 
> the questions asked above.
>
> Kind regards,
> Mathé Hertogh
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/bd17d897-b45c-491e-b669-31b03d936823n%40googlegroups.com.

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

[Peter Bruin]

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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f00b9d84-2c4b-4984-a7aa-ab1208e8d5c8n%40googlegroups.com.

[sage-devel] Re: lcalc.analytic_rank fails

[Peter Bruin]

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 = 
76386743039924534000525642916220282669332545616695170155741184/4818546878807463076444691815463494370294881403446197509765625;
gp> E = ellinit([A, B]);
gp> ellanalyticrank(E)
  ***   at top-level: ellanalyticrank(E)
  *** ^--
  *** ellanalyticrank: overflow in t_INT-->ulong assignment.

Do you want to file a PARI bug report?

Best wishes,

Peter


Op woensdag 18 maart 2020 13:36:46 UTC+1 schreef Barinder Banwait:
>
> MWE:
>
> sage: A = -17737878703644595885728157881856/2195118875780412735240966796875
> sage: B = 
> 76386743039924534000525642916220282669332545616695170155741184/4818546878807463076444691815463494370294881403446197509765625
> sage: E = EllipticCurve([A,B])
> sage: lcalc.analytic_rank(E)
>
> This produces "***   overflow in t_INT-->t_INT assignment.Segmentation 
> fault (core dumped), followed by "TypeError: unable to convert '' to an 
> integer". It looks like line 385 of sage/lfunctions/lcalc.py is returning 
> the empty string, i.e., 'rank-compute' is failing to compute, probably 
> because of the overflow.
>
> This elliptic curve comes from Elkies and Klagsbrun's recent paper (
> https://arxiv.org/abs/2003.00077); it is the rank 20 curve with torsion 
> Z/2Z.
>
> Other info:
>
> OS: Ubuntu 18.04.2 LTS, 64bit
> Sage installation: Downloaded and unzipped the top link here: 
> http://www.mirrorservice.org/sites/www.sagemath.org/linux/64bit/index.html
> SageMath version 9.0, release date 2020-01-01
> Using Python 3.7.3
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/fb89324a-91a6-4eea-ab06-be5c9d7b7140%40googlegroups.com.

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

[Peter Bruin]

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 interpolation,
>   even though the libraries we link to often have this.
>
> - Bruno Grenet remarked at SD75 that there were issues and lots of
>   crufted code in the class structure handling generic/specific and
>   dense/sparse/etc. polynomials.
>
> - Jeroen Demeyer remarked that the Cython code is from the prehistoric
>   era and has lots of cruft from back when Cython was a lot more
>   primitive than it is now.
>
> - add more things yourself.
>
> Considering how central polynomial arithmetic is in many parts of
> algebra, I think this is bad, and it impedes gradual improvement (e.g. I
> am at a loss on how to improve the GF(2^e)[x] thing which is my personal
> main itch).
>
> I would be interested in co-mentoring such a GSoC project for improving
> this. But I lack understanding of, especially Cython and linking. I
> would like to know if someone else would be a co-mentor with me on this,
> or technical advisor on e.g. Cython issues.

It would indeed be a big step forward to improve polynomial arithmetic.
A long time ago I wrote an implementation of power series using PARI:
https://trac.sagemath.org/ticket/15601
This is not merged yet, but could be useful to get an impression of the
sort and amount of work to be done for new polynomial implementations
(although the interfaces of e.g. NTL and FLINT are of course different).
Unfortunately I personally won't have a lot of free time to help with a
GSoC project...

Peter

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 bug reported at
.

Peter


> Here's an example.
> Entering:
> F = FiniteField(37)
> P3. = ProjectiveSpace(3,F)
> P3.point_set().cardinality()
> yields an error that begins:
> Error in lines 3-3 Traceback (most recent call last): File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/smc_sagews/sage_server.py",
> line 976, in execute exec compile(block+'\n', '', 'single') in namespace,
> locals File "", line 1, in  File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in cardinality return sum(ZZ.one() for point in self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in  return sum(ZZ.one() for point in self) File
> "sage/structure/parent.pyx", line 1596, in
> sage.structure.parent.Parent.__getitem__
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913)
> return self.list()[n] File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 602, in list return tuple(self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in cardinality return sum(ZZ.one() for point in self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in  return sum(ZZ.one() for point in self) File
> "sage/structure/parent.pyx", line 1596, in
> sage.structure.parent.Parent.__getitem__
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913)
> return self.list()[n]
> continues looping for a while, and ends:
> File "sage/structure/parent.pyx", line 1596, in
> sage.structure.parent.Parent.__getitem__
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913)
> return self.list()[n] File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 602, in list return tuple(self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in cardinality return sum(ZZ.one() for point in self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in  return sum(ZZ.one() for point in self) File
> "sage/structure/parent.pyx", line 1590, in
> sage.structure.parent.Parent.__getitem__
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12742)
> meth = getattr_from_other_class(self, self._category.parent_class,
> '__getitem__') File "sage/structure/misc.pyx", line 250, in
> sage.structure.misc.getattr_from_other_class
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/misc.c:1731)
> if isinstance(self, cls): RuntimeError: maximum recursion depth exceeded
> while calling a Python object
> On the other hand,
> P3.count_points(1)
> returns [52060].
> --Ursula.
>
> --
> 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@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Finite fields coercion bug

[Peter Bruin]

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 GF.  Is that what you're
>   suggesting?
>   sage: F = GF(3).algebraic_closure('custom')
>   sage: K9 = GF(9,'b',Fpbar=F)
>   sage: K81 = GF(81,'c',Fpbar=F)
>   sage: K81.has_coerce_map_from(K9)
>   True
>
> This currently works 
> sage: K9 = GF(9,'b',prefix='custom')
> sage: K81 = GF(81,'c',prefix='custom')
> sage: K81.has_coerce_map_from(K9)
> True
> But the following betrays my expectation..
> sage: K=GF(3).algebraic_closure('custom')
> sage: K81.gen() in K
> False
> sage: K.has_coerce_map_from(K81)
> False

One reason why this doesn't work is that you gave the custom variable
names 'b' and 'c' to K9 and K81.  However, even when you omit this, it
doesn't work, which I think is a bug.

It is also possible to first construct the algebraic closure of F_p and
then construct other finite fields as subfields of this:

sage: K = GF(3).algebraic_closure('custom')
sage: K9, i9 = K.subfield(2)
sage: K.has_coerce_map_from(K9)
True

However, there is a similar problem here:

sage: K81, i81 = K.subfield(4)
sage: K81.has_coerce_map_from(K9)
False

This should return True.

Peter

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Finite fields coercion bug

[Peter Bruin]

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() in F16
> False
> sage: F16.has_coerce_map_from(F4)
> False
>
> Why should the fact that I have given non-default names to the
> generators (the default names are z2 and z4) stop the coercion being
> dicovered?

Creating finite fields without a variable name was implemented in
.  If you don't specify a
variable, then the field is created as a subfield of an algebraic
closure, and there are canonical inclusions between such fields.
Otherwise, the finite field does not have such a distinguished
embedding.

By the way, creating finite fields without a variable name is something
that you should only do for small fields, because constructing an
algebraic closure requires computing (pseudo-)Conway polynomials.

> Worse than that, I tried to create my own coercion from F4 to F16 in
> the second situation and it prevented me from doing so, saying there
> already was one, while at the same time telling me there was no
> coercion.  Inconsistent!

Even though there is no coercion map in this situation, simply trying to
discover a coercion "taints" the target parent by registering the fact
that there is no coercion.  It does work if you don't call
has_coerce_map() first:

sage: F4 = GF(4, names='a')
sage: F16 = GF(16, names='b')
sage: f = F4.Hom(F16)[0]
sage: F16.register_coercion(f)

You can't rely on this to work, though, because it can fail if F16 was
already created in this Sage session.

Peter

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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).
> John Jones
>
> p=13189065031705623239
>
> Fq = FiniteField(p ** 3, "a")A 
>
> Fq_X = PolynomialRing(Fq, "x")
>
> pol=Fq_X("x^9 + 13189065031705622723*x^7 + 13189065031705622723*x^6 +
> 9288*x^5 + 18576*x^4 + 13189065031705590731*x^3 + 13189065031705497851*x^2
> + 13189065031705497851*x + 13189065031705581443")
>
> pol.roots()

This is now https://trac.sagemath.org/ticket/21186; I found a solution
and will upload a patch soon.

Peter

-- 
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@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 do almost nothing, it
> rebuilds gcc.

Something similar happened to me on an x86_64 GNU/Linux machine where
the system version of GCC is 4.6.3.  When typing "make" a second time
after upgrading to 6.9.rc0, it started reinstalling GCC; I don't know
what caused this, but prevented the rebuilding by simply doing "touch
local/var/lib/sage/installed/gcc-4.9.2.p1".

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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.
There are too many interesting non-associative algebras (such as Lie
algebras), or non-unital algebras (such as certain Hecke algebras) to
make associativity part of the definition of an algebra.

Moreover, it is in my opinion an unfortunate choice of terminology if
non-associative algebras are not in general algebras.

 The argument against including them is most people think of algebras
 as being associative (and maybe even unital), and as such, might
 surprise people when they come across the non-associativity in their
 computations.

Anyone has the right to think of algebras as being associative, just
like many people think of vector spaces as being finite-dimensional,
say.  This is a bit like books or papers using the convention that all
the algebras that one considers are assumed to be associative (or that
vector spaces are assumed to be finite-dimensional, etc.)  However, it
feels wrong to elevate such conventions to definitions.

 However, the community was at one point considering renaming magmatic
 algebras into algebras and having to specify the associative axiom
 explicitly.

I would be in favour of this.

When finite-dimensional algebras over a field were implemented in
#12141, we explicitly included non-associative algebras.  In case the
user already knows that his algebra is associative, he can pass a flag
assume_associative (default: False) to avoid a lengthy computation to
check this.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 created with an old version of Sage. Its odd that we
 lost the ability to pickle them over time.

 On Monday, March 23, 2015 at 7:10:25 PM UTC+1, Snark wrote:

   Hi,

   I'm still trying to track why calling unpickle_all twice leads to a
   SIGABRT crash with our experimental debian package.

   After some toying around, it turned out that within the whole pickle
   jar, only the files related to MacDonald polynomials are giving issues.

   That is why I'm trying to experiment on them (within a vanilla sage),
   but I'm hitting a small problem : I don't even manage to dump them as
   pickle!

   Indeed, the following :

   import pickle

   t = QQ['t'].gen()
   obj = SymmetricFunctions(QQ['t'].fraction_field()).macdonald(q=t,t=1)

   with open('/tmp/mcdopols.sobj','w') as fich:
  pickle.dump(fich, obj)

   only triggers:
   AttributeError: 'Macdonald' object has no attribute 'write'

   So I'm wondering how they were put into the pickle jar ?

   Snark on #sagemath

 --
 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@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 wrapper for an age-old matrix implementation in
 C-MeatAxe (which is part of my group cohomology spkg).

Yes, linear algebra over finite fields in Sage is unacceptably slow...

 Asymptotically fast multiplication doesn't seem relevant here.

Indeed, the classical algorithm is the optimal way to multiply a matrix
by a vector.

 So I wonder: Is there perhaps some overhead killing the performance?

Absolutely; the fact that all finite field elements are wrapped in Sage
objects costs a lot of time.

 What would you recommend as the fastest way in Sage to multiply a
 vector with a matrix over small finite not necessarily prime fields?

I would recommend merging one of Jeroen's branches to upgrade to a more
recent PARI version (#16997 or #16939).  These PARI versions contain
improvements to linear algebra over finite fields that I made some time
ago.  Then given a matrix M and a vector v over a finite field, the
following will probably give a nice speedup over M * v:

sage: Mp = M._pari_()
sage: vp = v._pari_().mattranspose()
sage: Mp * vp

The PARI version that Jeroen's ticket currently uses does not yet
contain an even faster algorithm using Kronecker substitution; this was
only merged in the PARI Git repository a week ago.

It may be even faster (but much more work) to write classes for matrices
and vectors over finite fields using FLINT (see also #16664 for the
finite fields themselves).

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 dzm...@gmail.com
 Date: 23 January 2015 at 12:51
 Subject: [sage-devel] trivial Artin symbols
 To: sage-devel@googlegroups.com


 Hi all,

 Can someone explain why there is an error when I try to compute an
 Artin symbol which is supposed to be trivial? In the following
 example, I am computing Artin symbols of some odd primes in the
 quadratic extension of discriminant -4. The Artin symbols of primes
 $\equiv 3\bmod 4$ are computed correctly, while there is an error for
 every $p\equiv 1\bmod 4$.

 I know this is a simple example and I don't need Sage to compute it
 for me, but I am getting a similar error in a more complicated
 situation where I can't do computations by hand.

 Thanks!
 Djordjo

 Sage code:

 QI.ii = NumberField(x^2+1)
 L = QI.absolute_field('c')
 G = L.galois_group()
 print G
 print [G.artin_symbol(P) for P in L.primes_above(3)]
 print [G.artin_symbol(P) for P in L.primes_above(7)]
 print [G.artin_symbol(P) for P in L.primes_above(11)]
 print [G.artin_symbol(P) for P in L.primes_above(5)]

 Output:

 Galois group of Number Field in c with defining polynomial x^2 + 1
 [(1,2)]
 [(1,2)]
 [(1,2)]
 Traceback (click to the left of this block for traceback)
 ...
 sage.libs.pari.gen.PariError: incorrect permutation in permtopol


 --
 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@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 I 
would like to propose that if the user does not specify a name, then the 
constructor should return the unique subfield of the relevant degree inside 
the chosen algebraic closure.  In other words, for all n  1 we should have

GF(p, n) = GF(p^n) = GF(p).algebraic_closure().subfield(n)[0]

With this convention, an added benefit is that the distinguished generator 
of GF(p, n) is called 'z' + str(n), which is less likely to be confusing 
than just 'z'.  For example:

sage: GF(3).algebraic_closure().subfield(5)[0]
Finite Field in z5 of size 3^5

Peter


Op dinsdag 30 december 2014 10:49:15 UTC+1 schreef Jean-Pierre Flori:

 I would also be nice to be able to pass GF(3,3).
 If I ever find some time to implement it, I'll do it, but anyone can feel 
 free to do it before I do.


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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


Op dinsdag 30 december 2014 12:35:30 UTC+1 schreef Dima Pasechnik:

 On 2014-12-30, Nathann Cohen nathan...@gmail.com javascript: wrote: 
  I wondered about this syntax. You can build a finite field from a 
  prime number with GF(p), but if what you have is a prime power you 
  should write GF(q,'x') instead. 
  
  I very often need to create a lot of finite fields, but I could not 
  care less about this 'x' and so I type this even though I do not need 
  it. Would it make sense to you if we made this argument optional ? It 
  would be 'x' by default, or anything else that you would prefer. 

 I don't see how this would play out nicely if you, say, define 
 GF(27) and then define GF(9). 
 Would the latter definition invalidate the former? 

 In GAP this is solved by having a special indexed variable Z(p^k), for 
 p a prime and k a natural number. Then after defining GF(27) and 
 then defining GF(9) 
 you can still refer to the elements of the former as a*Z(27)^i, 
 for a and i integers. 

 If something similar can be done in Sage, OK. 
 Otherwise, -1. 

 Dima 



-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 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 I 
 would like to propose that if the user does not specify a name, then the 
 constructor should return the unique subfield of the relevant degree inside 
 the chosen algebraic closure.  In other words, for all n  1 we should have

 GF(p, n) = GF(p^n) = GF(p).algebraic_closure().subfield(n)[0]

 With this convention, an added benefit is that the distinguished generator 
 of GF(p, n) is called 'z' + str(n), which is less likely to be confusing 
 than just 'z'.  For example:

 sage: GF(3).algebraic_closure().subfield(5)[0]
 Finite Field in z5 of size 3^5

 Peter


 Op dinsdag 30 december 2014 10:49:15 UTC+1 schreef Jean-Pierre Flori:

 I would also be nice to be able to pass GF(3,3).
 If I ever find some time to implement it, I'll do it, but anyone can feel 
 free to do it before I do.



-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Building Maxima spkg fails

[Peter Bruin]

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-5.35.1.p0.log 

 Two things are very strange: 

 1. even though building the spkg failed, the build process was 
 continued. And Sage even starts! And does not crash when I do log(x) 
 (does this not involve maxima?)! And sage can even do 
   sage: maxima(log(x)) 
   log(_SAGE_VAR_x) 

 2. It also says that building some spkg called cycache has failed. 
 Background story: I noticed that there is a folder ~/.cycache, and I 
 recalled that the result of running Cython is cached. But I was not sure 
 if this is by default, and thus I tried to install cycache in addition 
 to ccache. Well, of course sage -i cycache failed, since there is no 
 such spkg. But apparently make start is now still trying to install 
 the missing package, which of course is a bug! 

 Best regards, 
 Simon 




-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Building Maxima spkg fails

[Peter Bruin]

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.
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] abs(matrix)

[Peter Bruin]

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 should be the matrix consisting of absolute 
  values of entries, since that only works for matrices over a ring with 
  an absolute value.  Using 
  it as a determinant is consistent with standard notation, though I 
  agree that we don't usually say absolute value in this context. 

 abs(m) is not a standard notation for the determinant... (though |m| 
 is as Simon mentioned). My conclusion is that we should just forbid 
 __abs__ for matrices.

 
I would also be in favour of deprecating this.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 habet.  (Aut, sicut hodie dicetur: plus 
unum!)

Ceterum censeo codicem morum delendum esse.

Petrus

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 lingua 
 franca of sage- lists/groups. That would give us the added benefit  of 
 having grammatically well-built posts much more frequently...


 Quick, lets vote on it since it is only today that there are no Americans 
 on sage-devel ;-) 


 Placet. Sic fiat.


Placet mihi quoque.

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 group of invertible elements 
 in Z_n as a useful tool for teaching introductory group theory.  There 
 is of course, a very simple and straight-forward classification of 
 these abelian groups.  But for someone new to the topic, they display 
 quite a bit of variety - sometimes, cyclic, sometimes not, a variety 
 of orders for the elements, and a variety of subgroups.  I'd say they 
 might even look unpredictable to a novice. 

 In  IntegerModRing  there are a few relevant methods whose name begins 
 with unit and a few that begin with multiplicative.  These are 
 useful for students, and unit_gens will be useful for my purposes. 
 My intent would be to implement the group so that all a student ever 
 saw was the actual integers mod n. Under the hood, the classification 
 and generators might provide an efficient implementation.  For 
 example, rather than having multiplicative_subgroups return each 
 subgroup as a list of generators, it might be possible to actually 
 build the subgroups so they can be queried about order, cyclic-ness, 
 etc.  So I'd try to make the group implementation general enough to 
 also represent the subgroups. 

 So this won't necessarily make Sage any more powerful, but it might be 
 a great teaching tool for basic concepts of group theory, at least up 
 until the classification of finite abelian groups. 

 Has this group been implemented somewhere and I missed it?  Is there 
 some other powerful machinery for rings that might make this easier to 
 implement?  Any code elsewhere for a similar structure or purpose that 
 I might look to for help in designing this?  Any general advice or 
 suggestions?  Thanks! 

 Rob 


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 many patches. 


Maybe it is also useful to say for reference that there are 9 PARI patches 
in Sage 6.4.beta3, all of which are relatively small.  Most of them are to 
fix configuration problems, or in one case a GCC bug.  The exception is 
nffactor.patch, which is taken from an upstream commit included in the 
latest stable PARI release.

I have been working on the upgrade to the PARI git master (#16997), 
 which is in theory ready for review. The main new feature is an 
 implementation of Kedlaya for (hyper)elliptic curve point counting. 


At the moment it is not clear to me that starting to track the development 
version is the best decision.  It's called development version for a 
reason...

In that ticket, I would like to add two patches to PARI adding new 
 functionality, which unfortunately upstream refuses. Personally, I think 
 we should add these two patches to PARI-in-Sage anyway, regardless of 
 what upstream thinks. This will create a small fork between upstream 
 PARI and PARI-in-Sage. Hopefully, over time upstream will change their 
 mind and accept those patches after all. 


Or we find a different way to solve the respective problems that allows us 
to get rid of these patches.

If somebody has advice about how to deal with this situation or has 
 reasons why adding functionality to the PARI-in-Sage is absolutely not 
 acceptable, I would love to hear.


My opinion is that any new patch needs a very good reason to be included, 
and that we should try hard to avoid (the appearance of) a fork; the number 
theory world is too small for that.
 

 Details about the 2 patches: 

 * infinity.patch: PARI has a new infinity type but in upstream's 
 version, this type is almost useless. My patch allows basic arithmetic 
 (like 2*oo gives oo), which is needed to not break Denis Simon's scripts. 
 Rejected by upstream because Purposefully, we restricted the semantic 
 attached to oo. Most of the time such operations are the symptom of a bug.


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 of semantics that is valid in all or even most cases; you are also 
forced to either introduce NaN or accept that arithmetic operations may 
throw errors, etc.

One thing that does make this case a little more difficult is the fact that 
Denis Simon's scripts are not updated very frequently.  On the positive 
side, the functionality of these scripts is gradually being moved into the 
PARI library.

In this case I would prefer to make a few simple changes to Simon's code 
instead of introducing arithmetic with infinity just to fix this problem.

* ispseudoprimepower.patch: add a new function ispseudoprimepower() 
 which is like isprimepower() but without a primality proof. This could 
 be used in Sage for GF(p^n, proof=False). 
 Upstream's reaction: Well, but who would use it ?


That would by my question too.  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())?

In #16997, I am also adding other patches: 

 * qfparam_primpart.patch: fixes PARI bug #1611, upstream has not yet 
 commented on this.


I would say this is a price to pay for tracking a development version.  If 
it is not a critical bug, then I would prefer to wait for it to be fixed 
upstream and then include the relevant upstream commit as a patch until the 
next version is released.

* public_memory_functions.patch: make some private functions public. I 
 consider this a transitional patch to keep using Sage's memory handling 
 code for PARI. Upstream has changed a lot the way they deal with the 
 PARI stack. For the moment, we don't use these functions, but in some 
 future ticket we can have a look at it. Because of the transitional 
 nature, not submitted to upstream.


This is a reasonable thing to do, and an acceptable reason for a patch in 
my opinion.  At some point we will have to find out if we can do everything 
we want using the public interface.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 almost impossible to get new code into PARI: I have 
contributed (internal) PARI functions for faster linear algebra over finite 
fields on several occasions.  I also have my own collection of PARI 
routines, but the reason they exist is specific enough that there is no 
reason why they should go into upstream.

On Friday, September 26, 2014 9:32:59 AM UTC+1, Jeroen Demeyer wrote:

 Upstream's reaction: Well, but who would use it ? 


 Answer: Number theorists, most likely ;-)


Actually a very small subset, like Sage developers who want to implement 
GF(p^n, proof=False)...

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 of semantics that is valid in all or even most cases; you are 
 also forced to either introduce NaN or accept that arithmetic operations 
 may throw errors, etc.


 And that is a good thing! If you have to check before every operation that 
 the input is acceptable then you litter your code with if branches that 
 make it hard to follow what you are actually doing. Separating the error 
 handling from the actual algorithm is a basic programming pattern...


Sure, it is not the simple fact that errors are thrown that is the 
problem.  What I meant is that by allowing arithmetic with infinity, you 
could easily mask actual mathematical mistakes, due to the fact that there 
is hardly any property of infinity/ies that is valid in every case.  I 
think the original point in Denis Simon's program with respect to which 
this question arose involved taking a certain valuation of zero.  This used 
to return a very large integer, now it returns infinity.  I don't know if 
in this case zero was a valid value for the variable in question, but 
things like this are cases where the code needs to be clear on whether it 
is valid or not, instead of allowing errors to be raised later.  It is 
completely sensible for valuation(0) to result in an error (or a useless 
infinity return value), which you can then explicitly catch or check for, 
instead of allowing the program to silently continue computing with 
infinity, possibly resulting in a mathematically nonsensical answer later.  
Explicitly checking for x = 0 in the code inspires more confidence in the 
correctness of the program than code that doesn't tell you whether the 
author ever thought about the case x = 0.

One thing that does make this case a little more difficult is the fact that 
 Denis Simon's scripts are not updated very frequently.  On the positive 
 side, the functionality of these scripts is gradually being moved into the 
 PARI library.

 In this case I would prefer to make a few simple changes to Simon's code 
 instead of introducing arithmetic with infinity just to fix this problem.


 So even if upstream never comes around with infinities, we can always 
 remove the infinities patch once the scripts have been updated.


Only if nothing else has started to rely on them in the meantime...

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 things. The first gives an error immediately such that you 
 know where the problem lies, with the second you need to track down 
 where the infinity came from. 


By useless I mean the type of infinity that PARI currently has, which 
causes errors as soon as you try to do arithmetic with it.  In many cases 
this should get you closer to the source of the error than a useful 
infinity that allows arithmetic.
 

  What I meant is that by allowing arithmetic with infinity, you could 
  easily mask actual mathematical mistakes, due to the fact that there 
  is hardly any property of infinity/ies that is valid in every case. 
 I really think the situation isn't as bad as you (or Bill on pari-dev) 
 describe. Before PARI-2.8, valuation(0,p) returned LONG_MAX and the 
 world didn't collapse. Sage also returns +Infinity for valuation(0,p) 
 and I don't think anybody ever complained about that. 


Whether something makes the world collapse is not a useful metric. 8-)

I don't think that valuation(0, p) returning Infinity is necessarily a bad 
thing (although it goes against my personal taste to define it that way).  
I do admit being slightly worried about the ease with which infinity is 
thrown around as if it is for most practical purposes a real number.

I think my proposed patch is a good middle ground: it allows sufficient 
 arithmetic with oo to be actual useful but it doesn't allow too much, 
 closing a lot of pitfalls. And it keeps old code working. 


I am not that strongly against the limited functionality you implemented; I 
am just wondering if it is worth diverging from PARI for.

 Explicitly checking for x = 0 
  in the code inspires more confidence in the correctness of the program 
  than code that doesn't tell you whether the author ever thought about 
  the case x = 0. 
 On the other hand, many mathematical statements involving valuations 
 remain true if you allow 0 and define the valuation of 0 to be +oo with 
 the usual meaning. So why not reflect this in the code? 


Certainly, but many is not all; the infinity doesn't know if it comes 
from a valuation or from somewhere else, and for what it is going to be 
(mis)used.
 

  So even if upstream never comes around with infinities, we can 
  always remove the infinities patch once the scripts have been 
 updated. 
  
  
  Only if nothing else has started to rely on them in the meantime... 
 If so, that would be further proof that arithmetic with infinities is 
 useful. 


Or that people simply assumed it would be useful without realising that 
they may be entering mathematically ill-defined territory...

By the way, I think t_INFINITY in PARI was introduced in the first place as 
a better notation for integration limits (instead of the strange [+1] and 
[-1]).  From the PARI documentation of oo (note for use in functions 
such as intnum):

Returns an object meaning $+\infty$, for use in functions such as
\kbd{intnum}. It can be negated (\kbd{-oo} represents $-\infty$), and
compared to real numbers (\typ{INT}, \typ{FRAC}, \typ{REAL}), with the
expected meaning: $+\infty$ is greater than any real number and $-\infty$ is
smaller.

From a mathematical perspective, I can certainly understand why the PARI 
developers are reluctant to expand the semantics of t_INFINITY to make it 
behave in a more meaningful way.  It is simply a fact that the concept of 
infinity does not have one standard mathematical meaning.  I think it is 
still quite natural (and this is a point of view the PARI developers seem 
to share) to think of the real numbers together with plus and minus 
infinity as just an ordered set isomorphic to (or topological space 
homeomorphic to) the closed interval [-1, 1], but addition and scalar 
multiplication on this set already feel like ad hoc operations to me.

I guess my objection to attaching too much meaning to infinity comes from 
an uneasy feeling that this goes in the direction of symbolic 
manipulation rather than working in a well-defined mathematical 
structure.  I would say the same about the infinity ring, of which 
probably hardly any non-computer-algebra-oriented mathematician would see 
the point.

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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())? 
 To expand on this a bit more: I think the number of lines in the 
 implementation is not a good metric to decide whether or not to include 
 a function. And perhaps it's clear for you that it's those two lines, it 
 might not be that clear for everybody (just look at the implementation 
 of is_prime_power() for proof=False in arith.py) 

 My 2 cents. This is a bad metric. If it's a natural question to ask, then 
 it should be a function/method. I can think of many functions which are 
 simple computations (even more so than calling 2 other functions), but it 
 makes the code easier to read and maintain IMO. Plus it's not like there 
 will be thousands of such functions, they don't add much to the size, and 
 they don't add much time to compilation.


My argument is not that it should not be in PARI because it can be 
implemented in two lines.  Of course that is a bad metric in general.  The 
main reason why I don't see the point is that ispseudoprimepower() simply 
does not come across (to me) as a generally useful function.  As far as I 
can see, this functionality is _only_ used in Sage to factor (without 
proof) the argument to GF(q) and to check if it is a pseudoprime power, and 
then only in the case proof=False.  If that is indeed the only thing it is 
used for, it is makes more sense (to me, again) to do something with 
ispower() and ispseudoprime() there than to ask for this function to be 
included in PARI.  It would be a different story if there were a 
significantly faster algorithm than to call ispower() and ispseudoprime(), 
but that would first need to be demonstrated.

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Deprecations for changed behaviour

[Peter Bruin]

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
 different.  Since it is so recent, I'm personally willing to be a bit
 more flexible...

  -- William

 [1] http://trac.sagemath.org/ticket/14990

As the author of #14990, I can add that I certainly did not intend to
_prescribe_ that modulus() and gen() should always return x - 1 and 1,
respectively.  I think Jeroen's proposal to make these customisable is
very reasonable and does not require a deprecation warning.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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: simplify( abs(1/sqrt(x))  )
 abs(1/sqrt(x))
 The behavior in Sage = 6.2 is coherent and correct for x real (but not
 for x complex !), while that in Sage 6.3 is not coherent (why simplifying
 abs(sqrt(x)) and not abs(1/sqrt(x)) ?). Is there any reason for this ?
 Shall this be considered as a bug ?

This is probably due to Maxima.  The following happens with and without
the domain: complex setting:

Maxima 5.34.0 http://maxima.sourceforge.net
using Lisp ECL 12.12.1
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) domain: complex;
(%o1)   complex
(%i2) abs(sqrt(x));
(%o2)   sqrt(x)
(%i3) abs(1/sqrt(x));
   !   1   !
(%o3)  !---!
   !sqrt(x)!

I guess the first answer should be left alone (or at most changed to
sqrt(abs(x))) when domain: complex is set, which is what Sage does.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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)
 while in Sage 6.3:

 sage:  from sage.calculus.calculus import maxima
 sage: abs(1/sqrt(x))._interface_(maxima)
 abs(1/sqrt(_SAGE_VAR_x))

I see; actually I didn't test it in an older version of Maxima since I
only had 5.34.0 installed.  Maybe it is because of #16224 instead?  This
fixed a bug in the Maxima interface that changed (among other things)
which Sage function corresponds to Maxima's abs().

Anyway, a bit more experimenting shows that this behaviour can be fixed
using declare(x, complex):

(%i1) display2d: false;
(%o1) false
(%i2) abs(sqrt(x));
(%o2) sqrt(x)
(%i3) declare(x, complex);
(%o3) done
(%i4) abs(sqrt(x));
(%o4) abs(sqrt(x))
(%i5) abs(1/sqrt(x));
(%o5) abs(1/sqrt(x))

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 by default that it is operating over the reals, so that for example
abs(sqrt(x)) = sqrt(x) -- because sqrt is treated as a real-to-real
function with domain and range 0..inf.  But if there is an explicitly
complex quantity (%i or a variable declared complex), that assumption is
invalidated, so abs(z^2) = abs(z)^2, where declare(z,complex).

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 construction argument to the
 construct:

Ticket #16507 should solve this (at least to some extent) in situations
where there is a coercion B - A instead of A - B.  (Here B is the
object resulting from a functorial construction applied to A; this can
be used if B is a submodule of A, for example.)  This won't address
things like (base ring, cusp forms) - (modular forms), though.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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/src/sage/rings/polynomial/polynomial_element.pyx
+++ b/src/sage/rings/polynomial/polynomial_element.pyx
@@ -3370,7 +3370,9 @@ cdef class Polynomial(CommutativeAlgebraElement):
 elif is_FiniteField(R):
 v = [x._pari_(a) for x in self.list()]
 f = pari(v).Polrev()
+print('f = %s' % f)  # PARI polynomial
 G = list(f.factor())
+print('G = %s' % G)  # PARI factorisation

 elif is_NumberField(R):
 if R.degree() == 1:
@@ -3470,6 +3472,7 @@ cdef class Polynomial(CommutativeAlgebraElement):
 exps = G[1]
 R = self.parent()
 F = [(R(f), int(e)) for f, e in zip(pols, exps)]
+print(F = %s % F)  # PARI factorisation converted to Sage

 if unit is None:
 unit = self.leading_coefficient()

The first failure I is copy-pasted below.  The PARI factorisation G is
exactly the same the first time (the failure) and the second time (the
double-checking).  To make it look nicer:

gp  lift(lift(Mat(G)))
%2 = 
[  x + 1 1]

[x + (a^7 + a^6 + a^5 + 2*a + 1) 1]

[x + (2*a^7 + 2*a^6 + 2*a^5 + a + 1) 1]

[x^5 + x^4 + 2*x^3 + x^2 + x + 1 1]

However, the Sage factorisation F is different.  In fact, it appears
that the call to R(f) used in constructing F incorrectly converts the
factor x + (2*a^7 + 2*a^6 + 2*a^5 + a + 1) into T + (2*z^3 + z + 2).

Peter


f = Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 
3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^8 + Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 
3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^7 + 
Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + 
Mod(2, 3)*a + Mod(2, 3))*x^5 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + 
Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^4 + Mod(Mod(1, 3), 
Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + 
Mod(2, 3))
G = [[Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 
3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 
3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3)), Mod(Mod(1, 
3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a 
+ Mod(2, 3))*x + Mod(Mod(1, 3)*a^7 + Mod(1, 3)*a^6 + Mod(1, 3)*a^5 + Mod(2, 
3)*a + Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 
+ Mod(2, 3)*a + Mod(2, 3)), Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + 
Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x + Mod(Mod(2, 3)*a^7 
+ Mod(2, 3)*a^6 + Mod(2, 3)*a^5 + Mod(1, 3)*a + Mod(1, 3), Mod(1, 3)*a^8 + 
Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3)), 
Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + 
Mod(2, 3)*a + Mod(2, 3))*x^5 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + 
Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^4 + Mod(Mod(2, 3), 
Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + 
Mod(2, 3))*x^3 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + 
Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^2 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + 
Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x + 
Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + 
Mod(2, 3)*a + Mod(2, 3))]~, [1, 1, 1, 1]~]
F = [(T + 1, 1), (T + z^7 + z^6 + z^5 + 2*z + 1, 1), (T + 2*z^3 + z + 2, 1), 
(T^5 + T^4 + 2*T^3 + T^2 + T + 1, 1)]
ERROR (after 524 iterations):
 polynomial   : 2*T^8 + 2*T^7 + 2*T^5 + T^4 + 1
 factorization: (2) * (T + 1) * (T + 2*z^3 + z...
 product  : 2*T^8 + (2*z^7 + 2*z^6 + 2*z^5...
f = Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 
3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^8 + Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 
3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^7 + 
Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + 
Mod(2, 3)*a + Mod(2, 3))*x^5 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + 
Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^4 + Mod(Mod(1, 3), 
Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + 
Mod(2, 3))
G = [[Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 
3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 
3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3)), Mod(Mod(1, 
3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a 
+ Mod(2, 3))*x + Mod(Mod(1, 3)*a^7 + Mod(1, 3)*a^6 + Mod(1, 3)*a^5 + Mod(2, 
3)*a + Mod(1, 3), Mod(1, 

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

[Peter Bruin]

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 linear subspaces,
there is such a functorial construction, namely SubspaceFunctor, and
it does get used in pushout constructions.  I encountered this when
looking at #10513, and this was the reason for opening #16507.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 SubspaceFunctor (i.e.
with coercion_reversed=True in the terminology of #16507)?  Then
pushout() would remove the application of CuspidalSubspace when merging
the two constructions.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 arguments would make more sense there, no?

Do you mean something like the following?  Assume you have a
construction EvenSubspace() that applies to spaces of polynomials and
returns the subspace of all polynomials that only have even powers of x.
This of course includes constants.  Suppose you have a ring homomorphism
A - B and you want to do

pushout(B, EvenSubspace(PolynomialRing(A, 'x')))

I guess my approach would indeed eliminate the application of
EvenSubspace() because it doesn't know that B still coerces into
EvenSubspace(PolynomialRing(B, 'x')).  If this is the case, the
criterion for eliminating a coercion-reversed construction step F
probably needs to be made more strict: if both of the original objects
still coerce into the result of applying F, then we do want to apply F.
Does that sound reasonable?

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 arguments would make more sense there, no?

 Do you mean something like the following?  Assume you have a
 construction EvenSubspace() that applies to spaces of polynomials and
 returns the subspace of all polynomials that only have even powers of
 x.  This of course includes constants.  Suppose you have a ring
 homomorphism A - B and you want to do

 pushout(B, EvenSubspace(PolynomialRing(A, 'x')))

 Yes. I call this (implicit) base change where I mean base in the
 sense of base of construction (which in many cases starts as a
 ring).  This assumes that the base object coerces into the constructed
 object.

The fact that you need this last assumption may be a sign that pushout()
is not the right tool to do such a base change.  An alternative would be
to implement the base_extend() method (for the objects you are
interested in) in such a way as to repeat the construction of that
object with the new base ring.

 I guess my approach would indeed eliminate the application of
 EvenSubspace() because it doesn't know that B still coerces into
 EvenSubspace(PolynomialRing(B, 'x')).

 1.1 + x^2 would e.g. fail resp. not lie in EvenSubSpace.

Yes, exactly.

 If this is the case, the criterion for eliminating a
 coercion-reversed construction step F probably needs to be made
 more strict: if both of the original objects still coerce into the
 result of applying F, then we do want to apply F.  Does that sound
 reasonable?

 I'm not sure. I was hoping for a simple system where it is clear what
 happens. But since this would probably involve a partial redesign of
 the pushout construction all-together and since so many things depend
 on the old system I don't see this happening any time soon. :(

Ideally (in my opinion), doing pushout(X, Y) would look for the most
specific common category C in which X and Y are objects, and ask that
category C to return the categorical push-out of X and Y in C (as an
object Z with maps X - Z and Y - Z, which would then be used as
coercion maps).  But this is tricky: if X = ZZ[[x]] and Y = FF_p[x],
then you first want to deduce that C is the category of commutative
ZZ[x]-algebras, and to know that the push-out is the tensor product.
Then you have to implement this tensor product in a sufficiently
concrete way that it returns F_p[[x]] and not some abstract tensor
product object.  This is definitely not doable yet.

 Regarding your suggestion/fix:
 I'm not sure (as mentioned the pushout construction is complex and
 there are many cases). But yes, that might work:
 Do a/several coercion check(s) _during_ pushout (during the while loop
 starting at line 3210) if needed instead of only at the end.

 So coercion_reversed=False (default) would mean that we assume that
 the current base coerces into construction(base) and
 coercion_reversed=False would mean that a coercion check should be
 done.

 If yes: Maybe something like force_coercion_check fits better?

That's an interesting suggestion.  I'll try thinking about it a bit more
to see if this is an improvement over coercion_reversed.

 Note: That would actually work in general (always doing a coercion
 check) but for performance reasons it's nice to only do it when
 forced...

Indeed, it makes no sense to do such a check for constructions of which
you know that it is always going to succeed...

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Power series normalisation

[Peter Bruin]

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 currently implements power series on top of polynomials, not via
PARI (but I have been working on a different implementation based on
PARI series, see http://trac.sagemath.org/ticket/15601).

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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, the hashes of two previous implementations of finite 
 fields using PARI where different because some variable name was replaced 
 by something else in some object and this prevented this problem to occur.

 I read 
 http://www.sagemath.org/doc/developer/coding_in_python.html#the-hash-special-method
  
 but would welcome any advice.

 Though (non-prime) finite fields with the same order and defining 
 polynomial are considered equal, I'd say the hashes should be different.
 So, let's add the string of the implementation of the finite field into 
 it's hash (which is cached by the way).
 Does that seem sensible?

 Or should I modify the finite field code so that these hashes are equal 
 whatever the implementation is?
 Then we'd need coercion between all of the implementations (which is not 
 currently the case but should be done anyway), but that would surely yield 
 a non-negligible speed penalty, and you'll never know what the 
 implementation of the base ring of the polynomial ring will be as it will 
 depend on the order finite fields and their polynomial rings are created.

 Or should we modify the caching system of the polynomial rings not to use 
 hashes but ids?


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 identical.  Would 
this be enough?

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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, 'a', impl='pari_ffelt') == GF(13**5, 'a', impl='flint_fq')
 True

This should probably be False; even though the fields are canonically
isomorphic, pretending that they are equal sounds like asking for
trouble to me...

 Though I have:
 sage: GF(13**5, 'a', impl='pari_ffelt') == GF(13**5, 'a', impl='pari_mod')
 False
 Maybe that's because of the __cmp__ functions I copied/pasted/slightly
 modified.
 Or maybe I forgot to implement some methods as the new classes are cdefed.
 I'll check that.

I'm testing a patch that makes FiniteField behave like WithEqualityById
(unfortunately, inheriting from it is not possible because Cython does
not support multiple inheritance) and removes all hashing and comparison
methods from other finite field classes.

By the way, there is no point in relying on hashes being different for
different objects if they still compare equal; there is always some
small probability of a hash collision.  (I just saw that Simon King
wrote something to the same effect.)

Peter


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 identical.  Would this be enough?

 I think this would make sense---of course with bidirectional
 coercions, as mentioned in my previous mail.

This is now implemented in #16855 (ready for review).

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Difficulties with resultant

[Peter Bruin]

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^3 + 3*x + 1)

which is not a polynomial at all.  If you want to do this computation in
PARI, you have to replace x by a variable with lower priority than y:

gp  y; z;
gp  f = (z^4*y^2 + (z^3 + 1)*y + (z - 2)) * Mod(1, z^3 + 3*z + 1) * Mod(1, 
487326487);
gp  g = ((z^3 + 2*z + 1)*y^2 + (z + 1)*y + (z^4 + z^3 + z^2 + 1)) * Mod(1, z^3 
+ 3*z + 1) * Mod(1, 487326487);
gp  polresultant(f, g)
%4 = Mod(Mod(2201, 487326487)*z^2 + Mod(487324445, 487326487)*z + 
Mod(487325602, 487326487), z^3 + 3*z + 1)

Peter


Bill Hart wrote:

 I think that is the correct answer. It agrees with one of the answers
 Magma gives, and someone else says Mathematica agrees.
 My version of Sage is 'Sage Version 6.2, Release Date: 2014-05-06'
 Bill.

 On Thursday, 7 August 2014 16:10:52 UTC+2, Frédéric Chapoton wrote:

   Hello,
   it works for me on sage 6.3.beta8, giving:
   2201*xbar^2 + 487324445*xbar + 487325602
   which version of sage do you use ? type version() to know that.
   By the way, you should rather have asked that question on sage-support
   or on ask.sagemath.org
   Le jeudi 7 août 2014 16:03:43 UTC+2, Bill Hart a écrit :

  I'm having difficulties with the polynomial resultant function in
  Sage.
  I'm trying to find the resultant of two polynomials. 
  I compute the resultant of the polynomials below to be:
  6768454*x^2+257200062*x+20305258
  Pari/GP says the resultant is 1, which I don't believe, so I thought
  I'd try Sage 6.2:
  sage: R = Integers(487326487)
  sage: S.x = PolynomialRing(R)
  sage: T = QuotientRing(S, x^3 + 3*x + 1)
  sage: U.y = PolynomialRing(T)
  sage: f = x^4*y^2 + (x^3 + 1)*y + (x - 2)
  sage: g = (x^3 + 2*x + 1)*y^2 + (x + 1)*y + (x^4 + x^3 + x^2 + 1)
  sage: f.resultant(g)
  ---
  PariError Traceback (most recent call
  last)
  ipython-input-9-14f40f55d982 in module()
   1 f.resultant(g)
  
 /usr/local/sage/sage-current/local/lib/python2.7/site-packages/sage/structure/element.so
  in sage.structure.element.NamedBinopMethod.__call__
  (sage/structure/element.c:25475)()
  
 /usr/local/sage/sage-current/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_element.so
  in sage.rings.polynomial.polynomial_element.Polynomial.resultant
  (sage/rings/polynomial/polynomial_element.c:33908)()
  
 /usr/local/sage/sage-current/local/lib/python2.7/site-packages/sage/rings/polynomial/polynomial_element.so
  in sage.rings.polynomial.polynomial_element.Polynomial._pari_with_name
  (sage/rings/polynomial/polynomial_element.c:33119)()
  
 /usr/local/sage/sage-current/local/lib/python2.7/site-packages/sage/libs/pari/gen.so
  in sage.libs.pari.gen.gen.Polrev (sage/libs/pari/gen.c:12936)()
  
 /usr/local/sage/sage-current/local/lib/python2.7/site-packages/sage/libs/pari/handle_error.so
  in sage.libs.pari.handle_error._pari_handle_exception
  (sage/libs/pari/handle_error.c:1178)()
  PariError: variable must have higher priority in gtopoly
  ---
  Magma gives two different answers, depending on whether you coerce the
  coefficients of f and g into T or not (I don't see why). Neither agree
  with the Pari/GP answer, or the answer I compute myself (which is very
  likely wrong).
  Coercing the coefficients into T makes no difference to the resulting
  error in Sage.
  Can someone tell me what I am doing wrong here. I obviously don't know
  what I'm doing. I've never really tried to do any genuine computer
  algebra before. 
  Bill.

 --
 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@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: flint revert_series

[Peter Bruin]

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 it, http://arxiv.org/abs/1108.4772). The generic
 code would be a little slower than flint's implementations over Z, Q
 and Z/nZ, so you definitely want to special-case those. But in
 general, this should be much faster than sage's current
 implementation for polynomials of high degree.

 I am not familiar with the details but I assume that the algorithm
 heavily depends on the performance of power series operations like
 multiplication or inversion. See e.g. fredrikj.net/math/rev.pdf

 Flint is quite fast for all of those and I think sage's power series
 implementation is not optimized at all (does it even support fast
 multiplication?).

 The ideal solution would be to directly improve sage's power series
 implementation (e.g. using flint's code, which probably requires quite
 a lot of work). In any case if you can implement the mentioned
 improvement above that would be great of course. :-)

A while ago I wrote a Sage interface to PARI power series; see
http://trac.sagemath.org/ticket/15601.  It gives a nice speedup over
finite fields, but currently doesn't seem to be much faster than Sage's
own implementation over Q or Z.  Maybe the upgrade to PARI 2.7.1 will
improve this (see http://trac.sagemath.org/ticket/15767), but the two
tickets don't work together out of the box.  I think the ideal solution
would be to implement power series using FLINT; whoever wants to do this
should feel free to use #15601 as a template.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 a bilinear map A x A - A is regarded as a
finite-dimensional algebra.  You can use methods like is_associative()
to check if your algebra has certain properties:

sage: A = 
FiniteDimensionalAlgebra(CC,[Matrix([[1,1],[1,0]]),Matrix([[0,1],[1,1]])])
sage: A.is_associative()
False
sage: A.is_commutative()
False
sage: A.is_unitary()
False

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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
equivalent to factornf(f, g), but there seems to be a bug in nffactor().

In GP 2.5.5 as distributed with Sage,

gp  nffactor(nfinit(y^2 - 22), Mod(1, y^2 - 22)*x^2 + 
Mod(926246528884912528275985458927067632*y - 
4344481316563541186659879867597013188, y^2 - 22))
  ***   at top-level: nffactor(nfinit(y^2-
  *** ^
  *** nffactor: the PARI stack overflows !
  current stack size: 67108864 (64.000 Mbytes)

The same happens with the latest development version.  It does not seem
to be an actual out-of-memory problem, since (according to GDB or \g 6
in GP) the error happens at the same point no matter how much stack size
you give it.

I think it is actually a precision issue, since increasing the working
precision solves the problem (in both 2.5.5 and development 2.8.0):

gp  \p 100
   realprecision = 115 significant digits (100 digits displayed)
gp  nffactor(nfinit(y^2 - 22), Mod(1, y^2 - 22)*x^2 + 
Mod(926246528884912528275985458927067632*y - 
4344481316563541186659879867597013188, y^2 - 22))
%1 = 
[x + Mod(-314226370217524044*y + 1473852319020386314, y^2 - 22) 1]

[x + Mod(314226370217524044*y - 1473852319020386314, y^2 - 22) 1]

Peter


John Cremona wrote:

 On 16 June 2014 14:25, John Cremona john.crem...@gmail.com wrote:
 sage: K.a = QuadraticField(22)
 sage: D = -926246528884912528275985458927067632*a +
 4344481316563541186659879867597013188
 sage: D.is_square()
 (boom)
 MemoryError: Unable to allocate 2560 bytes for the PARI stack
 (instead, allocated 2048 bytes)

 Sage Version 6.3.beta3

 Any ideas?  Other arithmetic with this works fine, and in fact:

 sage: eps = 197-42*a
 sage: rootD = eps^8 * (14+3*a)^2
 sage: rootD^2 == D
 True

 so the problem is in a call to Pari to factor the polynomial x^2-D.


 Using the same pari/gp version (2.5.5) I have no problem doing the
 same factorization diectly in gp:

 ? nf = bnfinit(t^2-22);
 ? a = Mod(t,t^2-22);
 ? D = -926246528884912528275985458927067632*a +
 4344481316563541186659879867597013188;
 ? factor(x^2-D)
 %4 =
 [x + Mod(-314226370217524044*t + 1473852319020386314, t^2 - 22) 1]

 [x + Mod(314226370217524044*t - 1473852319020386314, t^2 - 22) 1]



 John

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 version string of the 
 package
 but still force a rebuild.


In this case the offending ticket was #9493 (authors: Leif and 
Jean-Pierre, reviewer: me).  The actual ECL version was the same, there was 
just a change in packaging where unneeded stuff was removed from the 
tarball.  The package-version.txt was updated (version number changed by 
appending a date, patchlevel reset to empty).

There was no reason to change the patchlevel of Maxima since nothing 
changed there.  The problem is that Maxima somehow needs to re-register 
itself as an ECL package so the reinstalled ECL knows that it exists.  It 
may be possible to do this in an easier way than by reinstalling Maxima, 
but setting SAGE_UPGRADING=yes solved the problem for me.

As for making SAGE_UPGRADING=yes the default, I personally keep it unset 
and only set it to yes when encountering problems such as this (but the 
patchbot I am running has it set to yes).  I would probably keep doing this 
if the default were changed, to avoid the annoying unnecessary 
reinstallations mentioned by others.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

 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 similarly make the following work:

sage: Modules(ZZ)
Category of commutative additive groups

Peter


Op dinsdag 27 mei 2014 20:14:06 UTC+1 schreef vdelecroix:

 Hi, 

 A module over ZZ is the same thing as an Abelian group. Why do we have 
 two distinct categories ? 

 More concretely, I want to implement a function that takes any finite 
 Abelian group as input ? So my test would looks like 

 def f(A): 
 assert A in CommutativeAdditiveGroups().Finite() 

 or 

 def f(A): 
 assert A in Modules(ZZ).Finite() 

 Is there a preference ? Is there a way to merge Modules(ZZ) and 
 CommutativeAdditiveGroups() ? 

 Vincent 


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: setuptools install problem

[Peter Bruin]

It would be great if that worked.  I disabled the tmp directory for the 
moment and am testing all tickets in the same directory, but that can leave 
the tree in a bad state.

Peter


Op vrijdag 16 mei 2014 10:03:01 UTC+1 schreef Ralf Stephan:

 Ah I finally found the relevant upstream ticket:

 https://bitbucket.org/pypa/setuptools/issue/168/ez_setuppy-failing-sporadically-when
 which appears resolved with setuptools-3.5.2

 Next is testing of a version = 3.5.2

 Regards,

 On Thursday, May 15, 2014 9:53:36 AM UTC+2, Ralf Stephan wrote:

 It may be possible to test newer package versions in patchbot without
 official ticket by forking Sage on github, installing the package in the 
 local
 Sage, publish the changed branch on github, and use that branch as
 base_repo with patchbot. This may work also with unsafe tickets because
 the cloning into /tmp copies upstream/ too. I'm testing that soon.

 If this doesn't work then my fork of patchbot soon will have a version
 with a --keep-tmp option that doesn't delete failed installs in /tmp so
 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:

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

 http://trac.sagemath.org/ticket/16300

 People running patchbot with errors on setuptools install please try
 version 2.2b1 of setuptools and report if this changes the behaviour
 or not.

 Regards,



-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 of Rational Field

if '_Spec__R' in state:
state['_AffineScheme__R'] = state.pop('_Spec__R')
super(AffineScheme, self).__setstate__(state)


Op dinsdag 13 mei 2014 03:16:28 UTC+1 schreef Julian Rüth:

 Hello sage-devel, 

 at #11895 I'm trying to make p-adic numbers unhashable. This works 
 nicely except for one pickle from the pickle jar that I can't seem to 
 fix. 

 The problem is that DirichletGroup_class used to have a dict which uses 
 p-adic numbers as keys. That dict used to be a cache which is not used 
 anymore, so dropping it would be no problem. However, I can only drop it 
 after the dict has been unpickled. But this fails since the unhashable 
 p-adic numbers can not be used as keys anymore. 

 Here is a minimal example to illustrate the problem: 

 sage: class DirichletGroup(object): pass 
 sage: class pAdicNumber(object): pass # the old hashable p-adic number 
 sage: 
 sage: G = DirichletGroup() 
 sage: G._cache = { pAdicNumber() : 0 } 
 sage: s = dumps(G) 
 sage: 
 sage: class pAdicNumber(object): 
 : __hash__ = None # now p-adics are not hashable anymore 
 : 
 sage: loads(s) 
 TypeError: unhashable type: 'pAdicNumber' 

 Any ideas how I could influence the unpickling so that the string s can 
 be unpickled with the _cache dropped in this example? 

 Thanks, 

 julian 


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

Hi Julian,

OK, I see the problem.  It seems that it is not unique to DirichletGroup, 
but is more general:

sage: class pAdicNumber(object): pass
sage: d = { pAdicNumber(): 0 }
sage: s = dumps(d)
sage: pAdicNumber.__hash__ = None
sage: loads(s)
...
TypeError: unhashable type: 'pAdicNumber'

For all we know, old pickles everywhere (e.g. on people's computers, not in 
the pickle jar) may contain dictionaries where p-adic numbers are used as 
keys.  What to do about this?  It sounds a bit drastic to generally change 
unpickling of dictionaries so that keys whose type is 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 pjb...@gmail.com javascript: [2014-05-13 01:23:56 
 -0700]: 

  Here is my solution to a similar problem in #15158: 
  
  def __setstate__(self, state): 
 The problem is that __setstate__ never gets called because the error 
 happens earlier, during the unpickling of state. 
 In other words, if I change DirichletGroup to 

 sage: class DirichletGroup(object): 
 : def __setstate__(self, state): 
 : assert(False) # I never get here 

 then the assertion is not triggered by loads(s). 

 julian 

  Op dinsdag 13 mei 2014 03:16:28 UTC+1 schreef Julian Rüth: 
   
   Hello sage-devel, 
   
   at #11895 I'm trying to make p-adic numbers unhashable. This works 
   nicely except for one pickle from the pickle jar that I can't seem to 
   fix. 
   
   The problem is that DirichletGroup_class used to have a dict which 
 uses 
   p-adic numbers as keys. That dict used to be a cache which is not used 
   anymore, so dropping it would be no problem. However, I can only drop 
 it 
   after the dict has been unpickled. But this fails since the unhashable 
   p-adic numbers can not be used as keys anymore. 
   
   Here is a minimal example to illustrate the problem: 
   
   sage: class DirichletGroup(object): pass 
   sage: class pAdicNumber(object): pass # the old hashable p-adic number 
   sage: 
   sage: G = DirichletGroup() 
   sage: G._cache = { pAdicNumber() : 0 } 
   sage: s = dumps(G) 
   sage: 
   sage: class pAdicNumber(object): 
   : __hash__ = None # now p-adics are not hashable anymore 
   : 
   sage: loads(s) 
   TypeError: unhashable type: 'pAdicNumber' 
   
   Any ideas how I could influence the unpickling so that the string s 
 can 
   be unpickled with the _cache dropped in this example? 
   
   Thanks, 
   
   julian 
   
  
  -- 
  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+...@googlegroups.com javascript:. 
  To post to this group, send email to 
  sage-...@googlegroups.comjavascript:. 

  Visit this group at http://groups.google.com/group/sage-devel. 
  For more options, visit https://groups.google.com/d/optout. 


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: setuptools install problem

[Peter Bruin]

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

 http://trac.sagemath.org/ticket/16300

 People running patchbot with errors on setuptools install please try
 version 2.2b1 of setuptools and report if this changes the behaviour
 or not.

 Regards,


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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.

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 
unpickling procedures, and to ask about ideas to remedy this.

Of course the pickle jar serves a very useful purpose.  It has happened to 
me that a failure to unpickle some object in there helped me discover 
problems that weren't caught by the usual loads(dumps(x)) == x test.  I 
suppose we could fix the existing unpickling failures and then extend 
unpickle_all() to do some basic checks on the unpickled objects, in order 
to make the pickle jar even more useful and the unpickling procedures more 
robust.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 
 unpickling procedures, and to ask about ideas to remedy this.


 If it is a parent/element then you could do TestSuite(loads(x)).run()


That is in fact an existing doctest, but marked not tested, in 
sage_object.pyx:

If you want to find *lots* of little issues in Sage then try the 
following:: 
  



sage: print x; 
sage.structure.sage_object.unpickle_all(run_test_suite = True) # todo: not 
tested 


This runs :class:`TestSuite` tests on all objects in the Sage 
pickle
jar. Some of those objects seem to unpickle properly, but do 
not
pass the tests because their internal data structure is 
messed  
up. In most cases though it is just that their source file 
misses   
a TestSuite call, and therefore some misfeatures went 
unnoticed 
(typically Parents not implementing the ``an_element`` 
method). 

The comment that their internal data structure is messed up now seems to 
apply to a _lot_ of pickles.  I think that before enabling the above 
doctest (for which we would undoubtedly have to do a huge amount of work to 
make it pass) we should implement some more basic tests, like verifying 
that taking the string representation of the unpickled object raises no 
errors.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 schreef Ralf Stephan:

 Hello,

 s/he who runs that patchbot should stop and investigate why most runs fail
 because of setuptools install fail, see the other thread.
 If a newer setuptools version fixes that (I'm just running with that) I 
 think
 the newer version should be included ASAP.

 Regards,


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: setuptools install problem

[Peter Bruin]

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
 version 2.2b1 of setuptools and report if this changes the behaviour
 or not.

 Regards,


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

OK, I'll try that after the patchbot finishes the current ticket (which 
seems to be unaffected by the setuptools problem).


Op woensdag 7 mei 2014 11:27:19 UTC+1 schreef Ralf Stephan:

 Just change builds/pkg.../package-version, download to upstream, run sage 
 to fix checksums, 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 pjb...@gmail.com javascript: wrote:

 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
 version 2.2b1 of setuptools and report if this changes the behaviour
 or not.

 Regards,

  -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups sage-devel group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/sage-devel/7acENsAQeXo/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 sage-devel+...@googlegroups.com javascript:.
 To post to this group, send email to sage-...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.



-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

 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 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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 for me is making the changes without committing 
 them; then the patchbot won't undo those changes.

 ​That will work until a ticket with unsafe changes​ is encountered, with 
 full rebuild in /tmp.

 Unfortunately, src/doc is deemed unsafe too by current patchbot:
 ​https://github.com/robertwb/sage-patchbot/issues/22​



-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 beta5 using the usual (for me) git pull trac 
 develop, I type make and it fails as follows.  The first two of these 
 are optional spkgs, but the third is not.  Doing make clean first 
 makes no difference.   My sage directory is at this commit: 

 %git log 
 commit 9db8c5c598ec9de953a33b14e531bee3c092c199 
 Author: Volker Braun vbrau...@gmail.com javascript: 
 Date:   Sun Mar 23 16:48:13 2014 -0400 

 Updated Sage version to 6.2.beta5 

 (...) 

 and the end of the make output is: 

 The following package(s) may have failed to build: 

 package: database_kohel 
 log file: /home/jec/sage/logs/pkgs/database_kohel.log 
 build directory: /home/jec/sage/local/var/tmp/sage/build/database_kohel 

 package: database_stein_watkins_mini-20030423.p1.tar.bz2 
 log file: 
 /home/jec/sage/logs/pkgs/database_stein_watkins_mini-20030423.p1.tar.bz2.log 

 build directory: 
 /home/jec/sage/local/var/tmp/sage/build/database_stein_watkins_mini-20030423.p1.tar.bz2
  


 package: matplotlib-1.3.1 
 log file: /home/jec/sage/logs/pkgs/matplotlib-1.3.1.log 
 build directory: /home/jec/sage/local/var/tmp/sage/build/matplotlib-1.3.1 

 John 


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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


That is possible; the bug was fixed in 6.2.beta3.  It should be possible to 
install the latest version yourself inside an SMC project.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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.linux-x86_64-2.7/CXX
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC 
-DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ft2font_ARRAY_API 
-DPYCXX_ISO_CPP_LIB=1 
-I/home/pbruin/src/sage/local/lib/python2.7/site-packages/numpy/core/include 
-I/home/pbruin/src/sage/local/include -I. 
-I/home/pbruin/src/sage/local/include/freetype2 
-I/home/pbruin/src/sage/local/include/python2.7 -c src/ft2font.cpp -o 
build/temp.linux-x86_64-2.7/src/ft2font.o
In file included from src/ft2font.h:16:0,
 from src/ft2font.cpp:3:
/home/pbruin/src/sage/local/include/ft2build.h:56:38: fatal error: 
freetype/config/ftheader.h: No such file or directory
compilation terminated.
error: command 'gcc' failed with exit status 1
Error building matplotlib package.

I could solve this by deleting local/include/ft2build.h (this is the old 
location of this file, newer versions of freetype install it in 
local/include/freetype2/ft2build.h), but perhaps other people have the same 
problem when upgrading to 6.2.beta5.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


matplotlib-1.3.1.log
Description: Binary data

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

[Peter Bruin]

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 (e.g. 
 $Syl_2(S_n)$, or in the example below $S_n$). I build all monic polynomials 
 with the given parameters, then ask pari for the order of their Galois 
 groups using the command
 gp.polgalois(p)[1]
 The problem is, when both $n$ and $N$ are both still relatively small, 
 some sort of data structure seems to be filling up, thereby causing a 
 strange error. It appears that this structure is saving the commands I have 
 passed to gp. The problem is cumulative, meaning this data structure is not 
 cleared unless I quit my Sage session and restart.


 Perhaps the problem is best explained via an example. I can run the 
 function I constructed for $n=4, 2 \leq N \leq 4$, but when I try to run it 
 for $n=4, N=5$, the error appears:
 sage: E4(5)
 ---
 TypeError Traceback (most recent call last
 )
 ipython-input-5-06eb9bccdf87 in module()
  1 E4(Integer(5))

 string in E4(N)

 /opt/sage/local/lib/python2.7/site-packages/sage/interfaces/interface.py 
 in __getitem__(self, n)
 945 P = self._check_valid()
 946 if not isinstance(n, tuple):
 -- 947 return P.new('%s[%s]'%(self._name, n))
 948 else:
 949 return P.new('%s[%s]'%(self._name, str(n)[1:-1]))

 


 /opt/sage/local/lib/python2.7/site-packages/sage/interfaces/gp.py in set(
 self, var, value)
 509 out = self.eval(cmd)
 510 if out.find('***') != -1:
 -- 511 raise TypeError, Error executing code in 
 GP:\nCODE:\n\t%s\nPARI/GP ERROR:\n%s%(cmd, out)
 512 
 513 

 TypeError: Error executing code in GP:
 CODE:
 sage[65536]=sage[65535][1];
 PARI/GP ERROR:
   ***   at top-level: sage[65536]=sage[65535][1]
   ***^---
   ***   _[_]: not a vector.
 The ellipses denote the error being traced through several different 
 methods within the file

 /opt/sage/local/lib/python2.7/site-packages/sage/interfaces/gp.py
 If you would like to see the entire example session in which I produced 
 the error message above, go to:
 http://sharetext.org/GlBk


 Noting that $65536=2^16$, it seems that this is quite a natural place for 
 this data structure (denoted by 'sage[]' in the example) to be filling up. 
 Unfortunately, this structure is essentially inaccessible from the Sage 
 command line.
 I should also note that I attempted to fix the problem with the command
 gp.eval('allocatemem()')
 but this did not fix the problem.

 Any sort of explanation of what this data structure is, how I can clear it 
 between calls to pari, or even some sort of black box workaround, would be 
 greatly appreciated.


-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bruin]

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 represented using different 
precisions; for example, you can have a power series ring R with default 
precision 20, an element f in R with precision 10, and another element g in 
R with infinite precision.

An operation on power series (addition, inversion etc.) return the result 
in the highest precision to which it is defined; this depends on the 
precision of the elements, not on the default precision.  The exception is 
when the input has infinite precision and the output cannot be represented 
with infinite precision.  This is where the default precision comes in.  
For example, 1 - x has infinite precision, but 1/(1 - x) = 1 + x + x^2 + 
x^3 + ... cannot be represented exactly as a power series, so it is 
truncated to the default precision.

In PARI the situation is similar, except for two things: (1) there is no 
distinction between polynomials and power series of infinite precision 
that happen to be polynomials, and (2) the default precision is a global 
setting, not tied to any specific ring.  Both of these are simply because 
PARI has no (explicit) concept of polynomial rings and power series rings.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 computing 1/f does the O(x^20) arise; the 
default precision is used here because the result cannot be expressed as a 
power series with infinite precision.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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.  Uses $O(n^3)$ 
scalar operations, but suffers from coefficient explosion unless the base 
field is finite or $\R$.  Since the determinant is just the constant term 
of the characteristic polynomial, this looks safe for the determinant as 
well.

I guess the question whether we should use Sage's built-in Hessenberg 
algorithm or PARI's matdet() comes down to which of the two is faster.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

 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. 


Well, it should also be fixed for a RealField of higher precision.  An easy 
solution for that is to use PARI, which uses a numerically more stable 
algorithm (Gaussian elimination, choosing pivots of maximal absolute value; 
I don't know about proven error bounds).  Example:

sage: A._pari_().matdet()
16801.7979988279  # same as when doing the computation over QQ

Sage's determinant() already uses PARI over Z/nZ for n less than the 
machine word size; it would be trivial to adapt it to work also over the 
reals.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 any mathematical interpretation).  If at some 
point it is decided that conversions should have some nice properties (e.g. 
being actual maps with some mathematical meaning, or (partial) sections of 
them), then it would make more sense to make them some map-like type, but 
that wouldn't really be the concept that is now called conversion.

I don't think we really need domain and codomain anyway. It also means that 
 in a lot of cases, one could simply store to codomain rather than a map 
 wrapping a call to the codomain.


Except that currently (if A is the codomain) A.__call__() looks for a 
conversion and calls it, where the default conversion consists of calling 
A._element_constructor_(), so just letting the conversion f be the callable 
A itself instead would create a circularity (A(x) = A.__call__(x) = f(x) = 
A(x) = ...).  To implement your proposal, one could return lambda x: 
return A._element_constructor_(x) as the conversion.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 lifting to ZZ:

sage: GF(7)(GF(11)(7))
0

The reason why this syntax works is the same as the problem from #11239 
that started this thread, namely that conversion (as opposed to coercion) 
is done with very little checking.

It gets worse: another disastrous consequence is that one can construct an 
element of an empty set.

sage: f = GF(11).convert_map_from(GF(7))
sage: f
Conversion map:
  From: Finite Field of size 7
  To:   Finite Field of size 11
sage: f.parent()
Set of field embeddings from Finite Field of size 7 to Finite Field of size 
11
sage: H = f.parent()
sage: H.order()
0
sage: H.list()
[]
sage: f in H
True

Not a very good way to start the new year!

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 the set of 
 all maps and the set of all morphisms. 


That seems to be the only reasonable solution.

I would like to add that in my opinion the first line of this example,

sage: f = GF(11).convert_map_from(GF(7))

should not be assumed to work at all, and it would be preferable to raise 
an error rather than returning something that is mathematically completely 
arbitrary.

Given the principle that no conditions are imposed on conversions (except 
that if a coercion exists, the conversion equals the coercion), it should 
in particular be perfectly fine if some of them do not satisfy the property 
of existing at all.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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
 Basically the generators of the finite fields are just exchanged, even 
 when the characteristics are different.
 The changes suggested in this ticket would more or less only let a 
 coercion be used if there is one, and rant if the characteristics are 
 different or the base finite fields are not part of a common lattice when 
 there is no canonical embedding.

 Note though that the original disturbing conversion fits with the current 
 behavior described in the doc:
 * 
 http://www.sagemath.org/doc/reference/coercion/index.html#maps-between-parents
 where it's stated that

 Conversions need not be canonical (they may for example involve a choice 
 of lift) or even make sense mathematically (e.g. constructions of some 
 kind).

 Anyone has a strong opinion about what we should let Sage do in such a 
 situation?

I posted a comment at #11239, so let me just say here that I think this 
principle (that conversions need not be canonical) shouldn't be pushed 
further than reasonable.  For example, if K is a field and f, g in K[x] are 
polynomials, then applying a conversion K[x]/(f) - K[x]/(g) is a sensible 
thing to do if g divides f (the canonical map) or if f divides g (the 
lifting map).  However, I don't see why it is important to insist that the 
composition of two such maps (e.g. K[x]/(f) - K[x] - K[x]/(g) when f, g 
have nothing to do with each other) should again be a valid conversion that 
can be invoked with the same ease.  Hence I think that R(h), for R = 
K[x]/(g) and h in L[x]/(f), should only be allowed when K has a canonical 
map to L and either f divides g (in L[x]) or vice versa.  This should cover 
almost all practical uses, and in the rare remaining cases it seems better 
to require being a bit more explicit and doing the conversion in two steps.

Should we leave the old conversion when there is no coercion even though 
 that might easily to wrong mathematical results for a careless user? Or 
 never look for a coercion unless the user explicitly asks for it (i.e. what 
 the situation is currently in Sage without the patches of the ticket)?

I thought that conversion should always give the same result as a coercion 
map whenever one exists; is there any (intended) situation where this is 
not the case?

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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. For example, you 
 couldn't even say that you have a conversion from K[x]/(f) to 
 K[x]/(g), since a conversion is not a map. It is a *partial* map, 
 hence, it often is the case that only polynomials of degree zero can be 
 converted and higher degree polynomials result in an error. 


Sure, that still counts as reasonable for me.
 

   For example, if K is a field and f, g in K[x] are 
  polynomials, then applying a conversion K[x]/(f) - K[x]/(g) is a 
 sensible 
  thing to do if g divides f (the canonical map) or if f divides g (the 
  lifting map).  However, I don't see why it is important to insist that 
 the 
  composition of two such maps (e.g. K[x]/(f) - K[x] - K[x]/(g) when f, 
 g 
  have nothing to do with each other) should again be a valid conversion 
 that 
  can be invoked with the same ease. 

 Hang on. Nobody says that the composition of two conversions A-B and 
 B-C yields a conversion A-C (even if we forget for the moment that 
 conversions are not more than partially defined maps)! Composibility 
 is an axiom for *coercions*, but not for *conversions*. Actially 
 conversion 
 have no axioms worth mentioning. 


Yes, I shouldn't have said insist above, maybe suggest.  I don't know 
if the fact that we have maps K[x]/(f) - K[x]/(g) for arbitrary f, g (or 
Z/mZ - Z/nZ for arbitrary m, n) was intended or just a side effect of not 
doing any checks and just doing conversions if the implementation allows 
it.  However, I'm really not convinced that it is easy for the average user 
to avoid the idea that such conversions apparently have some mathematical 
meaning, just because Sage makes it so easy to do these conversions.

Hence, it would be perfectly fine to have K[x]/(f)-K[x] and 
 K[x]-K[x]/(g) for *all* elements of the involved rings, but 
 no conversion from K[x]/(f)-K[x]/(g), or actually: Only conversion for 
 polynomials of degree zero.


Yes, that is more or less what I wanted to say.
 

 That said, do you really think one should do more or less expensive 
 operations (such as: compute gcd or a prime factorisation) to 
 verify that an easy conversion rule makes sense in a particular case? 


I don't know of an example where one has to do such expensive things; in 
the above examples, it is just a divisibility check.  In the examples of 
K[x]/(f) and Z/mZ, this divisibility check does look like a good sanity 
check to me.

You say it should not be pushed further than reasonable. Is it reasonable 
 to have an expensive test to decide whether or not to apply an easy 
 conversion rule? Recall: Coercions should obey axioms and thus expensive 
 tests may be needed. But why should one have expensive tests for something 
 that has no defined properties? How *could* you possibly test something 
 that has no defined properties?


It depends on how expensive the test is.  If I may play the devil's 
advocate for a moment: why would you want to *use* something that has no 
defined properties?
 

  Hence I think that R(h), for R = 
  K[x]/(g) and h in L[x]/(f), should only be allowed when K has a 
 canonical 
  map to L and either f divides g (in L[x]) or vice versa. 

 Do you claim we should drop conversion entirely? After all, we also have a 
 *coercion* system, and coercions (as opposed to conversions) are supposed 
 to 
 be mathematically consistent. Do you think this would be reasonable? 


No, I am certainly not suggesting that conversion should go away.  Using 
conversion to find preimages in the maps Z - Z/mZ or K[x] - K[x]/(f) is 
something that makes a lot of sense.  But when it comes to being maximally 
permissive in allowing conversions (allowing for example direct conversions 
Z/3Z - Z/2Z): despite some arguments for it (less checking, allowing 
people who really want to do that to save a few keystrokes) I don't see why 
it is a good thing.

If there is a coercion map then conversion must give the same result. 
 Everything else would be a bug.


At least there is no misunderstanding about that!

Best regards,

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 matrices
 with eigenvalues that are not in the fraction field of the base ring
 or in QQbar
 }}}
 I think the cleanest way would be to have an implementation of the
 algebraic closure of Fp. Is there some implementation already
 somewhere ? Otherwise, I will fix it using a splitting field of the
 characteristic polynomial.

Darij is right, there is a very basic implementation of Fpbar in #14990.
Unfortunately, factorisation of polynomials is not yet implemented, but
it should be relatively straightforward.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 
 treatment anyway.

 Thus, before embarking on the laborious task of trying to program such a 
 field, I recommend you first try to find a non-trivial scenario that would 
 genuinely benefit from this work.


Perhaps the constructor of RR should accept a flag specifying whether 
overflow, division by zero, etc. should raise exceptions or silently return 
+/- infinity or NaN.  I think it wouldn't really be that much work (see 
Paul Zimmermann's comment about MPFR internally raising exceptions), 
although I said a case could be made and not I want to implement this.

Anyway, I do think there are realistic possibilities for needless confusion 
when using Sage as a tool to teach people about calculus.  Say I am a 
student who wants to experiment with integration.  It is easy to write some 
Sage code to approximate \int_0^1 f(x) dx using the trapezium rule.  Then 
if I apply this unsuspectingly to f(x) = x^(-1/2), the outcome will be 
infinity (for any step width) since f(0) = infinity.  Since no zero 
division error occurs, I could be led to believe that the value of the 
integral is infinity instead of 2, and I could even explain this to 
myself by noticing that f(x) takes the value infinity somewhere.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 _an_ 
infinity element, and this should of course map to Infinity in the 
InfinityRing under the canonical coercion map.  What is not so clear to me 
is why the +infinity element of RR should compare _equal_ to Infinity (i.e. 
whether the fact that RR(oo) == oo yields True, as William noted, is a good 
thing).

Actually, I'm starting to think that once you allow RR(oo) as a valid 
construction, you should indeed let the coercion framework evaluate RR(oo) 
== oo to True, *but* that the user should be able to construct a variant of 
RR that forbids RR(oo).  I'm thinking of something like the following:

sage: R = RealField(prec=53, exceptions=True)
sage: R(oo)
TypeError: unable to coerce +Infinity (class 
'sage.rings.infinity.PlusInfinity') to a real number
sage: RR(oo)
+infinity
sage: oo in R
False
sage: oo in RR
True
sage: R(NaN)
TypeError: unable to coerce class 'sage.symbolic.constants.NotANumber' to 
a real number
sage: RR(NaN)
NaN
sage: 1/R(0.)
ZeroDivisionError
sage: 1/RR(0.)
+infinity

If you are to introduce special cases, then some things are much worse:

 sage: Zmod(5)(3) in ZZ
 True


Hmm.  This would almost be an argument for more restrictive equality and 
containment testing.  I just discovered this:

sage: Mod(2,6)==Mod(4,8)
True

On the other hand, the following extremely similar example gives the 
opposite (and in my opinion more correct) result:

sage: Mod(1,3)==Mod(2,4)
False

Unfortunately it is hard to think of a simple rule that gives the desired 
behaviour in all of the following cases:

sage: Mod(1, 3) == ZZ(1)
True  # current behaviour; certainly OK
sage: Mod(1, 3) == QQ(1)
False  # current behaviour; probably OK, but True wouldn't be completely 
wrong
sage: Mod(1, 3) == Mod(1, 4)
False  # current behaviour; certainly OK
sage: Mod(1,3) == Mod(1, 6)
True  # current behaviour; probably OK, but False wouldn't be completely 
wrong
sage: Mod(2, 6)==Mod(4, 8)
False  # currently yields True
sage: 2/1 in ZZ
True
sage: Mod(3, 5) in ZZ
False  # currently yields True
sage: Mod(1,3) in Zmod(6)
False  # currently yields True
sage: Mod(2,4) in Zmod(6)
False  # currently yields True

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 not be happy.


I agree too; I don't know why pushout raises an error if m, n are coprime 
instead of returning the zero ring (just to make Mod(1, m) == Mod(1, n) 
evaluate to False?), but it is inconsistent and hopefully unnecessary.  The 
code gives no good reason, just the following comment:

# quotient by gcd would result in the trivial ring/group/...
# Rather than create the zero ring, we claim they can't be 
merged

On the otherhand, will anyone be happy if for 
 coprime m and n, every comparison Mod(a,m)==Mod(b,n) is True since the 
 only place they can be compared is the trivial ring?


It is already a bit dubious to require that two ring elements be equal if 
there is _some_ common non-zero ring that both of them can be coerced into; 
I don't see why Mod(a,m) == Mod(b,n) should be True just because a and b 
happen to be equal mod gcd(m,n) when that gcd is smaller than both m and n.

I don't know if Sage uses exactly the same rules to find a common parent 
for comparison as it does for arithmetic operations, but it certainly looks 
like that is the case.  I could imagine stricter rules for finding such a 
parent for comparison.  An algorithm that at least makes my list of 
examples work is the following:

1) to evaluate a == b: if A (resp. B) is the parent of a (resp. b) and P 
is the push-out of A and B (tensor product in the case of rings), then a 
== b yields True if and only if the images of a, b in P are equal *and* at 
least one of A, B maps injectively to P

 sage: Mod(1, 3) == ZZ(1) 
  True  # with P = Zmod(3)
  sage: Mod(1, 3) == QQ(1) 
  False  # P is the zero ring
  sage: Mod(1, 3) == Mod(1, 4) 
  False  # P is the zero ring
  sage: Mod(1,3) == Mod(1, 6) 
  True  # P = Zmod(3)
  sage: Mod(2, 6)==Mod(4, 8) 
  False  # P = Zmod(2)
  sage: 2/1 in ZZ 
  True  # P = QQ


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 above, but asymmetric w.r.t. A, B).

 sage: Mod(3, 5) in ZZ 
  False  # P = Zmod(5)
  sage: Mod(1,3) in Zmod(6) 
  False  # P = Zmod(3)
  sage: Mod(2,4) in Zmod(6) 
  False  # P = Zmod(2)


Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

 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 above, but asymmetric w.r.t. A, B).


Somewhat coincidentally, this algorithm also makes Infinity in RR 
evaluate to False: in this situation a = Infinity, A = InfinityRing, B = 
RR, P = InfinityRing, and the coercion map B - P is not injective, so the 
result is False.  On the other hand, applying rule 1 to RR(Infinity) == 
Infinity still yields True.

The coercion map RR - InfinityRing does not currently know that it is not 
injective, but this should be easy to fix.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

 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 from GF(5) to the push-out 
(also GF(5)) which is injective.

On the other hand, Mod(1, 5) in ZZ would be False in my proposal because 
here it is specifically the map ZZ - GF(5) that should be injective for 
the result to be True.

This would be inconsistent with what is done in several other math 
 software packages: 

 PARI: 
 ? Mod(2,5) == 2 
 %1 = 1 

 Magma: 
  GF(5)!2 eq 2; 
 true 


 Consistency with the choices of other systems for basic things like 
 this has some relevance... 

 
I absolutely agree.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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. 

 thank you for the pointer. However for questions whether Inf should be in 
 RR 
 or not, the MPFR documentation does not say much. About this topic, I 
 recommend to look at the discussions around the P1788 standard for 
 interval 
 arithmetic : http://grouper.ieee.org/groups/1788/. 

 
I did not have time to look at any of this material yet, but I think it is 
good to point out that there are different questions here.  I think it is 
not very controversial that a system for floating-point arithmetic includes 
+/- infinity and NaN as special values.  However, one can argue to what 
extent these should be regarded as valid numbers, e.g. which operations on 
finite real numbers should be extended to these special values.  Of 
course, it is true that numerical analysts and programmers have thought 
deeply about this; however, Sage users coming from other fields of 
mathematics will not expect this behaviour (which is why I was baffled by 
Infinity in RR).  In other words, the fact that RR is a fairly thin 
wrapper around MPFR has good and bad sides.

As for NaN, this can hardly be viewed as anything else than a kind of error 
code.  It is still treated as an element of RR, though:

sage: NaN in RR
True
sage: parent(NaN)
Symbolic Ring
sage: n = RR(NaN)
sage: n
NaN

For +/- infinity, it at least looks reasonable to treat these as 
pseudo-numbers on which most operations still make sense.  This is what 
Sage's RR does; it is actually closer to the extended real line (the union 
of {-infinity}, the reals and {+infinity} with the expected topology) than 
to the reals alone.

At the same time +/- infinity do also play the role of error codes, namely 
for overflow and underflow:

sage: 2.^(2.^(2.^10))
+infinity

If one views RR as a model of the extended real line, then one could say 
that this +infinity is not really an error code, but just another instance 
of rounding.

I think a case could be made for having two versions of the current RR: one 
like the current one (more like a model of the extended real line) and one 
where overflow or division by zero raises an exception instead of returning 
+/- infinity (more like a model of the usual real numbers).  I can think of 
at least two reasons for having the latter:

(1) it has a better field-like behaviour; this will always be imperfect due 
to rounding errors, but not having infinity avoids many violations of the 
field axioms;

(2) it interacts better with the complex numbers; R embeds into C and this 
extends to an identification of R + R*i with C, but the current 
implementation acts as if this is true with R replaced by the extended real 
line.  This leads to the undesirable fact that Sage's CC now contains many 
different infinities (namely, all a + b*i where at least one of a, b is 
infinite; note that this is completely different from e.g. having all 
r*exp(i*t) with r = Infinity and t in [0, 2*pi), as well as from the fact 
that in the usual compactification of C (the Riemann sphere) there is only 
one point at infinity).  The question that Greg originally posed (why 
imag(CC(infinity)) = 0 instead of undefined) stems from this.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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_coerce_map_from(RR)
 True


Right, from that perspective it is hard to argue that there is a bug.
 

 As far as I can see, to make RR(oo) == oo evaluate to False (or give an 
 error), while staying consistent with the coercion framework, one would 
 need to either
 - disallow the explicit conversion RR(oo), or
 - remove the automatic coercion from RR to InfinityRing, or
 - make InfinityRing(RR(oo)) finite.


The only two options that seem acceptable to me are
- disallowing RR(oo) (if RR is taken to represent the field of real numbers 
as opposed to the extended real line);
- making the in keyword treat infinity as a special case.  This could be 
defended by saying that representing infinity in RR or CC is possible for 
convenience, but should not be viewed as an instance of set-theoretical 
containment.  I think this is similar to saying that +0.0 and -0.0 are 
represented differently in our implementation of floating-point arithmetic, 
but should be regarded as equal by comparison operators.

The following all make sense and look useful:

 sage: UnsignedInfinityRing.has_coerce_map_from(RR) # natural map RR -- 
 {finite, infinite}
 True
 sage: UnsignedInfinityRing.has_coerce_map_from(CC) # natural map CC -- 
 {finite, infinite}
 True
 sage: InfinityRing.has_coerce_map_from(RR) # natural map RR -- { -oo, 
 negative, 0, positive, +oo}
 True
 sage: InfinityRing.has_coerce_map_from(CC) # no natural map CC -- { -oo, 
 negative, 0, positive, +oo}
 False


Yes, I cannot think of any reason to change this.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Trac editor sucks

[Peter Bruin]

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 same problem from time to time (I use both Firefox and Chrome; I 
_think_ it only occurs with Chrome for me).

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

 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 
number.  This is related to the following questionable behaviour:

sage: Infinity in RR
True

This arises because the internal representation of floating-point numbers 
allows (+/-)Infinity as special values.

On the other hand:

sage: Infinity in CC
False

sage: RR.is_subring(CC)
Traceback (most recent call last):
...
NotImplementedError

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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  CC(infinity,0), 
 CC(0, infinity) and CC(infinity, infinity) are all distinct in sage, giving 
 us 3 different complex infinities.  I'm not particularly picking on CC, 
 since infinity*I and infinity are also not equal.   


If you ask me, neither RR nor CC should contain any kind of infinity.  As a 
piece of mathematical software, Sage must be mathematically correct and not 
pretend that infinity is in RR (or CC).

There is a set of floating point objects and a set of real numbers; they 
have a large intersection, but both of them contain elements that the other 
doesn't.  Plus or minus infinity and not a number are not real numbers; 
conversely, most real numbers, like pi, cannot be represented (only 
approximated) by floating point numbers.

Of course, it is also true that floating point objects can represent 
infinity, and for a good reason.  For example, if you evaluate a 
meromorphic function at a pole, then it is legitimate to say that the 
result is infinity.  It is just not an element of the complex numbers, but 
of the Riemann sphere (the projective line over CC).

For the real numbers, there are two separate completions: first, the 
projective line over RR, which has only one point at infinity and is a 
subset of the Riemann sphere; second, the extended real line containing 
plus infinity and minus infinity.  It depends on the context which one is 
more useful, but both of them are definitely different from RR, because RR 
does not contain any infinite element at all.

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), which says that the infinity ring does not canonically coerce 
into any other ring.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

  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), which says that the infinity ring does not canonically coerce 
  into any other ring. 

 I do not agree. RR and CC are *badly* named in Sage.


Actually, that is more or less what I mean.  I expressed it a bit 
polemically, though, because I think it is a serious problem.

As Peter said, 
 they are sets of floating point numbers. In particular, I found 
 completely valid that Infinity is an element of RR (since it is *not* 
 the set of real numbers).


But you know more about computer floating point arithmetic than most 
people.  Of course many of us realise perfectly how far RR is from the 
field of real numbers, because we have lots of experience with it.  
However, given that Sage will be used more and more for teaching calculus, 
for example, I think Infinity in RR -- True is dangerously misleading.  
The fact that there is an explanation why this behaviour arises (namely, 
that RR is badly named) does not make the problem vanish.

In case this sounds like I would the meaning of RR to change: of course 
this would be practically impossible.  But as I wrote before, Infinity in 
RR -- True also appears to contradict the documentation of the infinity 
ring, since that is not supposed to coerce into other rings.  What I 
would like is that Infinity (the globally named object, which lives in the 
infinity ring) should not designate an element of RR without explicit 
conversion.  While RR (as an implementation of floating point arithmetic) 
should have some elements representing plus/minus infinity and NaN, the 
current behaviour seems too potentially confusing for less experienced 
mathematicians.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 this approximation may differ from what they would
   be if those calculations were performed in the true field of real
   numbers. This is due to the rounding errors inherent to finite
   precision calculations.

Maybe this paragraph should also mention that plus/minus infinity are 
representable in RR, even though they are not real numbers?  After all, 
allowing plus/minus infinity in RR is a choice that is by no means forced 
upon us by working with finite precision.

I'm used to PARI, where multiprecision reals do not include infinity; for 
example, minus infinity as an endpoint for numerical integration has to be 
specified as the 1-element vector [-1].

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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(Infinity)
False
sage: CC(I+Infinity)==CC(2*I+Infinity)
True

See Trac tickets #14088, #11506 and #14857 for other reported problems with 
various infinities.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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.FieldElementMethods, 
 and then assign Fields.ElementMethods = FieldElementMethods. In that way, 
 elements of rings would inherit a method is_unit that probably is faster 
 what we currently have. 


We already have FieldElement, which is a Cython class consisting of 
methods, including is_unit().  Ignoring my opinion about C.ElementMethods 
for a moment, why not just move the existing methods in 
FieldsElementMethods to FieldElement and then set Fields.ElementMethods = 
FieldElement, and similarly for other Element classes?  (With or without 
static inheritance between the Cython classes, whichever makes it work.)

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 dynamically-constructed 
  types). 
  
  But how would the category framework automatically construct a class for 
  square integer dense matrices, for example?  It would still have to know 
  where to get the specialised determinant function from. 

 That's what it does now, by multiple inheritance. It does not provide 
 specialized implementations, only generic ones. 


The second sentence of your answer contradicts the first one.  We have a 
function Matrix_integer_dense.determinant() which only makes sense for 
matrices that (1) live over the integers and (2) are square (let's ignore 
the dense/sparse distinction).  This is not a generic implementation and 
the category framework can't know about this function if it only has the 
classes of matrices over ZZ (without the determinant) and the class of 
square matrices.

So maybe this should be solved by redirection, as you suggested: 
Matrix_integer_dense should have a method _determinant() (which raises an 
error if applied to a non-square matrix) and SquareMatrix should have 
determinant() which just calls self._determinant().

 The primary advantage of RingElement vs Rings().ElementMethods is that 
  one can place cdef methods on the former, in particular to provide 
  fast paths for arithmetic and the coercion system (including its 
  special relationship to ModuleElement). Ideally nothing 
  category-specific should go here (though there should be a big comment 
  at the top that Rings().ElementMethods is a common parent for all 
  RingElements) and actual ring element implementations could descend 
  from RingElement or not as needed/as the implementation allows. In 
  fact, there is very little in RingElement that's not about arithmetic 
  and the coercion model, it could probably be all moved out (with a 
  clear reference in the docstring about Rings().ElementMethods, and in 
  the Element class as well). In particular, the mostly-vacuous 
  hierarchy and deceptive is_X methods starting at 
  
  
 https://github.com/sagemath/sage/blob/8118b2b39e3a129a5a6186fdc9917940f92b87a6/src/sage/structure/element.pyx#L2767
  
  should probably be stripped out. 
  
  
  At least for the is_X methods that just use isinstance, I agree that 
 they 
  should go away; I am not so sure about the XElement hierarchy. 

 What value does it provide?


(I am not so sure was meant literally, not as a strong statement of 
support for XElement.)

It is true that some of the classes (like AlgebraElement) are largely 
vacuous, but as I said in another message in this thread, 
EuclideanDomainElement does seem the right place to put the gcd methods for 
Euclidean domains, especially since it is a Cython class.  Similarly for 
the other methods of EuclideanDomainElement and FieldElement.

On the other hand, if we want to use it as a parent class in multiple 
inheritance (i.e. absorb it into the current 
EuclideanDomains.ElementMethods or my proposed 
EuclideanDomains.Object.Element), then maybe the speed of Cython should 
sacrificed for the flexibility of Python.  I don't know which of the two 
has more advantages.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: pari questions

[Peter Bruin]

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 are or should be implemented in PARI and made accessible in 
Sage, instead of reinventing the wheel in Sage.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: pari questions

[Peter Bruin]

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 the error handler thing 
 on pari-dev 
 http://pari.math.u-bordeaux.fr/archives/pari-dev-1308/msg00014.html and 
 we'll hopefully get a cleaner hook.


Did you see my recent patch on #9640?  It uses the existing callback, and I 
think this approach is quite acceptable after all, since it allows us to 
catch any error messages printed to stderr by PARI.  The alternative would 
be to add another hook before those messages are printed, but that has a 
redundant feel to it and doesn't give us the error text.  I don't think 
adding a second hook would be worth the effort.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 is a special attribute of 
 the Object that the code must handle differently because it cannot simply 
 allow it to be overwritten by (abstract) parent classes.


What do you mean exactly?  Which code must handle Element differently, and 
what does overwriting Element mean?  There is already code that handles 
C.ElementMethods and Parent.Element specially for constructing 
P.element_class for parent instances P.  What I am proposing is that in 
concrete categories C (subcategories of Sets), C.Object should be an 
instance of Parent, and C.ElementMethods should be merged into 
C.Object.Element.  The latter should then be used (for C.Object itself and 
for Object classes of supercategories) to construct P.element_class, in a 
similar way as C.ElementMethods and Parent.Element are used now.

In terms of functionality, C.Object and C.Object.Element would be the place 
to _logically_ put the code of the existing (and partially deprecated) 
static inheritance hierarchy of all the various types of rings and the 
corresponding *Element classes.  The _actual_ placement of the code for 
these classes could by either inline (as with C.ElementMethods) or by 
setting C.Object = MyParent and MyParent.Element = MyElement, where 
MyParent and MyElement can be defined in separate files.

For the concrete example of Euclidean domains that has been discussed, the 
proposal would be to
- move EuclideanDomain to EuclideanDomains.Object
- move EuclideanDomainElement to EuclideanDomains.Object.Element
- merge EuclideanDomains.ElementMethods into EuclideanDomains.Object.Element
- if a parent P is constructed and determined to be a Euclidean domain:
- - make P dynamically inherit from EuclideanDomains.Object, and from 
Object classes of supercategories of EuclideanDomains
- - make P.element_class dynamically inherit from 
EuclideanDomains.Object.Element and from Object.Element classes of 
supercategories of EuclideanDomains.

The advantages would be:
(1) the relation Category - Parent - Element is better respected by not 
letting categories prescribe the behaviour of elements directly, but only 
via parents;
(2) at the moment there seems to be some confusion about what should be in 
ElementMethods and what should be in Element classes.  For myself, this 
confusion is largely caused by the fact that ElementMethods are attached to 
categories instead of parent classes.  In the above picture, it is clearer 
where methods belong.

Among the various Element classes, some of them might be Cython classes, 
but one would have to be careful in saying which ones are allowed to be 
(because of multiple inheritance).  I assume more of the inheritance would 
have to be specified by hand, but maybe less so than in the existing 
*Element hierarchy.

All of this is probably not so different from what the experts mean by 
moving something to the category framework, and many of my thoughts about 
this might just be repeating other people's ideas of how to do this.  
Again, the thing I want to stress is that I think it should be done in a 
way that clearly reflects the Category - Parent - Element relation.  In 
fact, thinking of Volker's remark that the category framework is not 
necessarily about mathematical categories, I am tempted to think of it as 
the category-parent-element framework instead.

Is is also not clear that inheritance in categories and the parent classes 
 could not come into conflict. Basically I'm worried about a diamond-type 
 problem, suppose we have the categories C1 and C2 and parents P1 and P2 
 with the following inheritance structure:

 C1.E - C2.E
 ^^
 | |
 P1.E - P2.E

 where X.E denotes the element class. In particular, P1.E gets methods from 
 C1.E, which are then inherited by P2.E and could override C2 
 implementations from C1. With the current way of having it be 
 ElementMethods, there's no confusion where the methods are coming from. 
 Maybe I'm just being somewhat paranoid about things (or more likely missing 
 or not understanding something)?


That would not be an issue in my proposal, because it would move all the 
element classes to the parents, so the Ci.E would not exist anymore.  Where 
the categories come in is when the subcategory relation is used to 
_construct_ the Pi.element_class, as in the above example for Euclidean 
domains.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.

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

[Peter Bruin]

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 -*-) ? 

 That wouldn't help since the offending character is on the *first* line, 
 before the coding line. 


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.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

 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, then there is little you can do.)

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 
 declares its category as EuclideanDomains.


Yes, I just added this to emphasise that I do want this to happen via the 
category framework and not via static inheritance.
 

 The difference between your proposal and what currently exists are 

 (1) The Element[Methods] class is attached to the category's 
 ParentMethods, rather than the category itself


Exactly; this is what I would like to be the case.  I don't propose any 
other changes except the ones needed to make this possible.
 

 (2) The Element and Object method classes are required to inherit from 
 Element and Parent directly. I don't see what value this adds, as the 
 concrete R.element_class values will already have this property. 


I don't think it is important whether Element and Object inherit from 
Element and Parent; this was just to stress that they could inherit from 
the same class, or none at all, for every element class.

 Less importantly, I would also prefer ParentMethods to be called Object, 
  ObjectClass or something similar, both because objects needn't be 
 parents 
  and because the class in question could have other attributes that are 
 not 
  methods. 

 Yeah. Unfortunately, we have object and SageObject that mean entirely 
 different things. There is also CategoryObject which is a superclass 
 of Parent (=Object in the category of Sets). Element doesn't actually 
 makes sense on CategoryObject. 


I agree.  But it would be an attribute of Category, not a global 
identifier, so if one uses C.Object for a category C then it is hopefully 
clear that it refers to category objects, not to Sage or Python objects.  
C.ObjectClass would be slightly clearer in my opnion.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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

 class EuclideanDomain(IntegralDomain): 
Element = EuclideanDomainElement 

 class EuclideanDomains(IntegralDomains): 
 ParentMethods = EuclideanDomain 

 instead of 

 class EuclideanDomainElement: 
 def xgcd(self, other): 
 ... 

 class EuclideanDomain: 
 ... 

 class EuclideanDomains(IntegralDomains): 
 ElementMethods = EuclideanDomainElement 
 ParentMethods = EuclideanDomain 


No, I want

class IntegralDomainElement(Element):
... 

class IntegralDomain(Parent):
Element = IntegralDomainElement

 class EuclideanDomainElement(Element):
 def xgcd(self, other): 
 ...
 class EuclideanDomain(Parent): 
 Element = EuclideanDomainElement

class IntegralDomains(Category_singleton):
ParentMethods = IntegralDomain

class EuclideanDomains(Category_singleton):
ParentMethods = EuclideanDomain

def super_categories(self):
return [IntegralDomains()]

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.

Less importantly, I would also prefer ParentMethods to be called Object, 
ObjectClass or something similar, both because objects needn't be parents 
and because the class in question could have other attributes that are not 
methods.

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 ElementMethods.  (clarification: as opposed to an example showing how 
ElementMethods is implemented or how it can be used.)

Here is what kind of example I have in mind: a realistic computation where 
the user, in order to solve his problem, is led to a situation where all of 
the following Sage objects exist, and where, most importantly, the last 
condition holds:

- C: instance of Category whose ElementMethods contains a non-trivial 
method m
- P: instance of Parent that is an object in the category C (or, if 
necessary, multiple P_1, ..., P_n in the same C)
- e: instance of P.element_class that is an element of P (or, if necessary, 
multiple e_i in the various P_j)
- x: the result of a computation involving e (or the e_i) for which it was 
necessary to invoke C.ElementMethods.m
- in a hypothetical version of Sage in which the method m is in a subclass 
of Element, it would have been impossible, or at least much harder, for the 
user to obtain x via a similar approach where e is an instance (or the e_i 
are instances of) of this subclass (either statically or dynamically).

Even after studying several of the ElementMethods classes in 
sage/categories, I cannot think of such an example.  (Since square matrices 
and polynomial factorisation came up in this discussion: I did think 
whether these gave rise to such an example).  I fully admit that this could 
be because of a lack of creativity or experience with the category 
framework.  I am also open to any other kind of example that will convince 
me that there is no good alternative to ElementMethods that is based on 
putting the methods in the correct Element classes.  What is important is 
that I am looking for realistic and completely concrete examples.

If someone can give me an example, then my plan is to look especially 
critically at the last condition and try to show that it using the 
alternative approach would in fact be equally natural for the user in a 
hypothetical version of Sage as above.  (By this hypothetical version, I 
mean one that chiefly differs from the actual Sage with respect to the 
general implementation of providing elements with methods, i.e. is not 
tailored specifically to the specific example in question, of course.)

For clarity, let me finally compress my motivation into a caricature (and 
do please view this as just a caricature):
- I have the impression that there are good conceptual (or aesthetic, if 
you want) reasons to get rid of the attribute ElementMethods in Sage 
categories;
- I can think of a promising alternative approach that would get rid of 
this attribute;
- before wasting too much time, I want to check if my impression above 
really isn't completely idiotic, and I am trying to be as explicit as 
possible about what kind of example would make me change my opinion.

 I did read that, but it didn't quite suffice to make everything clear for 
  me.  Also, there were some occurrences like TODO: example that made me 
  wonder if there would really be a natural example. 

 I just checked: The string TODO or todo does not appear in the 
 thematic tutorial coercion_and_categories.html (title: How to implement 
 new algebraic structures in Sage). So, what have you been reading? 


I read sage/categories/primer.html and sage/categories/tutorial.html, and 
various docstrings in sage/categories; I didn't remember the exact titles 
and thought you were referring to the first of these.

In the meantime, I have also read coercion_and_categories.html, but I don't 
think the example in there can easily be made into an example of the kind I 
am looking for.

I hope you anyone else doesn't feel like they are wasting their time in 
this discussion, and that at least something useful will come out of it for 
others who want to understand (and possibly extend or modify) the category 
framework.

Thanks,

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

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 there are many different matrix implementations specialized 
 on the basering for efficiency (e.g. finite fields of various sizes, 
 ZZ, QQ, number fields, etc.) Would you suggest that we create 
 SquareIntegerMatrix, SquareRationalMatrix, etc?


Good question.  Given that we have, for example, a specific function for 
computing the determinant of a square dense matrix over the integers, and 
there is no specific class for such matrices, either such a class has to be 
made (split off from the class of such matrices that are not necessarily 
square) or we have to accept that this specific function cannot be applied 
to all elements that it is a method of.  And maybe it is actually more 
user-friendly in this case: it is nicer to get an error message telling you 
that you are trying to take the determinant of a non-square matrix than the 
AttributeError that would arise if non-square matrices didn't have a 
determinant method at all.

Of course to spare 
 some work one would want a common SquareMatrix that all of these 
 (multiply) inherit from. (One technicality is that SquareMatrix could 
 not inherit from RingElement if the base IntegerMatrix class does not 
 as they would have incompatible C layouts.)


That is also a good point, and one that seems hard to solve.
 

 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 dynamically-constructed 
 types). 


But how would the category framework automatically construct a class for 
square integer dense matrices, for example?  It would still have to know 
where to get the specialised determinant function from.

Another good example of this is polynomials. There are various 
 sparse/dense representations implemented over various representations 
 of rings. Whether this is a UDF or PID depends on the category of the 
 basering, trying to (manually) bake this into the inheritance of 
 elements is painful. But there are some methods that can be 
 *automatically* provided if the category is right (e.g. gcd).


I don't understand this.  Whether the polynomial ring is a UFD or PID 
depends on the base ring, and that is it.  I don't see why it matters in 
which category you put it.  In practice, I think the following rules are 
often enough: for a ring A, one has
A is a field = A is Euclidean = A is a PID = A is a UFD
A is a field = A[x] is Euclidean
A is a UFD = A[x] is a UFD
You seem to be saying one of two things, and I'm not sure which:
- either your phrase depends on the category of the basering has the same 
meaning as depends on whether the basering is a UFD, PID, etc.;
- or you mean that for the same ring A, elements of A[x] should use a 
different gcd implementation depending on whether the user has put A into a 
larger category (so that the gcd of two polynomials is computed by 
factoring them instead of via the Euclidean algorithm).

The primary advantage of RingElement vs Rings().ElementMethods is that 
 one can place cdef methods on the former, in particular to provide 
 fast paths for arithmetic and the coercion system (including its 
 special relationship to ModuleElement). Ideally nothing 
 category-specific should go here (though there should be a big comment 
 at the top that Rings().ElementMethods is a common parent for all 
 RingElements) and actual ring element implementations could descend 
 from RingElement or not as needed/as the implementation allows. In 
 fact, there is very little in RingElement that's not about arithmetic 
 and the coercion model, it could probably be all moved out (with a 
 clear reference in the docstring about Rings().ElementMethods, and in 
 the Element class as well). In particular, the mostly-vacuous 
 hierarchy and deceptive is_X methods starting at 

 https://github.com/sagemath/sage/blob/8118b2b39e3a129a5a6186fdc9917940f92b87a6/src/sage/structure/element.pyx#L2767
  
 should probably be stripped out.


At least for the is_X methods that just use isinstance, I agree that they 
should go away; I am not so sure about the XElement hierarchy.

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Peter Bruin]

 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 performance reasons).


I would suggest that [x]gcd should be a method of the 
EuclideanDomainElement class (as it currently is).  In the modified 
framework that I am thinking of, suppose the user constructs an instance R 
of the class Ring (or a subclass) that is a priori not Euclidean.  Suppose 
also that R is detected to be Euclidean during construction (e.g. because R 
= PolynomialRing(A) and A happens to be a field) and placed in 
EuclideanDomains.  Then, instead of making EuclideanDomains add its 
ElementMethods to R.element_class, I propose that the following should 
happen:

R will be made an object in the category EuclideanDomains;
EuclideanDomains has an attribute Object, which equals the class 
EuclideanDomain;
therefore, EuclideanDomains has a dynamically generated object_class 
inheriting from EuclideanDomain;
R will dynamically be made an instance of EuclideanDomains.object_class (by 
using EuclideanDomain as a base class or via some __getattr__());
hence R will dynamically inherit from EuclideanDomain;
furthermore, EuclideanDomain (being a subclass of Parent) has an attribute 
Element, which equals the class EuclideanDomainElement;
therefore, R has a dynamically generated element_class inheriting from 
EuclideanDomainElement;
R.element_class will dynamically be made to inherit from 
EuclideanDomain.element_class;
hence R.element_class will dynamically inherit from EuclideanDomainElement, 
and have the correct gcd method.

As you see, I am absolutely not trying to avoid the category framework; I 
think this approach uses it just as much as the existing one.  The 
difference is that the category of Euclidean domains no longer directly 
specifies element behaviour, but does it via its object class, which I 
would find much more satisfactory.  Assuming that something like the above 
would work, of course!

Peter

-- 
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.