On Wed, Aug 26, 2009 at 03:47:05PM -0700, William Stein wrote:
> On Wed, Aug 26, 2009 at 2:39 PM, Jason Grout
> wrote:
> > I should mention that at various times, people have proposed that you
> > could create symbolic variables x[1], x[2], etc. As far as I know,
> > these proposals have just be
Hi,
On Thu, Aug 27, 2009 at 1:00 AM, William Stein wrote:
>
> On Wed, Aug 26, 2009 at 7:56 PM, Robert
> Bradshaw wrote:
x[1], and then x[1] would create another symbolic variable x[1][1].
>>>
>>> That sounds pretty easy to implement by defining __getitem__ for
>>> symbolic variables, a
Maybe I misunderstood your question about indexed variables, you do
can create and use arrays of oovars and oofuns, eg
from FuncDesigner import *
N = 100
a = oovars(N) # create array of N oovars
b = oovars(N) # another array of N oovars
some_lin_funcs = [i*a[i]+4*i + 5*b[i] for i in xrange(N)]
f =
On Wed, Aug 26, 2009 at 7:56 PM, Robert
Bradshaw wrote:
>>> x[1], and then x[1] would create another symbolic variable x[1][1].
>>>
>>
>> That sounds pretty easy to implement by defining __getitem__ for
>> symbolic variables, and making it cache its answer using a dictionary.
>
> I've advocated fo
On Aug 26, 2009, at 3:47 PM, William Stein wrote:
> On Wed, Aug 26, 2009 at 2:39 PM, Jason Grout s...@creativetrax.com> wrote:
>>
>> Nathann Cohen wrote:
Yes, you can use indexation like some_oovar[i] or some_oofun[i]
(probably with several indexes, or negative ones that are start
>>>
On Wed, Aug 26, 2009 at 2:39 PM, Jason Grout wrote:
>
> Nathann Cohen wrote:
>>> Yes, you can use indexation like some_oovar[i] or some_oofun[i]
>>> (probably with several indexes, or negative ones that are start from
>>> array end), however, I think it should be avoided if possible (you'd
>>> bet
Nathann Cohen wrote:
>> Yes, you can use indexation like some_oovar[i] or some_oofun[i]
>> (probably with several indexes, or negative ones that are start from
>> array end), however, I think it should be avoided if possible (you'd
>> better split your oovar into several
>> oovars).http://www.ope
> Yes, you can use indexation like some_oovar[i] or some_oofun[i]
> (probably with several indexes, or negative ones that are start from
> array end), however, I think it should be avoided if possible (you'd
> better split your oovar into several
> oovars).http://www.openopt.org/FuncDesignerDoc#S
On Aug 26, 7:47 pm, Nathann Cohen wrote:
> Hello !
>
> > You could be interested in the approach implemented in FuncDesigner LP
> > model:http://openopt.org/NumericalOptimizationForFuncDesignerModels#LP_example
> > Maybe in future I'll add FuncDesigner examples for MILP and some more
> > classes.
Hello !
> You could be interested in the approach implemented in FuncDesigner LP
> model:http://openopt.org/NumericalOptimizationForFuncDesignerModels#LP_example
> Maybe in future I'll add FuncDesigner examples for MILP and some more
> classes.
I *AM* interested in this... Thanks for the informa
Hi all,
I have been pointed to the discussion some time ago.
You could be interested in the approach implemented in FuncDesigner LP
model:
http://openopt.org/NumericalOptimizationForFuncDesignerModels#LP_example
Maybe in future I'll add FuncDesigner examples for MILP and some more
classes.
Let m
On Mon, Jun 29, 2009 at 04:08:28AM -0700, Nathann Cohen wrote:
>
> Hello everybody
>
> I have already sent a few messages about this and complained for a
> while. The only way for the moment to solve Linear Programs (
> http://en.wikipedia.org/wiki/Linear_programming ) is CVXOPT, a library
Hmmm Could this kind of behaviour come fro the sole fact that I do
not use a "good" version of some software ?
sage: setup()
---
SystemExitTraceback (most recent call
last)
/auto/sop-nas2a
On Fri, Jul 3, 2009 at 3:35 PM, Nathann Cohen wrote:
>
> Hmmm... I began to write the interface to CBC to notice that the
> libraries was writtten in C++ and that I needed to wrap C++ classes
> into Cython, which I do not know how to do ... I read several manuals
> and end up with compilation fail
Hmmm... I began to write the interface to CBC to notice that the
libraries was writtten in C++ and that I needed to wrap C++ classes
into Cython, which I do not know how to do ... I read several manuals
and end up with compilation failures I do not know how to fix :
sage: execfile("setup.py")
On Mon, Jun 29, 2009 at 10:18 AM, Nathann Cohen wrote:
>
> It may be a good idea to interface to OSI in order to avoid having to
> interface to both CPLEX and COIN-OR, but for license reasons we can
> not use OSI to interface to GLPK as OSI is GPL-Uncompatible and the
> only reason we want glpk in
It may be a good idea to interface to OSI in order to avoid having to
interface to both CPLEX and COIN-OR, but for license reasons we can
not use OSI to interface to GLPK as OSI is GPL-Uncompatible and the
only reason we want glpk installed by default is that it is the only
gpl LP solver ;-)
Nath
If you're considering interfacing to commercial libraries,
you should definitely consider MOSEK (www.mosek.com),
which is an excellent commercial convex optimization package
that includes conic MIP.
CVXOPT also interfaces to MOSEK, which has a native Python
interface.
Joachim
On Jun 29, 3:09 p
COIN-OR has a project called OSI, the open solver interface, for its own
lp solver clp but also CPLEX and GLPK (among others, see:
https://projects.coin-or.org/Osi/), so only this OSI has to be interfaced
to SAGE, to get all generality in lp solving.
In my understanding, cbc can solve mixed-integ
On Mon, Jun 29, 2009 at 1:08 PM, Nathann Cohen wrote:
>
> Hello everybody
>
> I have already sent a few messages about this and complained for a
> while. The only way for the moment to solve Linear Programs (
> http://en.wikipedia.org/wiki/Linear_programming ) is CVXOPT, a library
> focused o
Thanks for working on this! I agree with the points in your email.
LP solvers are an important topic where I teach so I am happy to
help. I think some of my colleagues would be very interested in
trying out whatever is developed. I'm not an operations
research person myself but would be intereste
21 matches
Mail list logo
