RE: [Help-glpk] [feature] defining sets of dynamic dimensions?

[Sebastien . deMentendeHorne]

On another point of view, could it be possible to make the features of the
language available through the C API ?

This would allow to interactively add those sets in a dynamic way in C and
do much more than that in still a very high level way without cluttering the
declarative language with more dynamic constructions.

However, it may be very difficult to implement this as, currently, no link
is kept between the model expressed in the language and the underlying GLPK
C structure.

Just a thought on the topic...


> Sébastien de Menten   
> Risk Asset and Liability Management
> ELECTRABEL
> Place de l'Université, 16
> B-1348 Louvain-la-Neuve
> Tel : ++32 10 48 51 76 - Fax : ++32 10 48 51 09       
> Gsm : ++32 478 78 94 44 


-----Original Message-----
From: Yingjie Lan [mailto:address@hidden
Sent: mardi 20 juillet 2004 4:53
To: address@hidden
Subject: Re: [Help-glpk] [feature] defining sets of dynamic dimensions?


Let's don't talk about the implementation, it's too
early. But I don't think the language is going to
deteriorate as you might think. It is still simple
enough and completely compatible with what is already
there (the change to the language is totally
transparent to the user and to all previously written
models). I guess what you think might become messy is
that the implementation, right? 

So, you can have a new feature that simply adds to the
power of the language, and not a single harm done to
what's already there (I am not talking on
implementation level, which is too early yet).

Then about the syntax. I think the origional proposal
is similar to declarations  of variables and
parameters, which sounds logical to me because we are
to declare a tuple of dummy variables, which is like
an array, thus we can use the same syntax as
declarations  of variables and parameters, only one
thing: the dimension must be one, and the index set
must be ordered, for tuples are implicitly ordered.

Thank you,

Lan Yingjie

=============You wrote==============================
I agree that there are attractions to allowing for
sets whose dimension is
not fixed by the model, but is rather determined by
the data.  However the
quality of the modeling language will degrade rapidly
if features like this
are added in limited ways to satisfy particular needs.
 If multidimensional
sets are to be added at all, they should be made
available throughout the
language, wherever sets can be used.  This is a
potentially difficult
problem of design, not to mention implementation.

To preserve the logic of the current language design,
a new feature also
needs to be consistent with existing syntactic forms. 
So, since the current
language expresses a fixed-dimensional "tuple" as a
parenthesis-enclosed
list, like (s1,s2), a multidimensional tuple should
also be such a list, but
with some indexing enclosed.  It might be ({i in
1..horizon} s[i]), for
example.  I would particularly be wary of the proposed
s{i in 1..2}, because
it has the same syntactic form as an iterated operator
(like sum{j in 1..i})
but is in fact something completely different.

Bob Fourer
address@hidden



        
                
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/


_______________________________________________
Help-glpk mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/help-glpk