This should be easy, and it's a potential source of library conflicts,
as gmp is often installed...

note that GMP is pulled in via `./configure --with-mp=gmp`
(as well as by specifying SAGE_MP_LIBRARY?)

**Configure:**
http://users.ox.ac.uk/~coml0531/sage/configure-316.tar.gz

URL: https://trac.sagemath.org/27212
Reported by: dimpase
Ticket author(s): Erik Bray, Dima Pasechnik
Reviewer(s): Dima Pasechnik

E. Madison Bray authored Feb 20, 2019 and Dima Pasechnik committed Apr 18, 2019

gmp.h for the version of GMP you want to use when building it

when passing --with-gmp-include it also requires a value for --with-gmp-lib;
for the vast majority of cases just replacing 'include' with 'lib' in the
include path should suffice; regardless it is less picky about this, especially
when using the system GMP (in which case it will be used naturally by the
linker via the standard library search path)

E. Madison Bray authored Feb 19, 2019 and Dima Pasechnik committed Apr 18, 2019

it can be used to get the absolute path to an existing header (basically
by running some code through the C preprocessor and grepping it out)

Hate to add another SAGE_GMP_ variable, but this can be useful for configuring
iml to use the correct system GMP

E. Madison Bray authored Feb 12, 2019 and Dima Pasechnik committed Apr 18, 2019

The SAGE_MP_LIBRARY variable should really only have either the values
"gmp" or "mpir" (i.e. actual package names, as opposed to "system").

When using the system GMP we just set its value to "gmp" (whether or
not it's actually MPIR).  In this case it's just a placeholder since we're
not installing either SPKG anyways.

E. Madison Bray authored Feb 12, 2019 and Dima Pasechnik committed Apr 18, 2019

$SAGE_CONFIGURE_GMP variable that is defined in sage-env-config and
set at configure time.

E. Madison Bray authored Feb 12, 2019 and Dima Pasechnik committed Apr 18, 2019

is local to where it is used

Also, most of the logic is in mpir/spkg-configure.m4 rather than
gmp/spkg-configure.m4 just because MPIR is the implementation we install by
default if it can't be used from the sytem.  It could go either way, but this
way seemed a bit more logical for that reason.

Then, the gmp/spkg-configure.m4 is mostly just a stub.

Finally, uses the symbol __gmpq_cmp_z to check for GMP>=6.1.0 (or whatever the
equivalent MPIR is).

URL: https://trac.sagemath.org/27671
Reported by: chapoton
Ticket author(s): Frédéric Chapoton
Reviewer(s): Travis Scrimshaw

only details, code and doc refreshing

URL: https://trac.sagemath.org/27661
Reported by: chapoton
Ticket author(s): Frédéric Chapoton
Reviewer(s): Travis Scrimshaw

Mark some `long(...)` tests as `# py2`, and also deprecate the
`__long__` method.

URL: https://trac.sagemath.org/27675
Reported by: jhpalmieri
Ticket author(s): John Palmieri
Reviewer(s): Travis Scrimshaw

URL: https://trac.sagemath.org/27668
Reported by: chapoton
Ticket author(s): Frédéric Chapoton
Reviewer(s): David Coudert

by changing the repr, so that frozensets are handled the same in py2 and
py3

URL: https://trac.sagemath.org/27667
Reported by: chapoton
Ticket author(s): Frédéric Chapoton
Reviewer(s): Daniel Krenn

In Sage 8.8.beta1, as well as in Sage 8.6 and 8.7, we have
{{{
sage: M = Manifold(2, 'M')
sage: X.<x,y> = M.chart()
sage: f = M.scalar_field(x)
sage: f in M.diff_form_module(0)  # OK
True
sage: f in M.diff_form_module(1)  # Bang!
...
AttributeError: 'list' object has no attribute '_sage_'
}}}
Full log is attached.

URL: https://trac.sagemath.org/27658
Reported by: egourgoulhon
Ticket author(s): Eric Gourgoulhon
Reviewer(s): Travis Scrimshaw

Consider a manifold covered by two coordinate charts:
{{{
sage: M = Manifold(2, 'M')
sage: X.<x,y> = M.chart()
sage: Y.<u,v> = M.chart()
sage: X_to_Y = X.transition_map(Y, [x+y, x-y])
sage: Y_to_X = X_to_Y.inverse()
}}}
and define a vector field from its components in the manifold's default
vector frame:
{{{
sage: M.default_frame()
Coordinate frame (M, (d/dx,d/dy))
sage: M.default_chart()
Chart (M, (x, y))
sage: v = M.vector_field(-y, x, name='v')
sage: v.display()
v = -y d/dx + x d/dy
}}}
Currently (Sage 8.7), if we would like to express `v` in terms of the
coordinates `(u,v)`, we have to write
{{{
sage: v.display(Y.frame(), Y)
v = v d/du - u d/dv
}}}
This is because the first argument of `display` is the vector frame with
respect to which the expansion of `v` is performed and the second
argument is the chart in which the components are expressed. If the
latter is omitted, the default chart is assumed:
{{{
sage: v.display(Y.frame())
v = (x - y) d/du + (-x - y) d/dv
}}}

Now, it occurs quite often that one wants to express a tensor field
entirely in terms of a given chart, i.e. with the components w.r.t. the
coordinate frame associated to the chart and each component being
expressed in terms of the coordinates of the chart. In Sage 8.7, if `Y`
is not the default chart, this is possible only through
`v.display(Y.frame(), Y)`. This ticket introduces the possibility to
pass only the chart to  `display`, with the understanding that the
vector frame with respect to which the expansion is to be performed is
the coordinate frame associated with this chart. In other words,
`v.display(Y.frame(), Y)` can now be shorten to `v.display(Y)`:
{{{
sage: v.display(Y)
v = v d/du - u d/dv
}}}

URL: https://trac.sagemath.org/27655
Reported by: egourgoulhon
Ticket author(s): Eric Gourgoulhon
Reviewer(s): Travis Scrimshaw

This project is my master thesis. I want to implement a computation of
characteristic classes of vector bundles out of their curvature
matrices. The algorithm is based on [https://www.math.uni-
potsdam.de/fileadmin/user_upload/Prof-
Geometrie/Dokumente/Lehre/Lehrmaterialien/charakteristisch.pdf this]
short script.

In this first step, the graded algebra of "mixed" differential forms of
a manifold will be introduced so one can use the matrix framework of
sage in the following steps.

A demo notebook is provided at
https://github.com/DeRhamSource/MixedFormNotebook

URL: https://trac.sagemath.org/27584
Reported by: gh-DeRhamSource
Ticket author(s): Michael Jung
Reviewer(s): Eric Gourgoulhon, Travis Scrimshaw

This ticket introduces a modified version of Kruskal and is called
filter-kruskal as suggested in the paper:
        http://algo2.iti.kit.edu/documents/fkruskal.pdf
This algorithm avoids the sorting of a large dataset by partitioning the
list of edges using a pivot. Its time complexity is approximately equal
to O(m) where m=number of edges.
I have implemented this new algorithm and it is passing all the tests.
Currently, it takes approximately equal time as compared to Kruskal
algorithm of sagemath. But, it can be further optimized.

URL: https://trac.sagemath.org/27482
Reported by: gh-Hrishabh-yadav
Ticket author(s): Hrishabh Yadav
Reviewer(s): David Coudert

It is natural to write the elements of the (differential) Weyl algebra
with the differentials factored out (on the right). This is a common
expression for the elements in the single variable case.

With this branch
{{{
sage: R.<t> = QQ[]
sage: D = DifferentialWeylAlgebra(R)
sage: t,dt = D.gens()
sage: x = dt^3*t^3 + dt^2*t^4
sage: x
t^3*dt^3 + t^4*dt^2 + 9*t^2*dt^2 + 8*t^3*dt + 18*t*dt + 12*t^2 + 6
sage: D.options.factor_representation = True
sage: x
(12*t^2 + 6) + (8*t^3 + 18*t)dt^1 + (t^4 + 9*t^2)dt^2 + (t^3)dt^3
}}}

URL: https://trac.sagemath.org/27442
Reported by: tscrim
Ticket author(s): Travis Scrimshaw
Reviewer(s): Daniel Krenn

Implement groups that handle complex arguments, points on the unit
circle, roots of unit etc.

These groups are needed for growth groups of asymptotic rings in
relation to #26587.

URL: https://trac.sagemath.org/26588
Reported by: dkrenn
Ticket author(s): Daniel Krenn
Reviewer(s): Benjamin Hackl

URL: https://trac.sagemath.org/26498
Reported by: dkrenn
Ticket author(s): Daniel Krenn
Reviewer(s): Benjamin Hackl

They currently assume a dense matrix and set a lot of 0 values if the
matrix sparse. We can give a better construction.

URL: https://trac.sagemath.org/24138
Reported by: tscrim
Ticket author(s): Travis Scrimshaw
Reviewer(s): Daniel Krenn

Every file or directory in the upstream tarball for elliptic_curves
contains a corresponding `._<filename>` file containing OSX-specific
"extended attributes" for the file.  Those should be stripped out when
creating the tarball.

Is this just a Sage issue or a problem upstream as well?  It's not
always clear to me since I'm not sure if/when we're using unmodified
source tarballs.

I have made a new tarball here:

http://chapoton.perso.math.cnrs.fr/elliptic_curves-0.8.1.tar.bz2

URL: https://trac.sagemath.org/20717
Reported by: embray
Ticket author(s): Frédéric Chapoton
Reviewer(s): Erik Bray

Merge branch 'public/linear_algebra/improve_sparse_right_kernel-24138' of git://trac.sagemath.org/sage into public/linear_algebra/improve_sparse_right_kernel-24138