Re: [Help-glpk] Database connectivity in MathProg

[glpk xypron]

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 "filename.tab" 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" 
(http://rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=4180&type=ftp&file_format=txt).
 When reading, files with LF instead of CRLF (required by RFC 4180) should be 
acceptable.

Best regards

Xypron
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger