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

[Robert Fourer]

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


On 7/17/04 10:47 AM, "Yingjie Lan" <address@hidden> wrote:

> One interesting application of LP is the
> Markov Decision Process (MDP). To formulate
> such a problem, one need to define the
> state space as index to decision variables
> as well as to parameters, which would often be
> multidimensional and dimension-dynamic.
> 
> For example, let (s1, s2) denote jobs due
> on tomorrow and on the day after tomorrow,
> but the factory can only finish 'cap' each day.
> so the feasible pairs of (s1,s2) would be:
> 
> 
> #################################
> set ss := { 
>           (s1,s2) :
>               s1 in 0..cap and
>               s2+s1 in 0..2*cap
>          };
> #################################
> 
> This state space would enable us to plan
> for two days into the future. If the new
> feature has been implemented, we can do:
> 
> ###################################
> set ss:={
>          s{i in 1..2}:
>          sum{j in 1..i}s[j]<i*cap
>       };
> ###################################
> 
> The cool part for the second approach is that
> it can be easily extended to any days:
> 
> #########################################
> param horizon >0 integer;
> set ss:={
>          s{i in 1..horizon}:
>          sum{j in 1..i}s[j] < i*cap
>       };
> #########################################
> 
> I hope this can serve as an example, and I
> hope there are other situations where such
> feature can be convenient (I don't want to
> be selfish :).
> 
> Thanks,
> 
> Lan
> 
> 
> --- Andrew Makhorin <address@hidden> wrote:
>>> It seems to me very challenging to have this
>>> feature integerated into the language, isn't it?
>>> And it would certainly increase the power of
>>> the modeling language. I would appreciate any
>>> feed back from you. Thanks!
>> 
>> Thank you for your suggestion. Can you give a more
>> meaningful example
>> where such feature is needed?
>> 
>> 
>> 
> 
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
> 
> 
> _______________________________________________
> Help-glpk mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-glpk