help-glpk
[Top][All Lists]
Advanced

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

Re: [Help-glpk] Generate data section files for model (in GNU MathProg o


From: Robbie Morrison
Subject: Re: [Help-glpk] Generate data section files for model (in GNU MathProg or other languages)
Date: Thu, 10 May 2012 09:16:04 +1200
User-agent: SquirrelMail/1.4.22

Hello again Tony

------------------------------------------------------------
To:           Robbie Morrison <address@hidden>
Subject:      Re: [Help-glpk] Generate data section files for model (in GNU
Message-ID: 
<address@hidden>
From:         Tony Khosravi <address@hidden>
Date:         Wed, 9 May 2012 22:29:12 +0200
------------------------------------------------------------

> Thanks for that Robbie
>
> 2012/5/9 Robbie Morrison <address@hidden>

[snip : original problem statement]

>> I am not aware of any GLPK functions, official or
>> internal, that do what you suggest.  Someone else may
>> know for sure.
>>
>> The following Boost C++ libraries may be of interest:
>>
>>    http://www.boost.org/doc/libs/1_49_0/
>>
>>    Boost.Smart_ptr
>>    Boost.Format
>>    Boost.Filesystem
>>
>> Or STL std::ostringstream instead of Boost.Format.
>>
>> Depending on your skill levels, maybe also C++ functors, custom
>> steam inserters, and the following:
>>
>>   Boost.Bind
>>   Boost.Lambda
>>
>> It would seem that fully fledged parsing is not
>> indicated, otherwise see Boost.Spirit.
>>
>> Write tight classes with clearly defined roles and
>> revisit your design if you are starting to code
>> spaghetti.  Think very carefully about the kind of
>> abstractions the language supports and use those to
>> your advantage.  Unit testing is also be useful.  Its
>> a learning curve, for sure.
>>
>> Finally, I guess that the specification for MathProg is
>> well thought through, although I don't use the
>> language myself.
>>
>> That is about as specific as I can be in the
>> circumstances.
>>
>> good luck
>> ---
>> 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]
>
> I knew the Boost library, but I never used them. I
> wanted to stay with the standard library and not use
> any extra library (the code that I am developing ought
> to be used by others people on other machine and there
> are not computer science people, so I want to keep
> things simple and in the standard c++ box).
>
> I will have a look anyway on those libraries that Boost
> provides.
>
> As you mentioned, I wanted to use some functors and/or
> template to achieve this kind of translator to the
> MathProg format.  I guess this is what I wil try to do.
>
> Thanks for the help anyway.
>
> Regards,
>
> --
> *Tony Khosravi Dehkourdi*
>
> MSc. Student - Computer Systems
> *Linköping University*
> Elève ingénieur -- Génie Informatique, Systèmes et Réseaux d'Informations
> (GI06)*
> Université de Technologie de Compiègne*
> Tel:+46 7 60 69 51 57

It makes sense for GLPK to stay within strict ISO C for
maximum portability.  But I think that your kind of
software could afford to make Boost a dependency.
Besides many of the Boost libraries have or are
migrating to the C++ standard library.  In addition,
many are header-only and you could copy the relevant
headers into your codebase if you wish.

Moreover I would think that adopting generalized
libraries like Boost.Filesystem would actually improve
your portability, not lessen it.

Also, a special plug for reference-counted 'shared_ptr'
pointers!  Wonderful things.

By-the-way, the GLPK wikibook has a page for GLPK
projects:

  http://en.wikibooks.org/wiki/GLPK/Application_projects_utilizing_GLPK

You might like to add a couple of sentences about your
software?

good luck with the coding
---
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]