Re: [sage-release] Sage 7.2.beta1 released

58 views
Skip to first unread message

Vincent Delecroix

unread,
Mar 28, 2016, 5:20:01 PM3/28/16
to sage-r...@googlegroups.com, sage-devel
Hello,

I got problems building the doc for "knots" (see attached log obtained
without parallel build). I am alone in that case?

Vincent

On 28/03/16 12:16, Volker Braun wrote:
> As always, you can get the latest beta version from the "develop" git
> branch. Alternatively, the self-contained source tarball is at
> http://www.sagemath.org/download-latest.html
>
> c690443 Updated Sage version to 7.2.beta1
> 1e5fb03 Trac #20269: Inconsistent return types in real_roots
> 24f2049 Trac #20307: PyPI Updates
> 64cc57c Trac #20283: Discrete valuation rings are Euclidean domains
> feeeff9 Trac #20257: Deprecate undocumented arguments to PARI functions
> 0fd2759 Trac #20098: doctest fix for: Re/Im(tanh) wrong formula
> 807846b Trac #17493: bind SymPy's ComplexInfinity
> 0a2df8e Trac #16203: conversion from SR.series to PowerSeries
> 09796ea Trac #20275: Fix typos in "default"
> 348ee09 Trac #20235: Enable warnings when compiling Sage library
> 17ff357 Trac #20234: Fix typos in "algorithm"
> 94685aa Trac #20289: pep8 cleanup in game_theory
> e481501 Trac #20236: Use sagelib-VERSION.log for Sage library log
> 5196015 Trac #16523: Relative vector spaces for function fields
> 9d4c00d Trac #20292: Fix weight function and category for alcove path model
> 5da8286 Trac #12603: copying cached_methods does not work properly
> e88cb55 Trac #6018: Confusing behaviour with Dirichlet characters
> da39d48 Trac #20299: Binary tarball sanity check when running make
> c422948 Trac #20286: Constructing matrix from numpy ignores ring
> bc6e438 Trac #20279: Homogeneous coordinates of polyhedron V-representation
> objects
> aead72c Trac #19824: Faster comparison code in (real embedded) number fields
> 453a37d Trac #19821: Increase speed for Coxeter groups, Weyl groups, and
> quantum Bruhat graph
> 84c522e Trac #17030: Knot Theory as a part of GSoC 2014.
> bbc0be0 Trac #20281: fix flintxx development
> 8232da7 Trac #20277: Implement intersection of LibGAP groups
> 7ac0c4d Trac #20276: Convert groups to libgap
> b117b30 Trac #20267: Comparison with EmptyLetter fails
> cc52fe3 Trac #20256: Implement conversion Infinity <-> PARI
> fa0c207 Trac #20253: bug in strongly connected test for static digraphs
> 4ec27fa Trac #20174: Avoid recomputing vacancy numbers for rigged
> configurations
> 8e0e439 Trac #20220: GCD of polyomials over polynomial rings
> 073357a Trac #19884: LatticePosets: Add is_relatively_complemented()
> 5283d59 Trac #17330: Take in the module OEIS the keyword 'dead' of
> sequences into account.
> edd4a5c Trac #20252: Allow sage-uncompress-spkg to work with Python 2.6
> 930e35e Updated Sage version to 7.2.beta0
>
doc.log

Volker Braun

unread,
Mar 28, 2016, 6:19:48 PM3/28/16
to sage-devel, sage-r...@googlegroups.com
I take it you haev CPLEX installed...

Vincent Delecroix

unread,
Mar 28, 2016, 6:29:10 PM3/28/16
to sage-r...@googlegroups.com, sage-devel
Yes I do. I see. Having plot code that is sensitive to the LP solver is
bad. Is there already a ticket opened?

Vincent Delecroix

unread,
Mar 28, 2016, 6:31:26 PM3/28/16
to sage-r...@googlegroups.com, sage-devel
Indeed, minimal failing example

sage: L = Link([[2,1,4,5], [5,6,7,3], [6,4,1,9], [9,2,3,7]])
sage: L.plot()
Traceback (most recent call last):
...
MIPSolverException: 'CPLEX: The primal has no feasible solution'

Vincent Delecroix

unread,
Mar 28, 2016, 7:04:59 PM3/28/16
to sage-r...@googlegroups.com, sage-devel
#20315

Dima Pasechnik

unread,
Mar 28, 2016, 7:12:39 PM3/28/16
to sage-release, sage-...@googlegroups.com


On Monday, March 28, 2016 at 11:29:08 PM UTC+1, vdelecroix wrote:
Yes I do. I see. Having plot code that is sensitive to the LP solver is
bad. Is there already a ticket opened?

I always maintained that the design when installation of a solver makes it default
is bad, but to no avail...

well, one cannot expect all the LP solvers be tested here, no? Especially CPLEX
and other solvers for which one has potentially to pay...

Vincent Delecroix

unread,
Mar 28, 2016, 7:16:42 PM3/28/16
to sage-r...@googlegroups.com, sage-devel
On 28/03/16 20:12, Dima Pasechnik wrote:
>
>
> On Monday, March 28, 2016 at 11:29:08 PM UTC+1, vdelecroix wrote:
>>
>> Yes I do. I see. Having plot code that is sensitive to the LP solver is
>> bad. Is there already a ticket opened?
>>
>
> I always maintained that the design when installation of a solver makes it
> default
> is bad, but to no avail...
>
> well, one cannot expect all the LP solvers be tested here, no? Especially
> CPLEX
> and other solvers for which one has potentially to pay...

This is actually very good (and GLPK is very bad): the LP constraints
polyhedron is empty (see #20315)!! I am very happy that Sage is tested
accross various LP solvers to detect that kind of things.

Vincent
Reply all
Reply to author
Forward
0 new messages