1. 29 May, 2014 3 commits
  2. 24 May, 2014 10 commits
  3. 23 May, 2014 6 commits
  4. 22 May, 2014 7 commits
  5. 21 May, 2014 14 commits
    • François Bissey's avatar
    • Release Manager's avatar
      Trac #16162: Cantor-Zassenhaus may enter infinite loop over GF(2**k) and cannot be interrupted · 51595420
      Release Manager authored
      A solution is to use random polynomials just as for odd characteristic.
      
      This also replaces calls to `power_mod` by calls to `pow` with three
      arguments which uses implementation optimized code for modular
      exponentiation.
      
      URL: http://trac.sagemath.org/16162
      Reported by: jpflori
      Ticket author(s): Jean-Pierre Flori
      Reviewer(s): Peter Bruin
      51595420
    • Clemens Heuberger's avatar
    • Release Manager's avatar
      Trac #15921: work around Maxima fpprintprec bug and other ARM-specific problems · 9a4b0b83
      Release Manager authored
      [https://groups.google.com/d/msg/sage-devel/oRpkswzpK38/rNVbVN2RyEcJ
      Maxima uses CL FORMAT function wrongly], resulting in outputting wrong
      number of digits for floats (one extra), and
      contradicting its own manual on fpprintprec. In particular it outputs
      too many digits on ix86 and ix86_64, which got in Sage's doctests. As a
      result, doctests fail on ARM.
      
      The fixes are to convert the results into `RealField(prec)`, with
      appropriate `prec`
      (at least 54, or sometimes more). This ticket also fixes ARM-specific
      numerical noise stemming
      from various other upstream problems, such as `eglibc` loss of precision
      in `lgamma`.
      
      URL: http://trac.sagemath.org/15921
      Reported by: dimpase
      Ticket author(s): Dmitrii Pasechnik
      Reviewer(s): Peter Bruin, Volker Braun
      9a4b0b83
    • Daniel Krenn's avatar
      corrected spacings; extended one doctest · 3e9e544c
      Daniel Krenn authored
      3e9e544c
    • Release Manager's avatar
      Trac #16255: FiniteStateMachine.with_final_word_out: New method · f4cbb5f1
      Release Manager authored
      Constructs a finite state machine with final output words for all states
      by implicitly reading trailing letters until a final state is reached.
      
      This is e.g. useful for finite state machines operating on digit
      expansions: there, it is sometimes required to read a sufficient number
      of trailing zeros (at the most significant positions) in order to reach
      a final state and to flush all carries. In this case, this method
      constructs an essentially equivalent finite state machine in the sense
      that it not longer requires adding sufficiently many trailing zeros.
      However, it is the responsibility of the user to make sure that if
      adding trailing zeros to the input anyway, the output is equivalent.
      
      URL: http://trac.sagemath.org/16255
      Reported by: cheuberg
      Ticket author(s): Clemens Heuberger, Daniel Krenn
      Reviewer(s): Daniel Krenn, Sara Kropf
      f4cbb5f1
    • Release Manager's avatar
      Trac #16357: FiniteStateMachine.default_format_transition_label: accept iterable · 3f6e0643
      Release Manager authored
      Current inconsistent behaviour:
      {{{
      sage: T = Transducer()
      sage: T.default_format_transition_label([])
      '\\varepsilon'
      sage: T.default_format_transition_label(iter([]))
      ''
      sage: T.format_transition_label_reversed([])
      ''
      }}}
      
      Change code such that {{{\varepsilon}}} is returned in all three
      instances.
      
      URL: http://trac.sagemath.org/16357
      Reported by: cheuberg
      Ticket author(s): Clemens Heuberger
      Reviewer(s): Daniel Krenn
      3f6e0643
    • Daniel Krenn's avatar
      added spaces after comment-symbol in code · 7db57742
      Daniel Krenn authored
      7db57742
    • Release Manager's avatar
      Trac #14102: Nonsymmetric Macdonald Polynomials for all affine types · 26a0240a
      Release Manager authored
      This ticket implements nonsymmetric Macdonald polynomials for
      arbitrary affine Cartan type (including twisted and BC, but not
      Koornwinder) using the recursion formula in terms of Demazure-Lusztig
      and Cherednik operators. It complements the type-A implementation
      based on the HHL combinatorial formula of #2708.
      
      This patch was written by Anne Schilling and Nicolas M. Thiéry during
      the ICERM Semester Program on "Automorphic Forms, Combinatorial
      Representation Theory and Multiple Dirichlet Series" (January 28,
      2013 - May 3, 2013) with the help of Dan Bump, Ben Brubaker, Bogdan
      Ion, Dan Orr, Arun Ram, Siddhartha Sahi, and Mark Shimozono. Special
      thanks go to Bogdan Ion and Mark Shimozono for their patient
      explanations and hand computations to check the code.
      
      In a follow-up ticket #14847 Whittaker functions and other features will
      become available.
      
      URL: http://trac.sagemath.org/14102
      Reported by: bump
      Ticket author(s): Nicolas M. Thiéry, Anne Schilling
      Reviewer(s): Anne Schilling, Nicolas M. Thiéry, Mark Shimozono, Bogdan
      Ion
      26a0240a
    • Release Manager's avatar
      Trac #15631: Random failures in sandpiles.py · d9fd9a71
      Release Manager authored
      As reported on https://groups.google.com/d/msg/sage-
      devel/ymsEq_f9MNU/0x6vympN2c0J
      {{{
       File "src/sage/sandpiles/sandpile.py", line 4684, in
      sage.sandpiles.sandpile.complete_sandpile
      Failed example:
          K.betti(verbose=False)
      ...
            File "multi_polynomial_libsingular.pyx", line 912, in sage.rings.p
      olynomial.multi_polynomial_libsingular.MPolynomialRing_libsingular.__cal
      l__ (sage/rings/polynomial/multi_polynomial_libsingular.cpp:7912)
          TypeError: Could not find a mapping of the passed element to this
      ring.
      ---
      (same place but different error:)
            File "multi_polynomial_libsingular.pyx", line 807, in sage.rings.p
      olynomial.multi_polynomial_libsingular.MPolynomialRing_libsingular.__cal
      l__ (sage/rings/polynomial/multi_polynomial_libsingular.cpp:6207)
            File "/usr/local/sage/sage-dev/local/lib/python2.7/site-
      packages/sage/interfaces/singular.py", line 1245, in __repr__
              elif self.type() == 'matrix':
            File "/usr/local/sage/sage-dev/local/lib/python2.7/site-
      packages/sage/interfaces/singular.py", line 1976, in type
              return m.group(1)
          AttributeError: 'NoneType' object has no attribute 'group'
      }}}
      This is because the singular pexpect interface has subtle bugs. The easy
      fix is to rewrite it with disabled terminal echo.
      
      URL: http://trac.sagemath.org/15631
      Reported by: vbraun
      Ticket author(s): Volker Braun
      Reviewer(s): Nils Bruin
      d9fd9a71
    • Release Manager's avatar
      Trac #16059: Equality vs hash for braid groups · 491dddc1
      Release Manager authored
      Playing with braid groups for a demo today, i want to see its Cayley
      graph in a neighbourhood of the neutral element:
      
      {{{
      
      ball = set()
      ball.add(B.one())
      for length in range(1,4):
          for w in Words(alphabet=B.gens(), length=length):
              ball.add(prod(w))
      G = B.cayley_graph(elements=ball, generators=B.gens())
      G.plot()
      
      }}}
      
      [[Image(Cayley_before.png)]]
      
      Hmmm, it looks locally like the free group, as if there was no relation
      !
      
      `s0 * s2` is a different vertex as `s2 * s0`, while:
      
      {{{
      sage: s0 * s2 == s2 * s0
      True
      }}}
      
      Indeed:
      
      {{{
      sage: hash(s0 * s2)
      954209079
      sage: hash(s2 * s0)
      1883627875
      }}}
      
      There should be a canonical representation for elements in Braid groups.
      At least, two equal elements should have the same hash. Currently,
      `cayley_graph` answers something wrong !
      
      After the modification, the Cayley group looks like:
      
      [[Image(Cayley_after.png)]]
      
      URL: http://trac.sagemath.org/16059
      Reported by: tmonteil
      Ticket author(s): Thierry Monteil
      Reviewer(s): Travis Scrimshaw
      491dddc1
    • Release Manager's avatar
      Trac #16224: incorrect translation of Bessel from Maxima? · 3e25c135
      Release Manager authored
      From [https://groups.google.com/forum/#!topic/sage-support/IgC78rcdO7c
      this sage-support thread]:
      {{{
      But other sums are simply wrong.
      
      k = var('k')
      sum(x^(2*k)/factorial(2*k),k,0,oo)
      
      gives
      
      -1/4*sqrt(2)*sqrt(pi)*x^(3/2)
      
      but the answer should be sinh(x).
      
      Hmm.  That shouldn't be happening, though I wouldn't be surprised if it
      didn't turn out as easy as that.
      
      (%i1) load(simplify_sum);
      (%o1) /Users/.../Sage-5.12-OSX-64bit-10.6.app/Contents/Reso\
      urces/sage/local/share/maxima/5.29.1/share/solve_rec/simplify_sum.mac
      (%i3) display2d:false;
      
      (%o3) false
      (%i4) simplify_sum(sum(x^(2*k)/factorial(2*k),k,0,inf));
      
      (%o4) sqrt(%pi)*bessel_i(-1/2,x)*sqrt(x)/sqrt(2)
      
      So I'm not sure why that would happen - maybe because of incorrect
      Bessel simplification?
      
      sage: maxima_calculus('bessel_i(-1/2,x)')
      bessel_i(-1/2,x)
      sage: _._sage_()
      sqrt(2)*sqrt(1/(pi*x))*cosh(x)
      
      That gives cosh(x), which I think is what you meant.
      }}}
      I don't know why this would happen, but presumably it should be possible
      to track down without too much effort.
      
      URL: http://trac.sagemath.org/16224
      Reported by: kcrisman
      Ticket author(s): Nils Bruin
      Reviewer(s): Peter Bruin
      3e25c135
    • Release Manager's avatar
      Trac #16362: Orthogonal Polar Graph · eeb33be7
      Release Manager authored
      Orthogonal Polar Graphs ! Brand new `O^+(m,q)`, `O^-(m,q)` and `O(m,q)`
      strongly regular graphs from Brouwer's website ! `:-P`
      
      Nathann
      
      URL: http://trac.sagemath.org/16362
      Reported by: ncohen
      Ticket author(s): Nathann Cohen
      Reviewer(s): Dima Pasechnik
      eeb33be7
    • Release Manager's avatar
      Trac #16216: Improve PEP8 compliance: replace "== None" by "is None" · 77361ccd
      Release Manager authored
      To cite from [[http://legacy.python.org/dev/peps/pep-0008/|PEP8]]:
      [[br]]
      Comparisons to singletons like None should always be done with is or is
      not, never the equality operators.
      
      This ticket is also related to a promise in ticket:15984.
      
      URL: http://trac.sagemath.org/16216
      Reported by: wluebbe
      Ticket author(s): Wilfried Luebbe
      Reviewer(s): Ralf Stephan
      77361ccd