Changeset 3251


Ignore:
Timestamp:
Nov 17, 2010 11:53:47 PM (10 years ago)
Author:
wehart
Message:

Reformating.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • ceps/cep-0004.txt

    r3250 r3251  
    4040    instance1 = model1.create()
    4141
    42 In this instance, the objective is 'x' rather than '-x', which would be correct given that
    43 p is negative.  The problem is that 'model.p > 0' generates an expression, rather than evaluating
    44 p and then doing the comparison.  The following concrete model has the expected semantics:
     42In this instance, the objective is 'x' rather than '-x', which would
     43be correct given that p is negative.  The problem is that 'model.p >
     440' generates an expression, rather than evaluating p and then doing
     45the comparison.  The following concrete model has the expected semantics:
    4546
    4647::
     
    7172Of course, this relates to the deeper issues that relate to the motivation
    7273for parameter objects.  These are really best motivated in abstract
    73 models, where the parameter values are loaded after the model is setup. 
     74models, where the parameter values are loaded after the model is setup.
    7475
    7576Regardless, Pyomo needs a simpler strategy for representing parameter
     
    101102Our first design allows parameters to be replaced with float or dict
    102103values.  The associated components are segregated into an attribute of
    103 the model, which allows users to directly interact with these objects after a
    104 model instance is created.
     104the model, which allows users to directly interact with these objects
     105after a model instance is created.
    105106
    106107Here's an example with a ConcreteModel:
     
    139140parameters q and s continue to be Param objects.
    140141
    141 I believe that this design can be implemented such that the data used in immutable parameters is shared, thereby avoiding a significant memory penalty for this design.
    142 
    143 Unfortunately, this design is not backwards compatible.  Thus, a user who has leveraged the API of Param objects may need to rewrite code to reference the components attribute of the instance.
     142I believe that this design can be implemented such that the data used
     143in immutable parameters is shared, thereby avoiding a significant memory
     144penalty for this design.
     145
     146Unfortunately, this design is not backwards compatible.  Thus, a user
     147who has leveraged the API of Param objects may need to rewrite code to
     148reference the components attribute of the instance.
    144149
    145150
     
    147152-------------------------
    148153
    149 Our second design segregates parameters to be expressed in a ''data'' attribute of the model.
    150 
    151 Here's an example with a ConcreteModel:
     154Our second design segregates parameters to be expressed in a ''data''
     155attribute of the model.  Here's an example with a ConcreteModel:
    152156
    153157::
     
    195199===============
    196200
    197 While considering the generation of data for immutable parameters,
    198 it seems natural to do the same for set data.  This would have the
    199 advantage of presenting set data to the user in a native Python format,
    200 for which complex manipulations can be performed.  Consider the following example, which generalizes the example in Design1:
     201While considering the generation of data for immutable parameters, it
     202seems natural to do the same for set data.  This would have the advantage
     203of presenting set data to the user in a native Python format, for which
     204complex manipulations can be performed.  Consider the following example,
     205which generalizes the example in Design1:
    201206
    202207::
     
    241246many ways, there are subtle differences that might confuse a user.
    242247
    243 However, there is a major memory issue lurking in this use of immutable set objects.  The set A is a Python set object.  When this is passed as an argument to the Param constructor, Pyomo creates a Set object to represent this indexing set, and then initializes it with the value of A.  Thus, the data in A is duplicated in the model!
    244 
    245 By contrast, when parameter s is constructed, set B is passed to the Param constructor.  Here, B is a Set object, which does not need to be duplicated.
    246 
    247 Thus, this design both eliminates a source of subtle bugs and introduces another.  Note, however,
    248 that since the model is concrete, the components are being generated as they are declared.  Consequently, the following declaration for parameter r would avoid this performance issue:
     248However, there is a major memory issue lurking in this use of immutable
     249set objects.  The set A is a Python set object.  When this is passed
     250as an argument to the Param constructor, Pyomo creates a Set object to
     251represent this indexing set, and then initializes it with the value of A.
     252Thus, the data in A is duplicated in the model!
     253
     254By contrast, when parameter s is constructed, set B is passed to the
     255Param constructor.  Here, B is a Set object, which does not need to
     256be duplicated.
     257
     258Thus, this design both eliminates a source of subtle bugs and introduces
     259another.  Note, however, that since the model is concrete, the components
     260are being generated as they are declared.  Consequently, the following
     261declaration for parameter r would avoid this performance issue:
    249262
    250263::
     
    252265    model4a.r = Param(model4a.components.A, initialize={0:0, 1:1})
    253266
    254 Note that this memory issue with immutable sets only arises in concrete models.  In abstract models,
    255 the set object construction is delayed, which allows the parameter
    256 objects to be defined with Set objects.  (I could provide an example here,
    257 but it wouldn't convey the dynamic nature of what is happening...)
     267Note that this memory issue with immutable sets only arises in concrete
     268models.  In abstract models, the set object construction is delayed,
     269which allows the parameter objects to be defined with Set objects.
     270(I could provide an example here, but it wouldn't convey the dynamic
     271nature of what is happening...)
    258272
    259273
Note: See TracChangeset for help on using the changeset viewer.