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

[Yingjie Lan]

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/