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
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
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
On Wed, Aug 26, 2009 at 2:39 PM, Jason Groutjason-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 from
array end), however, I think it should be avoided if
On Aug 26, 2009, at 3:47 PM, William Stein wrote:
On Wed, Aug 26, 2009 at 2:39 PM, Jason Groutjason-
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
from
On Wed, Aug 26, 2009 at 7:56 PM, Robert
Bradshawrober...@math.washington.edu 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.
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 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)
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 Fri, Jul 3, 2009 at 3:35 PM, Nathann Cohennathann.co...@gmail.com 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
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
On Mon, Jun 29, 2009 at 1:08 PM, Nathann Cohennathann.co...@gmail.com 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
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
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
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 ;-)
On Mon, Jun 29, 2009 at 10:18 AM, Nathann Cohen nathann.co...@gmail.comwrote:
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
17 matches
Mail list logo
