[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] Optimization and Multicore GLPK
From: |
Reginald Beardsley |
Subject: |
Re: [Help-glpk] Optimization and Multicore GLPK |
Date: |
Thu, 27 Dec 2012 16:45:00 -0800 (PST) |
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]
>
>
>