[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 "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
- [Help-glpk] Database connectivity in MathProg, Ted Poe, 2008/02/01
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/04
- Re: [Help-glpk] Database connectivity in MathProg, xypron, 2008/02/08
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/09
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/09
- Re: [Help-glpk] Database connectivity in MathProg,
glpk xypron <=
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/09
- Re: [Help-glpk] Database connectivity in MathProg, glpk xypron, 2008/02/10
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/10
- Re: [Help-glpk] Database connectivity in MathProg, glpk xypron, 2008/02/10
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/10
- Re: [Help-glpk] Database connectivity in MathProg, glpk xypron, 2008/02/11
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/12
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/10
- Re: [Help-glpk] Database connectivity in MathProg, glpk xypron, 2008/02/11
- Re: [Help-glpk] Database connectivity in MathProg, Andrew Makhorin, 2008/02/16