R + GLPK

[Dr. David Kirkby]

I know GPLK was added to Sage recently, and also that R is in Sage. I don't know
if there is any advantage, but there is a GLPK package for R.

http://cran.r-project.org/web/packages/glpk/vignettes/glpk-intro.pdf

I don't know if there is any advantage in making that.

I assume it would be fairly easy as long as GLPK was built before R.

Dave

[François Bissey]

On a similar note cvxopt can make use of glpk as well.

Francois

[Nathan Dunfield]

> On a similar note cvxopt can make use of glpk as well.

Yes, it can --- I was just using this yesterday.

The trick is that you have to tell cvxopt that glpk is available when
it is compiled/installed. Now that glpk is standard, the install
script for cvxopt should be told to make use of it. You just need to
edit a couple of lines in setup.py to make this happen. Has this
already been done, or should I file a patch for this?

Best,

Nathan

[Nathann Cohen]

> Has this
> already been done, or should I file a patch for this?

If you would be so kind... I saw no mention of it until I read your
message :-)

Nathann

[Dr. David Kirkby]

I strongly suspect you would also need to make sure glpk builds before cvxopt by
editing spkg/standard/deps. The cvxopt entry would then look like this.

$(INST)/$(CVXOPT): $(BASE) $(INST)/$(FORTRAN) $(INST)/$(F2C) \
$(INST)/$(LAPACK) $(INST)/$(BLAS) $(INST)/$(NUMPY) \
$(INST)/$(ATLAS) $(INST)/$(CEPHES) $(INST)/$(GLPK)

If you wanted to use the GLPK library in R, then the R entry would need to be
modified by adding the "$(INST)/$(GLPK)" on the end too.

You might find it works without doing the above, but unless you specify the
build order, it will be semi-random, especially with parallel builds.

Dave

[François Bissey]

Just checked the source, it is definitely a build time dependency so
this is needed otherwise the build will fail.
However as far as I can see cvxopt shouldn't depend on numpy (unless
that's a change between version 0.9 and 1.1).

Francois

[dahl.j...@gmail.com]

CVXOPT has no dependencies on Numpy (but can exchange data with
Numpy arrays efficiently via a buffer protocol).

[David Kirkby]

In my email above, I just appended '$(INST)/$(GLPK)' to the end of the
CVXOPT line as it currently is in spkg/standard/deps.. I did not add
NUMPY myself. If a dependency can be removed, it would be useful, as
it might permit more efficient parallel builds.

Dave

[François Bissey]

> In my email above, I just appended '$(INST)/$(GLPK)' to the end of the
> CVXOPT line as it currently is in spkg/standard/deps.. I did not add
> NUMPY myself. If a dependency can be removed, it would be useful, as
> it might permit more efficient parallel builds.

sorry Dave, I didn't imply you did. I just noticed it on the dependency
list you quoted and thought it was odd and then checked.

Francois

[David Kirkby]

No problem. There are a few changes that could be usefully added to 'deps'

1) SAGETEX does not show a dependency of BASE. It is implied by a long
chain rule, but it is unique in being the only package not to show
this more explicitly
2) R does not show a dependency to FORTRAN - though again it is
implied by a very long chain rule.
3) GLPK should be built before R if we ever hope to use it in R
4) GLPK should be built before CVXOPT if there is any hope of using
those together.
5) If what is said in this thread is correct, NUMPY should be removed
as a dependency of CVXOPT.
6) William has agreed GNU patch can be added, so that needs the
'patch' package installed.

I've built the 'patch' package. If nobody beats me to it, I'll sort
these issues out when I add GNU patch.

Dave

[Nathan Dunfield]

Ok, I'll do it in the next couple of days, taking into account David's
comment about skpg build order.

Nathan

[Robert Miller]

On Thu, Jul 15, 2010 at 1:51 PM, David Kirkby <david....@onetel.net> wrote:
> 3) GLPK should be built before R if we ever hope to use it in R
> 4) GLPK should be built before CVXOPT if there is any hope of using
> those together.

Shouldn't we wait until we implement using GLPK from these? Otherwise
we are potentially slowing down parallel builds...

--
Robert L. Miller
http://www.rlmiller.org/

[David Kirkby]

Theoretically that is true. But GLPK builds really quickly - in under
6 seconds on my computer, using a little over 15 s of CPU time.

drkirkby@hawk:~/sage-4.5.rc0$ ./sage -f glpk-4.44
<SNIP>
real 0m5.295s
user 0m11.287s
sys 0m4.012s
Successfully installed glpk-4.44

That's on a 3.33 GHz Sun Ultra 27, but it is still a very small
fraction of the time it takes to build Sage, which is around 30
minutes, though R and Maxima are not building, so I rekon it would be
closer to 35 or 40 minutes. That makes the time to build GLPK less
about 0.25% of the total time to build Sage.

My logic for suggesting doing them all at once was:

* Updating 'deps' is a bit of a pain, since its not under revision
control, so it would be worth getting all the changes in at one time.
* It would make testing the integration a bit easier, if the
dependencies were already in place.

Perhaps I'm missing something, and the penalty to build Sage could be
higher than the time it takes to build GLPK, but I don't think that
would be the case. In fact, I suspect it would be less than that.

Dave

[Nathan Dunfield]

Done, including patch, at

http://trac.sagemath.org/sage_trac/ticket/9598

Also, I'll mention that the version of cvxopt that comes with Sage is
three years old. The current version, unfortunately, uses a slightly
different interface for GLPK. Sage has version 0.9 in which GLPK
support seems to have been in beta, or maybe they just changed some
function names moving to the current version 1.1.

Nathan