[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Excessive copies of set elements in GMPL

From: Domingo Alvarez Duarte
Subject: Re: Excessive copies of set elements in GMPL
Date: Fri, 24 Jul 2020 08:58:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hello Michael !

What kind of problem do you expect ? Other than memory size requirements ?

Do you mean something like this:


set A := {1..10};
set B := {1..20};
set C := {1..30};

set D := { (a,b,c) in A cross B cross C : b=a+1 and c=b+2 };

printf "A count: %d\n", card(A);
printf "B count: %d\n", card(B);
printf "C count: %d\n", card(C);
printf "D count: %d\n", card(D);

display D;


A count: 10
B count: 20
C count: 30
D count: 10
Display statement at line 12


Cheers !

On 23/7/20 18:40, Michael Hennebry wrote:
On Tue, 21 Jul 2020, Domingo Alvarez Duarte wrote:

Do you have any example doing what you are talking about ?

In theory it should work.

Right now it process all models in the "examples" folder and the output is identical to the original GLPK/GMPL except that uses less memory and is slightly faster.

Things like the GMPL equivalent of { (a,b,c) in A x B x C : b=a+1, c=b+2 }
My understanding is that the current GMPL processor will form A x B x C
before applying the filtering.
If A, B and C have 100 items each, the inefficiency can probably be lived with. If they have 1,000 items each, it will be grindly slow, assuming it finishes.
If they have 10,000 items each,
the set will be to big for the handler to store.

Of course, done right, a set of 10,000 3-tuples should not be a problem.

On 21/7/20 15:24, Michael Hennebry wrote:
Are these changes supposed to deal with things like nested set iterations?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]