1. 04 May, 2015 1 commit
2. 28 Apr, 2015 4 commits
• Updated Sage version to 6.7.beta3 · e55e3153
Volker Braun authored
• Trac #18076: Coercion for numpy types · 93a7ac62
Release Manager authored
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
• Trac #17682: Generic filename extension for shared libraries · 636a9268
Release Manager authored
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
• Trac #17662: Evenly distributed sets · b549ae17
Release Manager authored
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
3. 27 Apr, 2015 13 commits
• trac #17662: Review · 007b862b
Nathann Cohen authored
• Trac 17662: doc improvements · 7224a147
Vincent Delecroix authored
• Trac 17662: fix _check_cosets method · 0a750d92
Vincent Delecroix authored
• trac #17662: Review · ef2a71fe
Nathann Cohen authored
• trac #17662: Merged with 6.7.beta2 · 617852bf
Nathann Cohen authored
• Trac #18276: is_squarefree() should not restrict to PID's · 89b92ebc
Release Manager authored
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
• Trac #18254: osx R spkg error: expected ',' or '}' before '__attribute__' · ad793324
Release Manager authored
The sage-support discussion is here:

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:
%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__'
__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
• Trac #18045: Wrong result returned by is_planar on a given embedding · f61f16b6
Release Manager authored
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

embedding-gives-wrong-result/

URL: http://trac.sagemath.org/18045
Reported by: ncohen
Ticket author(s): Nathann Cohen
Reviewer(s): Vincent Delecroix
• Trac #17823: Three.js optional package · 0f523eab
Release Manager authored
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
4. 26 Apr, 2015 4 commits
5. 25 Apr, 2015 18 commits
• Trac #17971: Infinite recursion when taking a resultant over a complicated base ring · 8c4f3458
Release Manager authored
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
• Trac #18271: Stanley hook content formula · 0bc22577
Release Manager authored
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
• Trac #18194: Speedup of calculation of Macdonald H and Ht bases · 689d2aed
Release Manager authored
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
• Trac #18189: real_roots.root_bounds: Inconsistent return types · 4f148028
Release Manager authored
{{{
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
• Trac #18169: Ref: add various missing modules to r/*rings* · 47c830d7
Release Manager authored
Many files in sage/rings/* are not in the documentation!

URL: http://trac.sagemath.org/18169
Reported by: mmezzarobba
Ticket author(s): Marc Mezzarobba
Reviewer(s): Vincent Delecroix
• Trac #9903: is_prime should document proof flag · 066de7a0
Release Manager authored
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
• Trac #18297: Increase tolerance in a doctest in linear programming tutorial · 98c1e7cc
Release Manager authored
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.

URL: http://trac.sagemath.org/18297
Reported by: vdelecroix
Ticket author(s): Vincent Delecroix
Reviewer(s): Nathann Cohen
• Trac #18283: Words random element is wrong · 5ae753aa
Release Manager authored
{{{
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
• Trac #18240: fix MPIR's compliance with c++ · 5b5a4c0d
Release Manager authored
with gcc 4.9.2, we hit this bug:

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;
}}}

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
• Trac #17575: Implement incidence algebra of a (finite) poset · 43bda958
Release Manager authored
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
• #9903 additional example · 7b687fdf
Vincent Delecroix authored
• Trac 18297: increase doctest tolerance · 6494c992
Vincent Delecroix authored
• Trac 18283: doctest · 6882809c
Vincent Delecroix authored
• Ref: add various missing modules to r/*rings* · 54df1d66
Marc Mezzarobba authored
Also sphinxify or fix their docstrings as necessary for the reference manual to
build (but not necessarily to look good).
• sage.rings.bern*: rst fixes · 9ed1b176
Marc Mezzarobba authored
• number_field.totallyreal_*: rst fixes · f7c0fa28
Marc Mezzarobba authored
• polynomial_compiled: rst fixes · cf23812d
Marc Mezzarobba authored