Re: Excessive copies of set elements in GMPL

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
D:
    (1,2,4)
    (2,3,5)
    (3,4,6)
    (4,5,7)
    (5,6,8)
    (6,7,9)
    (7,8,10)
    (8,9,11)
    (9,10,12)
    (10,11,13)

====

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?
>