help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] Optimization and Multicore GLPK


From: Robbie Morrison
Subject: Re: [Help-glpk] Optimization and Multicore GLPK
Date: Fri, 28 Dec 2012 22:51:46 +1300
User-agent: SquirrelMail/1.4.22

Hi Reg, all

------------------------------------------------------------
To:           glpk <address@hidden>
Subject:      Re: [Help-glpk] Optimization and Multicore GLPK
From:         Reginald Beardsley <address@hidden>
Date:         Thu, 27 Dec 2012 16:45:00 -0800 (PST)
------------------------------------------------------------

I just picked out a couple of points, mostly
related to the process and not the technicalities.
Note too that some of the original post has been
reordered.

PROBLEM STATEMENTS

> The solution I understand.  The problem I don't.

The problems being addressed need to be fully
articulated and agreed upon.

VERSION CONTROL

> 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.

There are a number of workflows supported by
distributed version control systems.  xypron (if I
am not mistaken) has suggested this one in the
past:

  
http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow

> FWIW I don't like git and would suggest
> mercurial instead.

I think 'git' is, for better or worse, the default
for open source projects these days.

Bug tracking might also be helpful.  Again a
workflow and a maintainer need to be assigned.

CODE STYLE

> 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 doubt if there will be a problem with
"incorrect" coding.  The current codebase is so
utterly consistent.  Indeed, the style police
would be better occupied looking thru my wardrobe.

WIKIBOOK CHAPTER

> 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.

Good point.

I started marking up a wiki page:

  http://en.wikibooks.org/wiki/GLPK/Sandbox_%28for_content_under_development%29

The working title is: Code optimization and
concurrent execution effort.  Let me know (Reg
perhaps) if this can be improved upon.  Once the
real page is made, this chapter title will (more
or less) be set in stone.

I'll continue to work on the content over the new
year break.  All feedback gratefully received.

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]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]