GitLab

Plenty of bugs have been reported for the interaction with numpy:
- #8426: polynomial * constant does not work if constant is a numpy type
- #8949: symbolic functions dont work with numpy.int32
- #9769: symbolic function do not work with numpy.int64 arguments
- #13386: comparison of Sage integer with Numpy integer
- #15695: Coercion problems between numpy and sage floats
- #17758: Intervals and numpy floats do not compare correctly
- #17865: get rid of _native_coercion_ranks_inv and
_native_coercion_ranks

We solve them all by defining coercions of numpy integers to `ZZ`, numpy
floating to `RDF` and numpy complex floating to `CDF`. Also, coercion
between numerical types (in `sage.structure.coerce`) are now done
directly via the addition. In particular, all of this used to fail
{{{
sage: import numpy

sage: f(t) = t^2
sage: f(numpy.int32('1'))
1

sage: sin(numpy.int32(10))
sin(10)

sage: 123 == numpy.int32(123)
True

sage: 1j + numpy.float(2)
2.00000000000000 + 1.00000000000000*I
sage: parent(_)
Complex Field with 53 bits of precision

sage: RIF(1) <= numpy.float64(2.0)
True
}}}

Some of them depend on modifying some internal in numpy and will not be
solved here:
- #8824: Make it so that numpy datatypes are integrated into the
coercion model

URL: http://trac.sagemath.org/18076
Reported by: vdelecroix
Ticket author(s): Vincent Delecroix, Jeroen Demeyer
Reviewer(s): Jeroen Demeyer, Vincent Delecroix

Some places in the code and some doctests assume that the filename
extension for shared libraries is `.so`, while it is `.dll` in cygwin.
The attached patch defines once and for all the correct extension
depending on the platform, and uses it where necessary.

URL: http://trac.sagemath.org/17682
Reported by: gouezel
Ticket author(s): Sebastien Gouezel
Reviewer(s): Jeroen Demeyer

We introduce evenly distributed sets (EDS) to get more difference
families and more BIBD in Sage. More precisely we add

- a database of small EDS
- a naive backtracker (that was actually used to build the database)

URL: http://trac.sagemath.org/17662
Reported by: vdelecroix
Ticket author(s): Vincent Delecroix
Reviewer(s): Nathann Cohen

The implementation of `is_squarefree()` for univariate polynomials
requires that the base ring is a PID. However, mathematically, the
question makes sense over any integral domain. Therefore, the condition
on the input can be relaxed.

The algorithm relies on `gcd()`, so the `gcd()` can still raise an
exception.

I don't know of any non-PID `R` in Sage for which the gcd in `R[x]`
works, so this won't change anything in practice.

URL: http://trac.sagemath.org/18276
Reported by: jdemeyer
Ticket author(s): Jeroen Demeyer
Reviewer(s): Bruno Grenet

The sage-support discussion is here:
https://groups.google.com/forum/#!topic/sage-support/9m5N0KUqkWo

I'm on OS X 10.10.3. I've removed homebrew from any part of the build.
I've updated sage to the develop branch.

The error still persists:
([http://www.google.com/url?q=http%3A%2F%2Fpaste.pound-python.org%2Fshow
%2FCSFQbBf722doPeyrXxJi%2F&sa=D&sntz=1&usg=AFQjCNE3nLaYMBJtas9IBEsp7q23P
8Odug full output])

{{{
gcc -std=gnu99 -I../../../../include -DNDEBUG -I../../../include
-I../../../../src/include -DHAVE_CONFIG_H -I../../../../src/extra/zlib
-fPIC  -g -O2   -c devQuartz.c -o devQuartz.o
In file included from /usr/include/Availability.h:153:0,
                 from /usr/include/stdio.h:65,
                 from ../../../../include/Rinternals.h:37,
                 from ../../../include/Defn.h:80,
                 from devQuartz.c:30:
/System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.fr
amework/Headers/FSEvents.h:486:41: error: expected ',' or '}' before
'__attribute__'
   kFSEventStreamEventFlagItemIsHardlink
__OSX_AVAILABLE_STARTING(__MAC_10_10, __IPHONE_9_0) = 0x00100000,
}}}

I suspect this needs another patch to fix up inappropriate objective-c
in the C code, similar to what was done for
[https://github.com/sagemath/sage/blob/master/build/pkgs/gcc/spkg-
install#L77,L78 dispatch/object.h], but I might be off base.

URL: http://trac.sagemath.org/18254
Reported by: buck
Ticket author(s): Buck Evan
Reviewer(s): John Palmieri, Volker Braun

As reported on `AskSage` [1], the function `.is_planar` can return wrong
results when given a specific embedding to run its computations on.

This actually comes from a mistake in a `if/else` and variable types, as
`bool(a_dictionary)` returns `True` when the dictionary is nonempty. The
original authors did not seem to be aware of that, and once fixed the
code does not make the mistake again.

The problem was that the computations were run on the cached embedding
(i.e `_embedding`) instead of the one provided by the user.

Nathann

[1] http://ask.sagemath.org/question/26301/testing-planarity-on-
embedding-gives-wrong-result/

URL: http://trac.sagemath.org/18045
Reported by: ncohen
Ticket author(s): Nathann Cohen
Reviewer(s): Vincent Delecroix

Tarball:
http://boxen.math.washington.edu/home/vbraun/upstream/threejs-r70.tar.gz

(modified to delete 200mb of examples)

URL: http://trac.sagemath.org/17823
Reported by: vbraun
Ticket author(s): Volker Braun
Reviewer(s): François Bissey, Andrey Novoseltsev

The following resultant computation used to lead to an infinite
recursion before #17974 (merged in 6.7.beta0):
{{{
sage: A.<a,c> = Frac(PolynomialRing(QQ,'a,c'))
sage: B.<d,e> = PolynomialRing(A,'d,e')
sage: R.<x> = PolynomialRing(B,'x')
sage: (a*d*x^2+a+e+1).resultant(-4*c^2*x+1)
Traceback (most recent call last):
...
RuntimeError: maximum recursion depth exceeded while calling a Python
object
}}}
Although this particular bug is now fixed, the doctest and the shortcut
added by this ticket may still be useful.

URL: http://trac.sagemath.org/17971
Reported by: pbruin
Ticket author(s): Peter Bruin
Reviewer(s): Vincent Delecroix

SemistandardTableaux_shape.cardinality() computes the cardinality by
summing over all the weight vectors that sum to the max_entry.  If the
max entry is much larger than 10, this becomes very slow.  Stanley's
hook content formula  (EC2 vol 2 corollary 7.21.4) is a much more
efficient way of computing the same number.

URL: http://trac.sagemath.org/18271
Reported by: deinst
Ticket author(s): David Einstein
Reviewer(s): Travis Scrimshaw

A formula of F. Bergeron and M. Haiman gives a Pieri rule for `h_r^\perp
{\tilde H}_\mu` and this formula can be used to compute the `H` and `Ht`
bases much quicker than previous implementations.  The current
implementation computes the `H` and `Ht` basis through the `J` basis and
this basis is implemented through creation operators.

For instance a command that takes a relatively long time to compute is
{{{
sage: %time H([3,2]).nabla(q=H.q,t=1/H.t)
CPU times: user 2.75 s, sys: 86.6 ms, total: 2.83 s
Wall time: 2.95 s
q^4/t^2*McdH[3, 2]
}}}
and with the new implementation the same command has the timing
{{{
CPU times: user 184 ms, sys: 18.7 ms, total: 203 ms
Wall time: 196 ms
}}}

One reason that some of the computations in the `H` and `Ht` bases take
a long time is that the entire basis a given degree is cached and so
subsequent computations will be faster.  However it seems that the new
implementation is cached more efficiently and is faster.

This ticket also catches an problem in `sage.combinat.nscf_qsym.qsym`
where `to_symmetric_function` constructs an element with support in
compositions.

URL: http://trac.sagemath.org/18194
Reported by: zabrocki
Ticket author(s): Mike Zabrocki
Reviewer(s): Travis Scrimshaw

{{{
sage: import sage.rings.polynomial.real_roots as rr
sage: x = polygen(QQ)
sage: rr.root_bounds(x)
(0, 0)
sage: rr.root_bounds(x+1)
(-1.00000000000000, -1.00000000000000)
sage: rr.cl_maximum_root_first_lambda([RIF(-1), RIF(0),
RIF(1)]).parent()
Real Field with 53 bits of precision and rounding RNDU
sage: type(rr.cl_maximum_root_first_lambda(map(RIF, [0, 0, 0, 14, 1])))
<type 'int'>
}}}

URL: http://trac.sagemath.org/18189
Reported by: mmezzarobba
Ticket author(s): Marc Mezzarobba
Reviewer(s): Vincent Delecroix

Many files in `sage/rings/*` are not in the documentation!

follow up: #18300

URL: http://trac.sagemath.org/18169
Reported by: mmezzarobba
Ticket author(s): Marc Mezzarobba
Reviewer(s): Vincent Delecroix

The documentation for {{{Integer.is_prime()}}} should document the
effect of the global proof.arithmetic flag. Similarly for the global
{{{is_prime}}} function.

URL: http://trac.sagemath.org/9903
Reported by: dmharvey
Ticket author(s): Marc Mezzarobba
Reviewer(s): Vincent Delecroix

If one has `Coin-or` installed (and a self compiled version of Sage)
then a doctest fails in the linear programming tutorial
{{{
sage -t linear_programming.rst
**********************************************************************
File "linear_programming.rst", line 432, in
doc.en.thematic_tutorials.linear_programming
Failed example:
    p.solve()  # rel tol 2e-12
Expected:
    2.0
Got:
    2.0000000000040004
Tolerance exceeded:
    2.0 vs 2.0000000000040004, tolerance 2e-12 > 2e-12
**********************************************************************
}}}
We just increase the tolerance to `2e-11`.

See also [https://groups.google.com/forum/#!topic/sage-devel/XpvyN3FzGEs
this sage-devel thread].

URL: http://trac.sagemath.org/18297
Reported by: vdelecroix
Ticket author(s): Vincent Delecroix
Reviewer(s): Nathann Cohen

{{{
sage: W = Words('ab', 50)
sage: W
Words of length 50 over {'a', 'b'}
sage: w = W.random_element()
sage: w.length()
+Infinity
}}}

URL: http://trac.sagemath.org/18283
Reported by: vdelecroix
Ticket author(s): Vincent Delecroix
Reviewer(s): Nathann Cohen

with gcc 4.9.2, we hit this bug:

[https://gcc.gnu.org/gcc-4.9/porting_to.html Header <cstddef> changes]
The <cstddef> header was updated for C++11 support and this breaks some
libraries which misuse macros meant for internal use by GCC only. For
instance with GMP versions up to 5.1.3, you may see:
{{{
/usr/include/c++/4.9.0/cstddef:51:11: error: ‘::max_align_t’ has not
been declared
   using ::max_align_t;
}}}

This has hit here: #18198, see also [https://groups.google.com/d/msg
/sage-devel/Tu-egDn-zLw/0S5ouau2J1AJ sage-devel thread]

The workaround suggested by the gcc people appears to work.

URL: http://trac.sagemath.org/18240
Reported by: dimpase
Ticket author(s): Dima Pasechnik
Reviewer(s): Jakob Kroeker, Leif Leonhardy

This ticket implements the incidence algebra of a poset and the reduced
incidence algebra for finite posets.

URL: http://trac.sagemath.org/17575
Reported by: tscrim
Ticket author(s): Travis Scrimshaw
Reviewer(s): Frédéric Chapoton

Also sphinxify or fix their docstrings as necessary for the reference manual to
build (but not necessarily to look good).