help-glpk
[Top][All Lists]

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

```