Yo !
> this would mean that we will have to forbid the user to name them R.
> This is ugly...
Well, right now there is no defined constraint name and yet we have
one in .show()
Alternatively, when the users gives no constraint name, we could
define the name to be
"NobodyWouldChoseThisAsAConstrai
On 2015-04-28 14:22, kcrisman wrote:
even make an alias for it?
See http://trac.sagemath.org/ticket/13540
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-de
>
> > e.g. if your default solver is CPLEX then you'd doctest with
>> > --optional=sage,cplex
>> > and (ideally) should get no errors, etc.
>> >
>>
>> It introduces complications since nobody (?) uses
>>
>> sage -tp --all --optional=xyz
>>
>>
> I am using this (ok, call me nobody :-))
>
On Tuesday, 28 April 2015 12:56:57 UTC+1, Nathann Cohen wrote:
>
> Y !
>
> > I mean that if I currently set the default solver to Gurobi, there are
> few
> > failing
> > doctests, as Gurobi prints the LP a bit differently.
> > An example:
>
> Oh, those Right :-P
>
> Perhaps
Y !
> I mean that if I currently set the default solver to Gurobi, there are few
> failing
> doctests, as Gurobi prints the LP a bit differently.
> An example:
Oh, those Right :-P
Perhaps we could ' fix' them by saying in the gurobi backend that if
a constraint is named R or som
On Tuesday, 28 April 2015 11:16:04 UTC+1, Nathann Cohen wrote:
>
> > Perhaps I was not clear enough: I meant to say: make the
> solver-specific
> > doctests work; we talk about a dozen doctests or so...
>
>
> What do you mean by "make them work" ? We already have a lot of
> solver-specific d
> Like I already said in a different post, the hard part is defining this:
>>
>> a reasonable base of optional packages.
What about first trying with all of them, and see what happens? Most
optional packages I am involved with just add a new feature. Some of
them improve existing features, but the
Like I already said in a different post, the hard part is defining this:
On 2015-04-26 21:55, Vincent Delecroix wrote:
a reasonable base of optional packages.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and st
> Perhaps I was not clear enough: I meant to say: make the solver-specific
> doctests work; we talk about a dozen doctests or so...
What do you mean by "make them work" ? We already have a lot of
solver-specific doctests in the numerical/backends/ folder.
Nathann
--
You received this message
On Sunday, 26 April 2015 20:55:44 UTC+1, vdelecroix wrote:
>
> On 26/04/15 21:50, Dima Pasechnik wrote:
> > On Sunday, 26 April 2015 20:32:57 UTC+1, Nathann Cohen wrote:
> >>> I would advocate the approach that all the MILP tests are explicit
> about
> >> the
> >>> solver to be
> >>> used.
On 26/04/15 21:50, Dima Pasechnik wrote:
On Sunday, 26 April 2015 20:32:57 UTC+1, Nathann Cohen wrote:
I would advocate the approach that all the MILP tests are explicit about
the
solver to be
used. Indeed, it's not only COIN, but all the other solvers like CPLEX
behave this way.
Nathann, wou
On Sunday, 26 April 2015 20:32:57 UTC+1, Nathann Cohen wrote:
>
> Hellooo !
>
> > I would advocate the approach that all the MILP tests are explicit about
> the
> > solver to be
> > used. Indeed, it's not only COIN, but all the other solvers like CPLEX
> > behave this way.
> >
> >
Hellooo !
> I would advocate the approach that all the MILP tests are explicit about the
> solver to be
> used. Indeed, it's not only COIN, but all the other solvers like CPLEX
> behave this way.
>
> Nathann, would you mind this?
HM... Why would you gain? If you make all doctests invo
On 26/04/15 21:21, Dima Pasechnik wrote:
On Saturday, 25 April 2015 10:26:48 UTC+1, vdelecroix wrote:
Hello,
I have COIN-OR installed on my computer and hence MILP chooses it as a
default:
{{{
sage: default_mip_solver()
'Coin'
}}}
(it would have been GLPK otherwise)
It is annoying since a
On Saturday, 25 April 2015 10:26:48 UTC+1, vdelecroix wrote:
>
> Hello,
>
> I have COIN-OR installed on my computer and hence MILP chooses it as a
> default:
> {{{
> sage: default_mip_solver()
> 'Coin'
> }}}
> (it would have been GLPK otherwise)
>
> It is annoying since as a consequence t
On 25/04/15 12:16, Jeroen Demeyer wrote:
On 2015-04-25 12:11, Vincent Delecroix wrote:
But questions:
- is the coin-or answer reasonable?
- should we increase the tolerance in that particular place?
It looks like it's just typical floating point noise, so +1 to
increasing the tolerance.
#1829
Yo,
> Nope. It was just a report that the long doctest fails.
Well in this case the fix is straightforward: add a "# tol" wherever it breaks
> But questions:
> - is the coin-or answer reasonable?
> - should we increase the tolerance in that particular place?
Coin's answers always contain a lot
On 2015-04-25 12:11, Vincent Delecroix wrote:
But questions:
- is the coin-or answer reasonable?
- should we increase the tolerance in that particular place?
It looks like it's just typical floating point noise, so +1 to
increasing the tolerance.
--
You received this message because you are su
On 25/04/15 12:03, Nathann Cohen wrote:
I have COIN-OR installed on my computer and hence MILP chooses it as a
default:
{{{
sage: default_mip_solver()
'Coin'
}}}
(it would have been GLPK otherwise)
It is annoying since as a consequence the following fails:
What is your question?
Nope. It w
Yoo !
I have COIN-OR installed on my computer and hence MILP chooses it as a
> default:
> {{{
> sage: default_mip_solver()
> 'Coin'
> }}}
> (it would have been GLPK otherwise)
>
> It is annoying since as a consequence the following fails:
>
What is your question? Do you want to c
20 matches
Mail list logo
