Re: [Help-glpk] Optimization and Multicore GLPK

[Reginald Beardsley]

I'd like to see an explanation of what the issue is surrounding making GLPK 
thread safe.

Not what or how, but why people think this is needed.  I can see benefits to 
making the matrix multiplies multithreaded, but that doesn't require making 
GLPK as a whole thread safe.  So I'm still baffled on this.  The solution I 
understand.  The problem I don't.  What are people trying to do that they can't 
do now?

As for version control, there is a strong benefit to having an accessible 
change history.  Particularly in tracking down bugs. However, I don't think 
there is any benefit to having multiple people modifying the code in a 
repository.  I think much preferable for people to send proposed changes to 
Andrew and if he accepts them they get integrated into the repository.  

So far as I know this is what's being done with Linux, though I don't really 
pay much attention.  I don't like Linux and disagree strongly with Torvalds on 
many things.


Much more useful in my view is people taking on chores like the wiki, setting 
up a profiling system, testing on major platforms, etc.  Doing what no one else 
is doing.  I'm trying to do what I don't see anyone else doing.  If someone is 
profiling GLPK using the Netlib corpus, please tell me and I'll find something 
else to work on.

A very serious issue in maintenance programming is style.  Sadly very few 
programmers understand the importance of matching the style of the existing 
code.  I don't like certain aspects of the style of GLPK.  In particular the 
lack of {} surrounding conditional statements.  My objection is not aesthetic, 
but practical.  You can't set breakpoints that are only triggered when the 
conditional is true.  However, I would not suggest for a moment that modifying 
GLPK to conform to this was worth the effort.  So if I write or modify GLPK 
code I will attempt to make it look as if Andrew wrote it.

I think collecting links or copies of relevant papers in a bibliography in the 
wiki would be a huge contribution. While Maros's book is more useful than any 
of the papers I've read so far, I wouldn't have found that book without the 
link Marc provided to Hall's work. Maros's book has in turn led to a couple of 
books on sparse matrix arithmetic that are now on my list.  I'm 3-4 hours drive 
from anything resembling a good library and can't afford the tariff for online 
access to the number of journals I would need to work effectively.  This makes 
links to online papers very valuable.

I found GLPK when the L1 solver from TOMS that I used for several years blew up 
on me and I went in search of a replacement.  I've been very impressed both by 
the code and the people associated with it. I may well be forced by my current 
project to develop a custom algorithm that takes account of particular 
structural aspects of the problem. At present I get a really good looking wrong 
answer.  Don't yet know why. But there's long term value to me to GLPK 
thriving.  So I'd like to contribute in whatever way I can. That way whenever I 
need a general LP/MIP solver I have one available.

Have Fun!
Reg

FWIW I don't like git and would suggest mercurial instead.  My personal 
preference is bare RCS, but that doesn't scale to multiple sites very well.


--- On Thu, 12/27/12, Robbie Morrison <address@hidden> wrote:

> From: Robbie Morrison <address@hidden>
> Subject: Re: [Help-glpk] Optimization and Multicore GLPK
> To: "GLPK help" <address@hidden>
> Cc: "Reginald Beardsley" <address@hidden>
> Date: Thursday, December 27, 2012, 4:41 PM
> 
> Hello Reg, Andrew, all
> 
> ------------------------------------------------------------
> To:           glpk <address@hidden>
> Subject:      [Help-glpk] Optimization and
> Multicore GLPK
> From:         Reginald
> Beardsley <address@hidden>
> Date:         Mon, 24 Dec 2012
> 17:37:22 -0800 (PST)
> ------------------------------------------------------------
> 
> > I am particularly interested in comments from
> > Andrew, Marc, Robbie and xypron.
> 
> Most of the suggestions thus far seem eminently
> sensible.  And continued development is essential
> to any software project -- otherwise the codebase
> will stagnate, quietly but surely.
> 
> I'll pick out a couple of items that stood out and
> then indicate my potential contribution.
> 
>  * making GLPK thread safe is regularly
>    requested and should be addressed
> 
>  * shifting to 'git' and a code hosting site
>    (GitHub or Savanna, for example) for this
>    development fork is essential -- which
>    then begs the question, why not move the
>    entire development effort to the same
>    repository
> 
> I don't have sufficient background in linear
> solvers or concurrent programming to contribute
> much.  But I will create a wikibook page, keep a
> list of papers and similar, and try and summarize
> the discussion.  I am also happy to be a
> non-technical 'git' maintainer (meaning I have
> no desire to approve code commits from others).
> 
> It is important, and possibly vital, that this
> development effort succeed.
> 
> best wishes, Robbie
> ---
> Robbie Morrison
> PhD student -- policy-oriented energy system simulation
> Technical University of Berlin (TU-Berlin), Germany
> University email (redirected) : address@hidden
> Webmail (preferred)       
>    : address@hidden
> [from Webmail client]
> 
> 
>