[Coin-discuss] Modeling Language

[Tim Hultberg]

Here is my assesment of the current status of FLOPC++ with respect to the desirable properties below.

1) Back end compatibilty is easy to achieve with any AML package, thanks to COIN OSI. No issue here. 
Front end compatibilty: Modelling statements in FLOPC++ are C++ statements which when executed build a syntax tree representation of the model, later used for generating problem instances. It should be possible for "an external" parser to use the same classes to generate a representation of the parsed model. 
However I am not sure, the benefit of having multiple AML languages is big enough to make it worthwhile.

2) Open source? Yes.

3) Being imbedded in C++,  it is easier to incorporate/interface new technologies with FLOPC++ than with traditional AML.
In my opinion FLOPC++ scores high on the extensibilty ranking, due to the fact that modeling entities are C++ objects which can be passed as subroutine arguments, etc. making "higher order" modeling abstractions possible.
(For example support for "Slice Models", which in [Ferris & Voelker http://www.optimization-online.org/DB_FILE/2000/12/247.pdf] required relatively complicated extension to GAMS, could easily be build on top of FLOPC++)

a) C++ code emitter is not needed since the code is the model.
 
b) ,c) and d) Nothing is implemented at the moment. (But could be done - probably easier than with other solutions (see 3 above))


At the moment I think the 3 major limitations of FLOPC++ are:

I) Very little documentation is available. (but should be easy to use generalizing from the examples)

II) Lack of maturity: Still some memory management issues to be solved, (probably) still some bugs to be removed. Symbolic check of models still to be implemented. Compilation with other compilers, like Visual C++?

III) Non-linear modeling is not available. (This could be implemented, but would be complicate the code considerably. I think that a good and stable version for linear modeling should first be in place before this issue should be addressed.)


I have not been working on FLOPC++ for the last year, partly because of lack of time and partly because of lack of motivation (due to low rate of feed-back). If there are some people out there who are interested in developing an AML based on FLOPC++, I would certainly be motived and would find the time to participate. 

Best regards,
                       Tim Hultberg


Leo Lopes wrote:
>How much of this does FlopC++ provide now?

Alan King wrote:
> 
> My list for desireable propertes of a COIN AML package:
> 
> Philosophy:
> 1)  Compatibility.  Able to use your favorite AML language or package on 
> the front end, and favorite solver on the back end.
> 2)  Open source.  Source code level access to the parser input and 
> output methods and data structures.
> 3) Utility and extensibility.  Able to incorporate new features and 
> technologies of interest to the community, eg document processing and 
> web services standards.
> 
> Functionality:
> a)  Support multiple flavors of output methods.  Eg C++, Java source 
> code emitters.
> b)  Distributed construction of model data for distributed solution of 
> optimization problems.
> c)  Interface to other modeling paradigms, eg simulation, statistics, 
> etc, using AML namespaces.
> d) Model debuggers, anyone?
> 
> Alan
>