1. 15 Mar, 2018 1 commit
  2. 10 Mar, 2018 1 commit
  3. 08 Mar, 2018 5 commits
  4. 07 Mar, 2018 7 commits
    • Travis Scrimshaw's avatar
      Fixing minor doc issue. · c6b1d03f
      Travis Scrimshaw authored
      c6b1d03f
    • Release Manager's avatar
      Trac #24893: some details in graph_latex · fbad515a
      Release Manager authored
      namely some typos in the doc and a partial pyflakes/pep8 cleanup
      
      URL: https://trac.sagemath.org/24893
      Reported by: chapoton
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Travis Scrimshaw
      fbad515a
    • Release Manager's avatar
      Trac #24779: py3: buffet of minor doctest fixes · 681e4275
      Release Manager authored
      This ticket collects up several (but not all) doctests that I've fixed
      in my Python 3 branch.
      
      Fixes are organized somewhat categorically in the commits, but all
      together these are just discrete and trivial little fixes.
      
      URL: https://trac.sagemath.org/24779
      Reported by: embray
      Ticket author(s): Erik Bray
      Reviewer(s): Frédéric Chapoton
      681e4275
    • Release Manager's avatar
      Trac #24899: py3: using richcmp in p1list.pyx · ccb4517d
      Release Manager authored
      part of #16537
      
      URL: https://trac.sagemath.org/24899
      Reported by: chapoton
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Julian Rüth
      ccb4517d
    • Release Manager's avatar
      Trac #24898: wrong relabel handling in modular_decomposition of graphs · fc9a17f6
      Release Manager authored
      As reported on [https://ask.sagemath.org/question/41398/error-with-
      is_prime/ this ask question]:
      
      {{{
      sage: G=Graph({1:[2],2:[1]})
      sage: G.modular_decomposition()
      ------------------------------------------------------------------------
      ---
      KeyError                                  Traceback (most recent call
      last)
      <ipython-input-5-05fa7ad0eb50> in <module>()
      ----> 1 G.modular_decomposition()
      
      /opt/sagemath/sage-source/local/lib/python2.7/site-
      packages/sage/graphs/graph.pyc in modular_decomposition(self)
         7185         relabel = lambda x : (x.node_type, [relabel(_) for _ in
      x.children]) if x.node_type != NodeType.NORMAL else
      id_label[x.children[0]]
         7186
      -> 7187         return relabel(D)
         7188
         7189     @doc_index("Graph properties")
      
      /opt/sagemath/sage-source/local/lib/python2.7/site-
      packages/sage/graphs/graph.pyc in <lambda>(x)
         7183         id_label = dict(enumerate(self.vertices()))
         7184
      -> 7185         relabel = lambda x : (x.node_type, [relabel(_) for _ in
      x.children]) if x.node_type != NodeType.NORMAL else
      id_label[x.children[0]]
         7186
         7187         return relabel(D)
      
      /opt/sagemath/sage-source/local/lib/python2.7/site-
      packages/sage/graphs/graph.pyc in <lambda>(x)
         7183         id_label = dict(enumerate(self.vertices()))
         7184
      -> 7185         relabel = lambda x : (x.node_type, [relabel(_) for _ in
      x.children]) if x.node_type != NodeType.NORMAL else
      id_label[x.children[0]]
         7186
         7187         return relabel(D)
      
      KeyError: 2
      }}}
      
      URL: https://trac.sagemath.org/24898
      Reported by: tmonteil
      Ticket author(s): Dima Pasechnik
      Reviewer(s): Thierry Monteil
      fc9a17f6
    • Release Manager's avatar
      Trac #24884: Matrix-related fixes in differential geometry · 2b6ad723
      Release Manager authored
      These are changes which are needed because of #24742.
      
      1. `src/sage/schemes/riemann_surfaces/riemann_surface.py`: #24742 will
      disallow passing strings to the matrix constructor. It's a rarely used
      feature and hard to get right properly. The fix is easy: pass actual
      elements of the ring instead of the generator names. This is clearly the
      right thing to do.
      
      2. `src/sage/tensor/modules/comp.py`: I needed to change `_get_list()`
      but I have to say that I don't understand what the code is supposed to
      do. I wrote the code the way I did mainly to pass doctests. I also added
      some documentation to reflect better what the `_get_list()` method does.
      I also got rid of the evil `try`/`except` block trying to construct a
      matrix but happily returning a list if that failed.
      
      3. `src/sage/manifolds/differentiable/metric.py`: this is a consequence
      of the change in 2. and it looks like a sensible change.
      
      URL: https://trac.sagemath.org/24884
      Reported by: jdemeyer
      Ticket author(s): Jeroen Demeyer, Eric Gourgoulhon
      Reviewer(s): Travis Scrimshaw
      2b6ad723
    • Release Manager's avatar
      Trac #24817: Faster creation of complex balls from two integers/rationals · 919ac0ea
      Release Manager authored
      Before:
      {{{
      sage: from sage.rings.complex_arb import ComplexBall
      sage: %timeit ComplexBall(CBF, 1)
      The slowest run took 65.49 times longer than the fastest. This could
      mean that an intermediate result is being cached.
      1000000 loops, best of 3: 444 ns per loop
      sage: %timeit CBF(1)
      The slowest run took 119.18 times longer than the fastest. This could
      mean that an intermediate result is being cached.
      1000000 loops, best of 3: 604 ns per loop
      sage: %timeit CBF(1, 2)
      The slowest run took 58.19 times longer than the fastest. This could
      mean that an intermediate result is being cached.
      100000 loops, best of 3: 2.75 µs per loop
      }}}
      After:
      {{{
      sage: from sage.rings.complex_arb import ComplexBall
      sage: %timeit ComplexBall(CBF, 1)
      The slowest run took 58.67 times longer than the fastest. This could
      mean that an intermediate result is being cached.
      1000000 loops, best of 3: 459 ns per loop
      sage: %timeit CBF(1)
      The slowest run took 135.45 times longer than the fastest. This could
      mean that an intermediate result is being cached.
      1000000 loops, best of 3: 642 ns per loop
      sage: %timeit CBF(1, 2)
      The slowest run took 18.88 times longer than the fastest. This could
      mean that an intermediate result is being cached.
      1000000 loops, best of 3: 909 ns per loop
      sage: %timeit ComplexBall(CBF, 1, 2)
      The slowest run took 18.09 times longer than the fastest. This could
      mean that an intermediate result is being cached.
      1000000 loops, best of 3: 620 ns per loop
      }}}
      
      URL: https://trac.sagemath.org/24817
      Reported by: mmezzarobba
      Ticket author(s): Marc Mezzarobba
      Reviewer(s): Vincent Delecroix
      919ac0ea
  5. 06 Mar, 2018 24 commits
    • Release Manager's avatar
      Trac #23700: update gc to version 7.6 · 4f2874af
      Release Manager authored
      An update to gc is needed to support arm64/aarch64, see #23687,
      as well as for FreeBSD support, see #22679.
      It also appears to be good to be in sync with Linux boxes that ship make
      with guile extension (the latter depends on gc, and causes interesting
      errors, see #24575).
      
      The source is here:
      https://github.com/ivmai/bdwgc/releases/download/v7.6.4/gc-7.6.4.tar.gz
      
      On some platforms this new version also needs libatomic_ops, see #23701
      
      URL: https://trac.sagemath.org/23700
      Reported by: dimpase
      Ticket author(s): Dima Pasechnik, Erik Bray
      Reviewer(s): Erik Bray, Dima Pasechnik, Jeroen Demeyer
      4f2874af
    • Release Manager's avatar
      Trac #23505: Lattice precision for p-adics · 30d77825
      Release Manager authored
      In several recent papers, David Roe, Tristan Vaccon and I explain that
      lattices allow a sharp track of precision: if f is a function we want to
      evaluate and x is an input given with some uncertainty modeled by a
      lattice H, then the uncertainty on the output f(x) is exactly df_x(H).
      
      For much more details, I refer to my lecture notes
      http://xavier.toonywood.org/papers/publis/course-padic.pdf
      
      The aim of this ticket is to propose a rough implementation of these
      ideas.
      
      You can play with the latest version of this by clicking on launch
      binder [https://github.com/saraedum/sage-binder-env/tree/t-23505
      -lattice-precision here].
      
      Below is a small demo (extracted from the doctest).
      
      {{{
      
         Below is a small demo of the features by this model of precision:
      
            sage: R = ZpLP(3, print_mode='terse')
            sage: x = R(1,10)
      
         Of course, when we multiply by 3, we gain one digit of absolute
         precision:
      
            sage: 3*x
            3 + O(3^11)
      
         The lattice precision machinery sees this even if we decompose the
         computation into several steps:
      
            sage: y = x+x
            sage: y
            2 + O(3^10)
            sage: x + y
            3 + O(3^11)
      
         The same works for the multiplication:
      
            sage: z = x^2
            sage: z
            1 + O(3^10)
            sage: x*z
            1 + O(3^11)
      
         This comes more funny when we are working with elements given at
         different precisions:
      
            sage: R = ZpLP(2, print_mode='terse')
            sage: x = R(1,10)
            sage: y = R(1,5)
            sage: z = x+y; z
            2 + O(2^5)
            sage: t = x-y; t
            0 + O(2^5)
            sage: z+t  # observe that z+t = 2*x
            2 + O(2^11)
            sage: z-t  # observe that z-t = 2*y
            2 + O(2^6)
      
            sage: x = R(28888,15)
            sage: y = R(204,10)
            sage: z = x/y; z
            242 + O(2^9)
            sage: z*y  # which is x
            28888 + O(2^15)
      
         The SOMOS sequence is the sequence defined by the recurrence:
      
            ..MATH::
      
            u_n =  rac {u_{n-1} u_{n-3} + u_{n-2}^2} {u_{n-4}}
      
         It is known for its numerical instability. On the one hand, one can
         show that if the initial values are invertible in mathbb{Z}_p and
         known at precision O(p^N) then all the next terms of the SOMOS
         sequence will be known at the same precision as well. On the other
         hand, because of the division, when we unroll the recurrence, we
         loose a lot of precision. Observe:
      
            sage: R = Zp(2, 30, print_mode='terse')
            sage: a,b,c,d = R(1,15), R(1,15), R(1,15), R(3,15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            4 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            13 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            55 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            21975 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            6639 + O(2^13)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            7186 + O(2^13)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            569 + O(2^13)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            253 + O(2^13)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            4149 + O(2^13)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            2899 + O(2^12)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            3072 + O(2^12)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            349 + O(2^12)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            619 + O(2^12)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            243 + O(2^12)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            3 + O(2^2)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            2 + O(2^2)
      
         If instead, we use the lattice precision, everything goes well:
      
            sage: R = ZpLP(2, 30, print_mode='terse')
            sage: a,b,c,d = R(1,15), R(1,15), R(1,15), R(3,15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            4 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            13 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            55 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            21975 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            23023 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            31762 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            16953 + O(2^15)
            sage: a,b,c,d = b,c,d,(b*d+c*c)/a; print d
            16637 + O(2^15)
      
            sage: for _ in range(100):
            ....:     a,b,c,d = b,c,d,(b*d+c*c)/a
            sage: a
            15519 + O(2^15)
            sage: b
            32042 + O(2^15)
            sage: c
            17769 + O(2^15)
            sage: d
            20949 + O(2^15)
      
         BEHIND THE SCENE:
      
         The precision is global. It is encoded by a lattice in a huge
         vector space whose dimension is the number of elements having this
         parent.
      
         Concretely, this precision datum is an instance of the class
         "sage.rings.padic.lattice_precision.PrecisionLattice". It is
         attached to the parent and is created at the same time as the
         parent. (It is actually a bit more subtle because two different
         parents may share the same instance; this happens for instance for
         a p-adic ring and its field of fractions.)
      
         This precision datum is accessible through the method
         "precision()":
      
            sage: R = ZpLP(5, print_mode='terse')
            sage: prec = R.precision()
            sage: prec
            Precision Lattice on 0 object
      
         This instance knows about all elements of the parent, it is
         automatically updated when a new element (of this parent) is
         created:
      
            sage: x = R(3513,10)
            sage: prec
            Precision Lattice on 1 object
            sage: y = R(176,5)
            sage: prec
            Precision Lattice on 2 objects
            sage: z = R.random_element()
            sage: prec
            Precision Lattice on 3 objects
      
         The method "tracked_elements()" provides the list of all tracked
         elements:
      
            sage: prec.tracked_elements()
            [3513 + O(5^10), 176 + O(5^5), ...]
      
         Similarly, when a variable is collected by the garbage collector,
         the precision lattice is updated. Note however that the update
         might be delayed. We can force it with the method "del_elements()":
      
            sage: z = 0
            sage: prec
            Precision Lattice on 3 objects
            sage: prec.del_elements()
            sage: prec
            Precision Lattice on 2 objects
      
         The method "precision_lattice()" returns (a matrix defining) the
         lattice that models the precision. Here we have:
      
            sage: prec.precision_lattice()
            [9765625       0]
            [      0    3125]
      
         Observe that 5^10 = 9765625 and 5^5 = 3125. The above matrix then
         reflects the precision on x and y.
      
         Now, observe how the precision lattice changes while performing
         computations:
      
            sage: x, y = 3*x+2*y, 2*(x-y)
            sage: prec.del_elements()
            sage: prec.precision_lattice()
            [    3125 48825000]
            [       0 48828125]
      
         The matrix we get is no longer diagonal, meaning that some digits
         of precision are diffused among the two new elements x and y. They
         nevertheless show up when we compute for instance x+y:
      
            sage: x
            1516 + O(5^5)
            sage: y
            424 + O(5^5)
            sage: x+y
            17565 + O(5^11)
      
         It is these diffused digits of precision (which are tracked but do
         not appear on the printing) that allow to be always sharp on
         precision.
      
         PERFORMANCES:
      
         Each elementary operation requires significant manipulations on the
         lattice precision and then is costly. Precisely:
      
         * The creation of a new element has a cost O(n) when n is the
           number of tracked elements.
      
         * The destruction of one element has a cost O(m^2) when m is the
           distance between the destroyed element and the last one.
           Fortunately, it seems that m tends to be small in general (the
           dynamics of the list of tracked elements is rather close to that
           of a stack).
      
         It is nevertheless still possible to manipulate several hundred
         variables (e.g. squares matrices of size 5 or polynomials of degree
         20 are accessible).
      
         The class "PrecisionLattice" provides several features for
         introspection (especially concerning timings). If enables, it
         maintains an history of all actions and stores the wall time of
         each of them:
      
            sage: R = ZpLP(3)
            sage: prec = R.precision()
            sage: prec.history_enable()
            sage: M = random_matrix(R, 5)
            sage: d = M.determinant()
            sage: print prec.history()  # somewhat random
               ---
            0.004212s  oooooooooooooooooooooooooooooooooooo
            0.000003s  oooooooooooooooooooooooooooooooooo~~
            0.000010s  oooooooooooooooooooooooooooooooooo
            0.001560s  ooooooooooooooooooooooooooooooooooooooooo
            0.000004s  ooooooooooooooooooooooooooooo~oooo~oooo~o
            0.002168s  oooooooooooooooooooooooooooooooooooooo
            0.001787s  ooooooooooooooooooooooooooooooooooooooooo
            0.000004s  oooooooooooooooooooooooooooooooooooooo~~o
            0.000198s  ooooooooooooooooooooooooooooooooooooooo
            0.001152s  ooooooooooooooooooooooooooooooooooooooooo
            0.000005s  ooooooooooooooooooooooooooooooooo~oooo~~o
            0.000853s  oooooooooooooooooooooooooooooooooooooo
            0.000610s  ooooooooooooooooooooooooooooooooooooooo
            ...
            0.003879s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.000006s
      oooooooooooooooooooooooooooooooooooooooooooooooooooo~~~~~
            0.000036s  oooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.006737s
      oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.000005s
      oooooooooooooooooooooooooooooooooooooooooooooooooooo~~~~~ooooo
            0.002637s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.007118s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.000008s
      oooooooooooooooooooooooooooooooooooooooooooooooooooo~~~~o~~~~oooo
            0.003504s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.005371s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.000006s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooo~~~o~~~ooo
            0.001858s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.003584s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.000004s
      oooooooooooooooooooooooooooooooooooooooooooooooooooooo~~o~~oo
            0.000801s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.001916s
      ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
            0.000022s
      ooooooooooooooooooooooooooooo~~~~~~~~~~~~~~~~~~~~~~oooo~o~o
            0.014705s  ooooooooooooooooooooooooooooooooooo
            0.001292s  ooooooooooooooooooooooooooooooooooooo
            0.000002s  ooooooooooooooooooooooooooooooooooo~o
      
         The symbol o symbolized a tracked element. The symbol ~ means that
         the element is marked for deletion.
      
         The global timings are also accessible as follows:
      
            sage: prec.timings()   # somewhat random
            {'add': 0.25049376487731934,
             'del': 0.11911273002624512,
             'mark': 0.0004909038543701172,
             'partial reduce': 0.0917658805847168}
      
      }}}
      
      URL: https://trac.sagemath.org/23505
      Reported by: caruso
      Ticket author(s): Xavier Caruso
      Reviewer(s): David Roe, Julian Rüth
      30d77825
    • Release Manager's avatar
      Trac #21524: configure.ac: write build/make/Makefile within an AC_CONFIG_FILE,... · 15fbaa62
      Release Manager authored
      Trac #21524: configure.ac: write build/make/Makefile within an AC_CONFIG_FILE, not during main configure
      
      `build/make/Makefile` should be written by `config.status` within an
      `AC_CONFIG_FILE` template, not at `configure` time.
      
      URL: https://trac.sagemath.org/21524
      Reported by: mkoeppe
      Ticket author(s): Erik Bray
      Reviewer(s): Julian Rüth
      15fbaa62
    • Release Manager's avatar
      Trac #24867: The check for broken GCC should use src/bin/sage-env · 2972b5ab
      Release Manager authored
      The problem is that `$SAGE_LOCAL/bin/sage-env` is created as part of the
      build process. There is no guarantee that it exists after building GCC.
      
      URL: https://trac.sagemath.org/24867
      Reported by: jdemeyer
      Ticket author(s): Jeroen Demeyer
      Reviewer(s): Matthias Koeppe
      2972b5ab
    • E. Madison Bray's avatar
    • E. Madison Bray's avatar
      Moved the code that collects up SPKG info into a single SAGE_SPKG_COLLECT... · bb9ff43e
      E. Madison Bray authored
      Moved the code that collects up SPKG info into a single SAGE_SPKG_COLLECT macro, along with additional documentation thereof.
      bb9ff43e
    • Travis Scrimshaw's avatar
      Some cleanup and other minor tweaks. · c4e32999
      Travis Scrimshaw authored
      c4e32999
    • Travis Scrimshaw's avatar
      Do not use @cached_method for automorphism_group(). · 0c212d21
      Travis Scrimshaw authored
      The UniqueRepresentation handles the caching.
      0c212d21
    • Travis Scrimshaw's avatar
      Merge branch... · 5e3e5432
      Travis Scrimshaw authored
      Merge branch 'u/sbrandhorst/endomorphisms_ring_and_automorphism_group_of_finite__additive__abelian_groups_' of git://trac.sagemath.org/sage into u/tscrim/automorphism_group_finite_abelian_groups_gap-24087
      5e3e5432
    • Xavier Caruso's avatar
      Fix doctest · f29502ee
      Xavier Caruso authored
      f29502ee
    • Dima Pasechnik's avatar
      c3235d74
    • Release Manager's avatar
      Trac #24871: fixing doc formatting in widgets.py · f3fcca21
      Release Manager authored
      plus some pep8 details
      
      URL: https://trac.sagemath.org/24871
      Reported by: chapoton
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Jeroen Demeyer
      f3fcca21
    • Release Manager's avatar
      Trac #24844: Some elliptic curve functions do not set a point's order · 3ddf3229
      Release Manager authored
      {{{
      sage: p=next_prime(1000000)
      sage: E=EllipticCurve(GF(p), 123, 456)
      sage: pts = E(0).division_points(3)
      sage: P=pts[1]; P
      (389063 : 124244 : 1)
      sage:
      sage: P._order
      ...
      AttributeError: 'EllipticCurvePoint_finite_field' object has no
      attribute '_order'
      sage: P.order()
      3
      sage: P._order
      3
      sage:
      }}}
      
      Here one might expect the point P's _order attribute to be set to 3 on
      construction since this can be deduced from what is known.
      
      URL: https://trac.sagemath.org/24844
      Reported by: cremona
      Ticket author(s): John Cremona
      Reviewer(s): Frédéric Chapoton
      3ddf3229
    • Release Manager's avatar
      Trac #24821: _mul_ for FGP_Module_class · 9c6fc0fc
      Release Manager authored
      We define scalar multiplication of FGP_Module_class.
      Here scalar multiplication means an ordinary one, that is, the image of
      the map defined by a scalar multiplication as a module.
      
      URL: https://trac.sagemath.org/24821
      Reported by: khashimoto
      Ticket author(s): Kenji Hashimoto
      Reviewer(s): Simon Brandhorst
      9c6fc0fc
    • Release Manager's avatar
      Trac #24001: Some "optional - dot2tex" doctests do not depend on dot2tex · e60a2f4d
      Release Manager authored
      11 of the 28 doctests which are marked `# optional - dot2tex` or `#
      optional - dot2tex graphviz` pass even when dot2tex and graphviz are not
      installed.
      
      URL: https://trac.sagemath.org/24001
      Reported by: jdemeyer
      Ticket author(s): Jeroen Demeyer
      Reviewer(s): Travis Scrimshaw, Frédéric Chapoton
      e60a2f4d
    • Release Manager's avatar
      Trac #23229: Cache fraction_field() of p-adic rings, deprecate print_mode options · 6ac29abb
      Release Manager authored
      Note that `creduce` calls this a lot since it computes `inverse_of_unit`
      in the fraction field.
      
      In a two-step extension, introduced in #23218, this is probably most
      significant:
      {{{
      sage: w=W.gen()
      sage: %timeit u=-w
      1000 loops, best of 3: 774 µs per loop # without caching
      10000 loops, best of 3: 77.9 µs per loop # with caching
      }}}
      
      In order to get better speed, this ticket also deprecates the
      `print_mode` dictionary that can passed into `fraction_field`, since
      this functionality is now available with `change`.
      
      URL: https://trac.sagemath.org/23229
      Reported by: saraedum
      Ticket author(s): Julian Rüth, David Roe
      Reviewer(s): David Roe
      6ac29abb
    • Release Manager's avatar
      Trac #24897: cantor_product does an infinite loop · 2d0f8549
      Release Manager authored
      {{{
      sage: from sage.misc.mrange import cantor_product
      sage: c = cantor_product([1])
      sage: c.next()
      (1,)
      sage: c.next()
      
      }}}
      
      The blank line at the end is intentional as that is just what
      cantor_product does. It hangs. --> ctrl + c. I would expect it to rather
      raise a stop iteration.
      
      URL: https://trac.sagemath.org/24897
      Reported by: sbrandhorst
      Ticket author(s): Vincent Delecroix
      Reviewer(s): Simon Brandhorst
      2d0f8549
    • Release Manager's avatar
      Trac #24882: various enhancements to cluster quivers · 95e44ce4
      Release Manager authored
      extracted from #22381
      
      URL: https://trac.sagemath.org/24882
      Reported by: chapoton
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Travis Scrimshaw, Christian Stump
      95e44ce4
    • Release Manager's avatar
      Trac #24881: Minor fixes involving matrices · 5b735cdb
      Release Manager authored
      This collects a bunch of minor fixes which were needed for #24742 but
      which make sense anyway.
      
      URL: https://trac.sagemath.org/24881
      Reported by: jdemeyer
      Ticket author(s): Jeroen Demeyer
      Reviewer(s): Frédéric Chapoton
      5b735cdb
    • Release Manager's avatar
      Trac #24879: Typo in Sage documentation · 039f3d4a
      Release Manager authored
      I found a typo in the Sage documentation, at the function `period()`:
      
      http://doc.sagemath.org/html/en/reference/rings_standard/sage/rings/rati
      onal.html#sage.rings.rational.Rational.period
      
      It should be
      {{{
      In general if d=2^a5^bm where m is coprime to 10
      }}}
      instead of
      {{{
      In general if d=2^a3^bm where m is coprime to 10
      }}}
      
      See also [https://ask.sagemath.org/question/41324/typo-in-sage-
      documentation/ this ask question].
      
      URL: https://trac.sagemath.org/24879
      Reported by: gh:Thrashophil
      Ticket author(s): Frédéric Chapoton
      Reviewer(s): Tommy Angelo
      039f3d4a
    • Release Manager's avatar
      Trac #24874: BooleanMonomialMonoid is commutative · 28fed0df
      Release Manager authored
      The category should be `Monoids().Commutative()`
      
      URL: https://trac.sagemath.org/24874
      Reported by: jdemeyer
      Ticket author(s): Jeroen Demeyer
      Reviewer(s): Frédéric Chapoton
      28fed0df
    • Release Manager's avatar
      Trac #24870: is_rational on Integer and Rational · 815b1f12
      Release Manager authored
      The element in number fields support `is_rational` and it would be nice
      if Sage Integer and Rational support it as well.
      
      URL: https://trac.sagemath.org/24870
      Reported by: vdelecroix
      Ticket author(s): Vincent Delecroix
      Reviewer(s): Travis Scrimshaw
      815b1f12
    • Release Manager's avatar
      Trac #24865: Finite field elements should not have a _matrix_ method · e7843192
      Release Manager authored
      This is unexpected:
      {{{
      sage: k.<a> = GF(4)
      sage: matrix(a, nrows=2, ncols=2)
      [0 1]
      [1 1]
      }}}
      because one would typically expect a scalar matrix instead:
      {{{
      sage: R.<a> = EisensteinIntegers()
      sage: matrix(a, nrows=2, ncols=2)
      [a 0]
      [0 a]
      }}}
      This is because finite field elements implement `_matrix_` and this
      takes priority in the matrix constructor.
      
      Proposal: rename `_matrix_` to `matrix` to make it usable as ordinary
      method.
      
      URL: https://trac.sagemath.org/24865
      Reported by: jdemeyer
      Ticket author(s): Jeroen Demeyer
      Reviewer(s): Frédéric Chapoton
      e7843192
    • Xavier Caruso's avatar
      Lattice precision for p-adics · b2b82e87
      Xavier Caruso authored and Julian Rüth's avatar Julian Rüth committed
      
      
      In several recent papers, David Roe, Tristan Vaccon, and Xavier Caruso explain
      that lattices allow a sharp track of precision. This approach is implemented
      here in a first experimental version.
      Co-authored-by: roed314's avatarDavid Roe <roed.math@gmail.com>
      Co-authored-by: Julian Rüth's avatarJulian Rüth <julian.rueth@fsfe.org>
      b2b82e87
  6. 05 Mar, 2018 2 commits