design question: set_value() behavior

36 views
Skip to first unread message

Siirola, John D

unread,
Jan 14, 2020, 11:55:57 AM1/14/20
to pyomo-de...@googlegroups.com

All,

 

An interesting question came up while discussing implementation issues for Disjunct.set_value():

 

What is the “expected” behavior for the following:

 

model.v = Var([1,2,3])

model.x = Var([1,2,3], bounds=(0,1))

model.x[1].fix(5)

model.v[1] = modle.x[1]

 

Is it:

  1. model.v[1] is modle.x[1] == True

  2. model.v[1] is modle.x[1] == False
    value(model.v[1]) == value(modle.x[1]) == 5
    model.v[1].fixed == True
    model.v[1].lb == 0
    model.v[1].ub == 1

  3. model.v[1] is modle.x[1] == False
    value(model.v[1]) == value(modle.x[1]) == 5
    model.v[1].fixed == False
    model.v[1].lb == None
    model.v[1].ub == None

  4. A ValueError exception (because x is not in domain Reals)

  5. …something else

 

… the current implementation is (d), which I think is undesirable.  I believe that kernel implements (a) (but does that mean that the var exists in two containers?).  I am leaning toward (b), for two reasons:

 

  1. If m.x was not indexed, directly storing the scalar container in the IndexedVar container would foul up things that walk up the component hierarchy

  2. If a user had the following model:
    m = ConcreteModel()

m.x = Var([1,2])

m.c = Constraint(expr=m.x >= 0)

m.y = Var([1,2])

m.x[1] = m.y[1]

Then if we implemented (a), then the constraint “c” would reference a variable that was no longer attached to the model.

 

Thoughts?

 

John

William Hart

unread,
Jan 14, 2020, 12:05:31 PM1/14/20
to pyomo-de...@googlegroups.com
I like the current semantics. 

Setting a variable equal to another should not be allowed with the equal operator. This is would make an error that users and developers are likely to make.

If we want some sort of variable copy semantics then I think that should be an explicit function to clone the variable.

I'm not sure I agree with your defaults, so one feature of an explicit call is that I could configure the semantics 

Bill

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pyomo-developers/acdcbdda047c44838cbf2441c82f937d%40ES02AMSNLNT.srn.sandia.gov.

Bynum, Michael Lee

unread,
Jan 14, 2020, 12:11:04 PM1/14/20
to pyomo-de...@googlegroups.com
I personally prefer (d). If we need support for (b), then I think there are more clear ways to support it than __setitem__.

Michael

Siirola, John D

unread,
Jan 14, 2020, 12:41:17 PM1/14/20
to pyomo-de...@googlegroups.com

Excellent points!

 

__setattr__ is already mapped through to an explicit call to the set_value() method.  We could augment set_value()’s API with something like ‘copy_state’ that defaults to False.  That way,

 

                m.x[1] = m.y[1]

 

generates an exception (for Var), but the user could still do:

 

                m.x[1].set_value(m.y[1], copy_state=True)

 

…which makes it explicit what should be happening.  This seems much more clear.

 

john

 

From: 'Bynum, Michael Lee' via Pyomo Developers <pyomo-de...@googlegroups.com>
Sent: Tuesday, January 14, 2020 10:11 AM
To: pyomo-de...@googlegroups.com
Subject: Re: [EXTERNAL] Re: design question: set_value() behavior

 

I personally prefer (d). If we need support for (b), then I think there are more clear ways to support it than __setitem__.

 

Michael



On Jan 14, 2020, at 10:05 AM, William Hart <whar...@gmail.com> wrote:

 

I like the current semantics. 

 

Setting a variable equal to another should not be allowed with the equal operator. This is would make an error that users and developers are likely to make.

 

If we want some sort of variable copy semantics then I think that should be an explicit function to clone the variable.

 

I'm not sure I agree with your defaults, so one feature of an explicit call is that I could configure the semantics 

 

Bill

 

On Tue, Jan 14, 2020, 9:55 AM 'Siirola, John D' via Pyomo Developers <pyomo-de...@googlegroups.com> wrote:

All,

 

An interesting question came up while discussing implementation issues for Disjunct.set_value():

 

What is the “expected” behavior for the following:

 

model.v = Var([1,2,3])

model.x = Var([1,2,3], bounds=(0,1))

model.x[1].fix(5)

model.v[1] = modle.x[1]

 

Is it:

a.       model.v[1] is modle.x[1] == True

b.       model.v[1] is modle.x[1] == False


value(model.v[1]) == value(modle.x[1]) == 5
model.v[1].fixed == True
model.v[1].lb == 0
model.v[1].ub == 1

c.       model.v[1] is modle.x[1] == False


value(model.v[1]) == value(modle.x[1]) == 5
model.v[1].fixed == False
model.v[1].lb == None
model.v[1].ub == None

d.       A ValueError exception (because x is not in domain Reals)

e.       …something else

 

… the current implementation is (d), which I think is undesirable.  I believe that kernel implements (a) (but does that mean that the var exists in two containers?).  I am leaning toward (b), for two reasons:

 

1.       If m.x was not indexed, directly storing the scalar container in the IndexedVar container would foul up things that walk up the component hierarchy

2.       If a user had the following model:
m = ConcreteModel()

m.x = Var([1,2])

m.c = Constraint(expr=m.x >= 0)

m.y = Var([1,2])

m.x[1] = m.y[1]

Then if we implemented (a), then the constraint “c” would reference a variable that was no longer attached to the model.

 

Thoughts?

 

John

 

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pyomo-developers/acdcbdda047c44838cbf2441c82f937d%40ES02AMSNLNT.srn.sandia.gov.

 

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pyomo-developers/CANumbFgJR_2nq%2BDS_8Ke%2BStj_NQu8bkgHgJY88BXf6Tr5M-_rQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.

William Hart

unread,
Jan 14, 2020, 1:00:58 PM1/14/20
to pyomo-de...@googlegroups.com
I am advocating for a separate copy_state method, since copying state is a superset of the logic in set_value. And a separate function would avoid slowing down set_value with an option that is rarely used.

To view this discussion on the web visit https://groups.google.com/d/msgid/pyomo-developers/b76664b2aa194e76802ae0331fb81e93%40ES02AMSNLNT.srn.sandia.gov.

Bynum, Michael Lee

unread,
Jan 14, 2020, 1:03:03 PM1/14/20
to pyomo-de...@googlegroups.com
I would be happy either way (utilizing set_value or creating a separate method/function).

Michael

Nicholson, Bethany L.

unread,
Jan 14, 2020, 1:14:52 PM1/14/20
to pyomo-de...@googlegroups.com

I’m also in favor of (d) and having an explicit method for copying state from one object to another. I also resonate with Bill’s point about having a separate method from set_value. I think there is something to be said for having more streamlined methods for specific functionality instead of adding more options to existing functionality. I think it makes documentation/testing easier too.

 

Bethany

Laird, Carl Damon

unread,
Jan 14, 2020, 3:46:32 PM1/14/20
to pyomo-de...@googlegroups.com
I agree with Bethany.

On Jan 14, 2020, at 10:14 AM, 'Nicholson, Bethany L.' via Pyomo Developers <pyomo-de...@googlegroups.com> wrote:


Reply all
Reply to author
Forward
0 new messages