[Coin-discuss] Modeling Language

[Leo Lopes]

Dear Tim,

	Have you tried swiging (www.swig.org) FLOPC++ at all?

Thanks,
Leo.

Tim Hultberg wrote:

> 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
>>
> 
> 
> 
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss