On Sunday, August 20, 2017 at 5:27:55 PM UTC+1, fidelbc wrote:
>
> Just created the ticket [1]. Not reported to GLPK, do you recommend to do
> so?
>
no, GLPK (with default parameters) is certainly not guilty here.
It's just a precision loss that is not avoidable while computing with
floating p
Just created the ticket [1]. Not reported to GLPK, do you recommend to do
so?
Wasn't sure who to CC, please edit the ticket if you have any suggestions.
[1]: https://trac.sagemath.org/ticket/23658#ticket
On Sunday, August 20, 2017 at 6:58:19 AM UTC-4, vdelecroix wrote:
>
> Might be due to round
Certainly, a procedure that carelessly adds inequalities to an LP formulation
solved by a solver working with a machine precision is going to exhibit this
sort of behaviour on a sufficiently bad example. Thus, yes, it should be fixed
by setting the default solver to be PPK.
--
You received thi
Might be due to roundoff issue (?). PPL does exact solving (using
rationals from GMP) while GLPK works with floating point numbers.
Though, on such small instance it looks suspicious that floating point
are to blame (especially if CBC/Coin works fine). Is there a Sage ticket
open? Was it report
Hello All,
Seems like the `fractional_chromatic_index` method for graphs contains a
bug.
The implementation contains an infinite loop that is broken when a quantity
is less than or equal to 1, however the loop never ends on the following
input:
sage: g=graphs.PetersenGraph()
sage: g.fractiona
