1. 04 Nov, 2017 1 commit
  2. 21 Aug, 2017 1 commit
  3. 20 Aug, 2017 11 commits
    • Release Manager's avatar
      Trac #23622: LatticePoset doc, use the master bib file · e5005bdf
      Release Manager authored
      This patch will a) move references to the master bibliography file and
      b) unify order of examples- and seealso-blocks in `lattices.py`. #23597
      did the same for `posets.py`.
      URL: https://trac.sagemath.org/23622
      Reported by: jmantysalo
      Ticket author(s): Jori Mäntysalo
      Reviewer(s): Travis Scrimshaw
    • Release Manager's avatar
      Trac #19339: Use digraph labels if present for ClusterAlgebra and ClusterQuiver · e87f9b5a
      Release Manager authored
      '''Information from Gregg Musiker'''
      I recently realized that if one starts with a digraph `D` (with vertices
      labeled however) and then writes
         `S = ClusterSeed(D)`, then the code will effectively call
         `Q = ClusterQuiver(D)` and then assign `S = ClusterSeed(Q)`.
      In the same spirit as the last ticket, I think it makes sense to add
      other vertex names to `ClusterQuiver` and allow these to be passed on to
      `ClusterSeed`.  Since we only changed the behavior of `cluster_seed.py`
      in the last ticket, I believe the behavior of `quiver.py` was
      In particular, if one writes `ClusterSeed(D)` or `ClusterQuiver(D)`,
      then I believe Sage should then use the vertices of digraph as labels
      rather than defaulting to `[0,...,n-1]`.  (Although we will have to
      think somewhat about backwards compatibility.)
      In particular, I'm thinking of two changes.
      1) In `ClusterQuiver.__init__()`, if a digraph is the input, then the
      vertices of `ClusterQuiver` agree with the labels of the vertices of the
      input digraph.  (Although for internal data, sage would also have a
      dictionary from `{0,..., n-1}` to these vertex labels so that it
      understands the "ij-th" entry of the B-matrix for instance.
      2) In `ClusterSeed.__init__()`, if a `ClusterQuiver` is the input, then
      it uses those vertices as labels for the cluster variables as if the
      user had given `user_labels`.
      The only exception would be if the user puts in such a `ClusterQuiver`
      and also `user_labels` as a separate input, then the new `user_labels`
      should override the old ones from the `ClusterQuiver`.
      URL: https://trac.sagemath.org/19339
      Reported by: aram.dermenjian
      Ticket author(s): Ben Strasser
      Reviewer(s): Aram Dermenjian, Emily Gunawan, Jacob P. Matherne, Travis
      Scrimshaw, Gregg Musiker
    • Release Manager's avatar
      Trac #23654: Bug in ClusterAlgebra _coerce_map_from_ · c8a96622
      Release Manager authored
      Right now the method `_coerce_map_from_` of `ClusterAlgebra` references
      a variable before actually defining it:
      sage: A = ClusterAlgebra(['A',2])
      sage: AA = ClusterAlgebra(['A',3])
      sage: A.has_coerce_map_from(AA)
      Traceback (most recent call last):
      UnboundLocalError: local variable 'f' referenced before assignment
      URL: https://trac.sagemath.org/23654
      Reported by: etn40ff
      Ticket author(s): Salvatore Stella
      Reviewer(s): Frédéric Chapoton
    • Release Manager's avatar
      Trac #23651: py3 more cmp for polynomial ring elements · 8808ca40
      Release Manager authored
      another move to python3
      URL: https://trac.sagemath.org/23651
      Reported by: chapoton
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Travis Scrimshaw
    • Release Manager's avatar
      Trac #23649: py3 richcmp for Gamma congruence groups · 03bad70b
      Release Manager authored
      as another step to python3
      URL: https://trac.sagemath.org/23649
      Reported by: chapoton
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Travis Scrimshaw
    • Release Manager's avatar
      Trac #23641: py3: another load of absolute imports in cython files · 3b249bf9
      Release Manager authored
      part of #22808
      chosen with the help of
      grep -L "absolute_import" $(git grep -l "^import " *.pyx)
      URL: https://trac.sagemath.org/23641
      Reported by: chapoton
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Travis Scrimshaw
    • Release Manager's avatar
      Trac #23636: arccoth(float) returns complex · 8c4222be
      Release Manager authored
      sage: arccoth(float(1.1))
      should be
      URL: https://trac.sagemath.org/23636
      Reported by: paulmasson
      Ticket author(s): Paul Masson
      Reviewer(s): Frédéric Chapoton
    • Release Manager's avatar
      Trac #23633: infinite polynomial: iterate over coefficient/monomial · 6c8bd5d7
      Release Manager authored
      sage: X.<x,y> = InfinitePolynomialRing(QQ)
      sage: a = x[0] + 2*x[1] + y[0]*y[1]
      sage: list(a)
      (so that it works like with the usual polynomials).
      URL: https://trac.sagemath.org/23633
      Reported by: dkrenn
      Ticket author(s): Daniel Krenn
      Reviewer(s): Travis Scrimshaw
    • Release Manager's avatar
      Trac #23608: Riemann surfaces: homomorphisms, interfacing, sums · 7f7f5838
      Release Manager authored
      Provide simple access methods on projective and plane algebraic curves
      to create the corresponding Riemann surface (that way we don't have to
      expose anything extra in the global namespace!)
      Also implement the numerical computation of homomorphisms (directly
      analogous to computation of endomorphisms)
      Also compute disjoint sums of riemann surfaces (direct product on their
      complex tori), to allow easy use of homomorphism testing with
      decomposable jacobians.
      The direct sums presently do not provide much further functionality than
      that their Riemann matrices are the block sums of their constituents.
      (By implementing that and inheriting from RiemannSurface, we get
      homomorphisms and endomorphisms to work for them).
      URL: https://trac.sagemath.org/23608
      Reported by: nbruin
      Ticket author(s): Nils Bruin
      Reviewer(s): Jeroen Sijsling
    • Release Manager's avatar
      Trac #23583: py3: some more richcmp in schemes, rings, and combinat · aff66a3b
      Release Manager authored
      another step one our looong road to python3
      URL: https://trac.sagemath.org/23583
      Reported by: chapoton
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Travis Scrimshaw
    • Release Manager's avatar
      Trac #20932: Issues with p1list in modular symbols · efaeac41
      Release Manager authored
      Two related issues with modular symbols, originally reported by
      robharron on sage-nt: [https://groups.google.com/forum/#!msg/sage-
      Issue 1:
      sage: chi = kronecker_character(3*34603)
      sage: M = ModularSymbols(chi, 2, sign=1, base_ring=GF(3))
      File "/projects/sage/sage-6.10/local/lib/python2.7/site-
      packages/sage/modular/modsym/relation_matrix.py", line 126, in
          assert j != -1
      The underlying problem appears to be:
      sage: import sage.modular.modsym.p1list as p1list
      sage: for (i,j) in p1list.P1List(103809):
      sage:    if i != 1 and i != 3: print (i,j)
      (0, 1) #should also return (34603, 1), (34603, 2), (34603, 3)
      Issue 2:
      sage: chi = kronecker_character(3*61379)
      sage: M = ModularSymbols(chi, 2, sign=1, base_ring=GF(3))
        File "sage/rings/fast_arith.pyx", line 381, in
      sage.rings.fast_arith.arith_llong.c_inverse_mod_longlong (/projects/sage
          raise ArithmeticError("The inverse of %s modulo %s is not
      ArithmeticError: The inverse of -2142142713 modulo 184137 is not
      The underlying issue appears to be:
      sage: import sage.modular.modsym.p1list as p1list
      sage: N = 3*61379
      sage: p1 = p1list.P1List(N)
      sage: p1.normalize_with_scalar(21, -1)
      ArithmeticError: The inverse of -2142142713 modulo 184137 is not
      URL: https://trac.sagemath.org/20932
      Reported by: kedlaya
      Ticket author(s): Kiran Kedlaya
      Reviewer(s): Vincent Delacroix, John Cremona, Frédéric Chapoton
  4. 19 Aug, 2017 6 commits
  5. 18 Aug, 2017 3 commits
  6. 17 Aug, 2017 7 commits
  7. 16 Aug, 2017 10 commits
    • Nils Bruin's avatar
      documentation update and some fixes · d7ccf0d9
      Nils Bruin authored
      More specifically:
       - integer_matrix_relations: more robust for different-sized coefficients,
         as well as documentation changes
       - Check that polynomial is at least of degree 2.
    • Release Manager's avatar
      Trac #23472: The error message for splitting_field when name is None does not... · 5af5f731
      Release Manager authored
      Trac #23472: The error message for splitting_field when name is None does not match that of NumberField
      When one computes:
      sage: R.<x> = QQ[]
      sage: f = x^2 - 2
      sage: K = NumberField(f)
      Error in lines 3-3
      Traceback (most recent call last):
        File "/usr/local/sage/local/lib/python2.7/site-
      packages/smc_sagews/sage_server.py", line 995, in execute
          exec compile(block+'\n', '', 'single') in namespace, locals
        File "", line 1, in <module>
        File "/usr/local/sage/local/lib/python2.7/site-
      packages/sage/rings/number_field/number_field.py", line 524, in
          return NumberField_version2(polynomial=polynomial, name=name,
      check=check, embedding=embedding, latex_name=latex_name,
      maximize_at_primes=maximize_at_primes, structure=structure)
        File "sage/structure/factory.pyx", line 362, in
          key, kwds = self.create_key_and_extra_args(*args, **kwds)
        File "/usr/local/sage/local/lib/python2.7/site-
      packages/sage/rings/number_field/number_field.py", line 594, in
          raise TypeError("You must specify the name of the generator.")
      TypeError: You must specify the name of the generator.
      However when one computes:
      sage: f.splitting_field()
      Error in lines 3-3
      Traceback (most recent call last):
        File "/usr/local/sage/local/lib/python2.7/site-
      packages/smc_sagews/sage_server.py", line 995, in execute
          exec compile(block+'\n', '', 'single') in namespace, locals
        File "", line 1, in <module>
        File "sage/rings/polynomial/polynomial_element.pyx", line 4181, in
      sage.rings.polynomial.polynomial_element.Polynomial.splitting_field (/us
          def splitting_field(self, names, map=False, **kwds):
      TypeError: splitting_field() takes at least 1 positional argument (0
      One needs to add the lines:
      if name is None:
          raise TypeError("You must specify the name of the generator.")
      Before the line:
      name = normalize_names(1, name)
      in the corresponding file.
      URL: https://trac.sagemath.org/23472
      Reported by: geze
      Ticket author(s): Gerardo Zelaya
      Reviewer(s): Kevin Lui
    • Release Manager's avatar
      Trac #23620: gcd has wrong parent · 689096ee
      Release Manager authored
      Currently, the parent of a gcd might be wrong when the gcd of
      polynomials is just the gcd of its contents:
      sage: R.<x> = ZpFM(2)[]
      sage: f = 2*x + 2
      sage: g = 4*x + 2
      sage: f.gcd(g).parent() is R
      False # parent is ZpFM(2)
      URL: https://trac.sagemath.org/23620
      Reported by: saraedum
      Ticket author(s): Julian Rüth
      Reviewer(s): David Roe
    • Release Manager's avatar
      Trac #23609: Don't use wrong Cremona labels in elliptic_curves database · 8e2e4876
      Release Manager authored
      When the elliptic_curves database (of curves with large rank) returns a
      curve with an unknown Cremona label, it instead sets a bogus label:
      sage: E = elliptic_curves.rank(5)[0]
      sage: E.cremona_label()
      We fix this by setting the label only if the conductor is <= 400000.
      We also change the exceptions a bit in the case that the curve is not
      found, changing `RuntimeError` to a more appropriate `LookupError`.
      URL: https://trac.sagemath.org/23609
      Reported by: jdemeyer
      Ticket author(s): Jeroen Demeyer
      Reviewer(s): John Cremona
    • Release Manager's avatar
      Trac #23160: Add a library of common helper functions for use in spkg-install · 3cbfcdae
      Release Manager authored
      This idea has come up before but not been implemented.  My
      implementation simply adds a collection of shell functions with names
      prefixed by `sdh_` for Sage distribution helpers (this is somewhat
      inspired by, but much simpler than, the `dh_` programs from the
      `debhelper` package in Debian).
      These functions are exported by `sage-spkg`, and so are immediately
      usable by any `spkg-build`, `spkg-install`, or similar scripts executed
      from `sage-spkg` (these are still not required to be shell scripts, but
      as most are having such a library is convenient).
      One piece of boilerplate I replaced with a function is the check in most
      `spkg-install`s for `$SAGE_LOCAL`.  A downside to this is that if the
      script is run outside the correct environment, then rather than getting
      a useful error message we just get that `sdh_check_vars` is undefined.
      I have two thoughts on this:
      1) In general these scripts shouldn't be run directly in the first
      place.  In the case that they are (such as testing) the person
      developing the package should have some awareness of the fact that these
      scripts are being run from `sage-spkg` and assume `sage-env` has been
      2) Most of the time these scripts are run, it's after they've been
      copied to a temporary build directory for the package.  If nothing else,
      `sage-spkg` could create a wrapper around these scripts that
      automatically sets some default assumptions (such as sourcing `sage-env`
      and the new `sage-dist-helpers`).
      In general, though, I think having a library of helper functions will be
      a big improvement to the consistency and legibility of theses scripts.
      This ticket also updates the `spkg-install` for `patch` for
      demonstration purposes only.  I don't intend with this to go on a mass
      rewriting of install scripts, but having this will be helpful for some
      other work (e.g. #22509, #22510).
      URL: https://trac.sagemath.org/23160
      Reported by: embray
      Ticket author(s): Erik Bray
      Reviewer(s): Jeroen Demeyer
    • Daniel Krenn's avatar
      primitive root p^j mod p^k · a24534f5
      Daniel Krenn authored
    • Daniel Krenn's avatar
      add doctests · 121fab6d
      Daniel Krenn authored
    • Daniel Krenn's avatar
      0 is primitiv root mod 1 · d1e742a0
      Daniel Krenn authored
    • Will Song's avatar
      0 is not a primitiv root mod n · b9f29b78
      Will Song authored and Daniel Krenn's avatar Daniel Krenn committed
    • Travis Scrimshaw's avatar
      Fixing doctest and docbuild. · 5d8224ce
      Travis Scrimshaw authored
  8. 15 Aug, 2017 1 commit