[Top][All Lists]

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

Re: [Help-glpk] Database connectivity in MathProg

From: glpk xypron
Subject: Re: [Help-glpk] Database connectivity in MathProg
Date: Sat, 09 Feb 2008 22:36:59 +0100

Hello Andrew,

> > Definitions should be made in the model:
> > table TABLENAME;
> > Before the the minimize statement read statements can be used to fill
> sets
> > and parameters:
> > read table TABLENAME;
> In principle, in MathProg this statement is not needed. Any reference
> to a set or parameter, which is linked to a table in the data section,
> from an expression to be evaluated could automatically perform reading
> the corresponding table. Can this statement be omitted in AMPL?

In the proposed subset of the AMPL table statement, ommitting read table might 
be feasible.

I would like to see the door left open to implement the full AMPL syntax. Here 
tables might be defined as:

set NUTR = { i in PROD : i > 5 };

table TABLENAME1 IN ... :
{ i in NUTR : i in MAXREQ } -> [ i ~ keycol1 ], par[i];

table TABLENAME2 IN ... :
PROD <- [prod];

Having the MathProg interpreter decide when which of the two tables shall be 
read will become challenging.

Hence I propose to stick to table read and table write.

> I need a time to think over this new feature and necessary changes in
> the translator. Probably the first step could be implementing tables
> in a flat (text or csv) format.

AMPL has the idea to provide multiple data base handers, one of which is for 
text files. Implementing a handler for a text file data base first is a good 
idea. This handler then can serve as template for the SQL handlers.

The definition in AMPL is that if the first and only string of the string-list 
of the table declaration is of the form "" the data is read from or 
written to a file in AMPL tab format.

It is a bit awkward to mix up naming of files and file format. I would rather 
like to see one string defining the handler and intrinsicly the file format and 
another the filename, e.g.  
table TABLENAME 'CSV' 'data.csv' : ... ;

Supporting the AMPL specific file format is of limited. Supporting CSV would be 
a good choice as often data is available in spreadsheets and CSV export will be 
available. I propose to use the definition in RFC 4180 "Common Format and MIME 
Type for Comma-Separated Values (CSV) Files" 
 When reading, files with LF instead of CRLF (required by RFC 4180) should be 

Best regards

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen:

reply via email to

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