help-glpk
[Top][All Lists]
Advanced

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

Re: [Fwd: Re: [Fwd: Re: [Fwd: MathProg set vs param]]]


From: Mate Hegyhati
Subject: Re: [Fwd: Re: [Fwd: Re: [Fwd: MathProg set vs param]]]
Date: Tue, 30 May 2023 10:29:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0

Hi!

I think I might understand your issue. Here are several thoughts, where I tried to look at things from your perspective:

Yes you have to have set S, if A and B are dependent on the "instance" and not the "problem class".

Consider parameters as dictionaries/associative arrays with the value type of an enum. You have to provide the domain (enum) as well, you cannot do that dynamically in runtime.

However, there are "two stages" of this compile time: model declaration and user input (data). In your case, p1 and p2 are part of the former, A and B are part of the latter. When you fix something for the whole problem class and name it, like p1 and p2 in your example, it is like named data member of a class type. Having different values for A and B in p is more like a "freely changeable" dictionary.

Maybe an important thought is that there is no .getKeys() you have to define the domain first and then use it for a parameter. It doesn't work the other way around. (I think, that theoretically it could, but afaik the language/compiler doesn't support that.)

I hope this helped, and sorry if I misunderstood you.

Regarding your example, another thought:

if p1 and p2 are fixed for all instances, this may be better:

set S;
param p1{S};
param p2{S};


And then the data section:

set S := A B;

param:
        p1      p2 :=
A       100     20
B       200     30
;

It may also help to clear your thoughts to separate the declarations in the model file, and the data section.

In the end: as it is with different programming paradigms, sometimes you cannot find an equivalent from previous experiences and have to look at things from a different perspective. And maybe after gaining some experience you will find connections, etc. I'm no expert in either of these two fields though.

All the best!

Mate





On 2023. 05. 28. 20:19, Andrew Makhorin wrote:
-------- Forwarded Message --------

*Date*: Sun, 28 May 2023 14:08:46 -0300
*Subject*: Re: [Fwd: Re: [Fwd: MathProg set vs param]]
*Cc*: help-glpk@gnu.org <mailto:help-glpk@gnu.org>, Andrew Makhorin <mao@gnu.org <mailto:Andrew%20Makhorin%20%3cmao@gnu.org%3e>>
*To*: Jeff Kantor <jeff@nd.edu <mailto:Jeff%20Kantor%20%3cjeff@nd.edu%3e>>
*From*: Code Raguet <ignacio.code@gmail.com <mailto:Code%20Raguet%20%3cignacio.code@gmail.com%3e>>
The ’set’ and ‘param’ statements need to be considered from the
perspective of a mathematical optimization model.

This may be the cause of my struggling. My lack of knowledge in LP isn't helping to link the proper domain abstractions.

For example, I need to work with some dataset as a matrix:

        *p1*    *p2*
*A*     100     20
*B*     200     30

        
        

I managed to encode this table as the following statements. This works but my rationale is that the whole table is my "parameter". I'd like to be able to solve the model with another dataset where the only things that would remain are column names (p1 and p2).
Everything else may change.
So, do I need the S set? why? Is it possible to do this with param p only?
I think that my /parameter/ is just p and not p _and_ s.

set S := A B;
param p :
            p1   p2    :=
        A   100  20
        B   200  30
        ;

Thank you very much for your help, time and kindness.
Ignacio.

On Sun, May 28, 2023 at 10:18 AM Andrew Makhorin <mao@gnu.org <mailto:mao@gnu.org>> wrote:
-------- Forwarded Message --------
From: Jeff Kantor <jeff@nd.edu <mailto:jeff@nd.edu>>
To: Andrew Makhorin <mao@gnu.org <mailto:mao@gnu.org>>
Cc: help-glpk@gnu.org <mailto:help-glpk@gnu.org>
Subject: Re: [Fwd: MathProg set vs param]
Date: Sat, 27 May 2023 20:00:37 -0500

> Hi Ignacio,
>
> The ’set’ and ‘param’ statements need to be considered from the
> perspective of a mathematical optimization model. A ’set’ refers to a
> mathematical set of objects that will index other components of the
> model, such as parameters, constraints, and decision variables. The
> elements of the set must be unique. They can be integers or strings.
> Identifying appropriate sets for a particular problem is often
> obvious, but other times worth some thought.
>
> Elements of a set index parameters and provide a symbolic reference to
> the numbers needed to specify expressions appearing in your model.
>
> Parameters and sets are very different things.
>
> Jeff
>
> > On May 27, 2023, at 7:17 PM, Andrew Makhorin <mao@gnu.org <mailto:mao@gnu.org>> wrote:
> >
> > -------- Forwarded Message --------
> > From: Code Raguet <ignacio.code@gmail.com <mailto:ignacio.code@gmail.com>>
> > To: help-glpk@gnu.org <mailto:help-glpk@gnu.org>
> > Subject: MathProg set vs param
> > Date: Sat, 27 May 2023 19:51:01 -0300
> >
> > > Hi, there!
> > > I'm new to MathProg (and LP) but I have several years as a
> > > software
> > > developer.
> > > I would like to understand the semantic differences between set
> > > and
> > > param.
> > > When reading the doc and looking at examples, I understand that
> > > the
> > > set statement is for sets, arrays, vectors, (n-tuples) and simple
> > > symbolic elements. On the other hand, param statement is for
> > > simple
> > > scalar values or values of a set (usually indexed).
> > >
> > > My issues are about the semantics and rationale behind these
> > > statements.
> > > Why are two different statements for doing quite similar (in my
> > > understanding) purpose?
> > > I mean, both declare data structures (and initialize in the data
> > > section).
> > > Aren't sets kind of a param after all?
> > >
> > > for ex.:
> > > Imagine declaring an array of simple elements:
> > > set S := {'A', 'B'};
> > > param P{i in {'A', 'B'}};
> > >
> > > How are these statements different?
> > >
> > >
> > > Thanks in advance,
> > > Ignacio.
>
>




reply via email to

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