«

On 19 Jul 2006 08:49:35 -0700, declaimed the following
in comp.lang.python:

>
> I like your idea of using something like a setStreams method to
> establish the linking. The streams do reflect each other, although
> having many-to-one and vice versa will complicate that. I have not

Shouldn't be that difficult; store a list of the "many" end and
cycle through the list...

Silly example, but visualize a water tank feeding irrigation
fields...

tank => [north_pipe, east_pipe, south_pipe, west_pipe]
<= None

north_pipe => [north_north_40, north_east_40, north_south_40,
north_west_40]
<= [tank]

north_north_40 => None
<= [north_pipe]
--
Wulfraed Dennis Lee Bieber KD6MOG

HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: web-)
HTTP://www.bestiaria.com/

Iain King wrote in news:1153323649.171612.74510
@s13g2000cwa.googlegroups.com in comp.lang.python:

>
> daveho...@f2s.com wrote:

>> [...] I need to reference (link) each object to the objects
>> upstream and downstream of it, i.e.
>>
>> supply = supply()
>> compressor = compressor(downstream=combustor, upstream=supply)
>> combuster = combuster(downstream=turbine, upstream=compressor)
>> etc.
>>
>> the problem with this is that I reference 'combustor' before is it
>> created. [...]

>
> At the top of your code you could put:
>
> supply = None
> compressor = None
> combuster = None
> turbine = None

That doesn't help.

The variable names will be rebound when assigned to the result of
the contructor calls, but only after the previous binding (None) has
been passed to some other objects constructor.

IOW the second line of the OP's code would effectively be:

compressor = Compressor(downstream=None, upstream=supply)

Rob.
--
http://www.victim-prime.dsl.pipex.com/

a écrit :
>>Even if you need to do something during attachment of components it is
>>more Pythonic to use properties. So you will write a method in your
>>class name something like _set_up(self,upstream_obj) an _get_up(self).
>> And then at the end of your class put up=property(_get_up, _set_up).
>>You can still use the compr.up=... format.
>
>
> sorry, I don't quite follow. what are properties?
>
Computed attributes. cf
http://www.python.org/doc/2.2.3/what...00000000000000

wrote:
> I have a problem. I'm writing a simulation program with a number of
> mechanical components represented as objects. When I create instances
> of objects, I need to reference (link) each object to the objects
> upstream and downstream of it, i.e.
>
> supply = supply()
> compressor = compressor(downstream=combustor, upstream=supply)
> combuster = combuster(downstream=turbine, upstream=compressor)
> etc.
>
> the problem with this is that I reference 'combustor' before is it
> created. If I swap the 2nd and 3rd lines I get the same problem
> (compressor is referenced before creation).
>
>
> aargh!!! any ideas on getting around this?
>
> Dave
Hi Dave,
In Digital electronics we have what are called netlists, (and also
component lists)

We have component types (map them to component objects); named
instances of components (instances); then we have net types (you could
probably get away with one net type) which models connections between
ports on a component.


class Port:
def __init__(self, direction):
self.direction = direction
class Comp:
def __init__(self,compType,name):
self.upstream = Port("U")
self.downstream = Port("D")
self.name = name
self.compType = compType
class Link:
def __init__(self, name, *connections):
self.connections = connections
self.name = name

# Instantiate your components
supply1 = Comp("supply", "supply1")
supply2 = Comp("supply", "supply2")
compressor1 = Comp("compressor", "compressor1")

# Instantiate Links and link in ports of component intances
supply2comp = Link("supply2comp", supply1.downstream,
compressor1.upstream)
# ...

With a bit more effort you can create component and link factories
that will name instances with the variable they are assigned to
without having to put that information in twice.

- Paddy.

Steve Holden wrote:
> wrote:
> > I have a problem. I'm writing a simulation program with a number of
> > mechanical components represented as objects. When I create instances
> > of objects, I need to reference (link) each object to the objects
> > upstream and downstream of it, i.e.
> >
> > supply = supply()
> > compressor = compressor(downstream=combustor, upstream=supply)
> > combuster = combuster(downstream=turbine, upstream=compressor)
> > etc.
> >
> > the problem with this is that I reference 'combustor' before is it
> > created. If I swap the 2nd and 3rd lines I get the same problem
> > (compressor is referenced before creation).
> >
> >
> > aargh!!! any ideas on getting around this?
> >
> Yes. You are building a generic data structure, so you shouldn't really
> be trying to store individual objects in variables like that. You need a
> data structure that's appropriate to your problem.
>
> For example, you could consider storing them in a list, so you have
>
> components = [supply(), compressor(), combuster()]
>
> Then components[n] is upstream of components[n-1] and downstream of
> components[n+1].

Unfortunately, if he wanted to make the topology more complicated, for
instance having two components downstream, it would be much more
cumbersome to inherit the list object and implement this.

> In short, your thinking about data representation might need to become a
> little more sophisticated.

That sounds a little arrogant. sorry!

> regards
> Steve
> --
> Steve Holden +44 150 684 7255 +1 800 494 3119
> Holden Web LLC/Ltd http://www.holdenweb.com
> Skype: holdenweb http://holdenweb.blogspot.com
> Recent Ramblings http://del.icio.us/steve.holden

wrote:
> I have a problem. I'm writing a simulation program with a number of
> mechanical components represented as objects.

Have you looked at SimPy? This may simplify much of your data
structure anguish (probably only need forward refs, without the back
refs), plus it will do all the discrete event scheduling for you.

-- Paul

Dave,

Python properties allow you to get rid of methods like c.getAttr(),
c.setAttr(v), c.delAttr() and replace them with simple constructs like
c.attr, c.attr=v and del c.attr.

If you have been using Java or C++ you know that as soon as you code
your class you have to start filling in the get() set()
delete()/reset() methods for each attribute. Some IDE tools like
Netbeans will to it for you with code refactoring and such. But for 10
attributes you will end up having another 20 or so
accessors/setters/and erase methods.

In Python not too long ago they introduced properties. With properties
you just access you attributes as attributes c.attr and c.attr=value if
you don't need to do anything special during getting and setting. Then
you can safely publish your API for everyone to use. If one day you
find a off-by-1 bug and you need to change one of the attributes when
it is accessed or set, you use properties. You create a method like
_get_attr(self) or _set_attr(self,v) in your class and at the end of
the class definition you write:
attr=property(_get_attr, _set_attr). From then on, when someone
accesses the attribute of your class c.attr the function _get_attr()
will be automatically called, in there you can do whatever you need and
return the value.

Check out this page:
http://www.python.org/download/releases/2.2/descrintro/
Look further down in the page for "properties".

Also take a look at "Python Is Not Java" article, it was interesting
for me to read. Properties getters and setters are mentioned there too
under the "getter and setters are Evil!" section Here is the link:
http://dirtsimple.org/2004/12/python-is-not-java.html

Nick V.

wrote:
> > Even if you need to do something during attachment of components it is
> > more Pythonic to use properties. So you will write a method in your
> > class name something like _set_up(self,upstream_obj) an _get_up(self).
> > And then at the end of your class put up=property(_get_up, _set_up).
> > You can still use the compr.up=... format.
>
> sorry, I don't quite follow. what are properties?
>
> > Also, you might want to re-think your OO design. It seem that all of
> > your components do a lot of things in common already. For one they all
> > are connected to other components like themselves, they also propably
> > will have method to do some computing, perhaps send or receive stuff
> > from other components, or they all will implement somekind of an event
> > model. In that case you could create a generic component class and
> > sublass the specific implementations from it.
>
> yes, I already do this - I have a component class and then the other
> components inherit from it.
>
> Dave

wrote:
> Steve Holden wrote:
>
>> wrote:
>>
>>>I have a problem. I'm writing a simulation program with a number of
>>>mechanical components represented as objects. When I create instances
>>>of objects, I need to reference (link) each object to the objects
>>>upstream and downstream of it, i.e.
>>>
>>>supply = supply()
>>>compressor = compressor(downstream=combustor, upstream=supply)
>>>combuster = combuster(downstream=turbine, upstream=compressor)
>>>etc.
>>>
>>>the problem with this is that I reference 'combustor' before is it
>>>created. If I swap the 2nd and 3rd lines I get the same problem
>>>(compressor is referenced before creation).
>>>
>>>
>>>aargh!!! any ideas on getting around this?
>>>
>>
>>Yes. You are building a generic data structure, so you shouldn't really
>>be trying to store individual objects in variables like that. You need a
>>data structure that's appropriate to your problem.
>>
>>For example, you could consider storing them in a list, so you have
>>
>>components = [supply(), compressor(), combuster()]
>>
>>Then components[n] is upstream of components[n-1] and downstream of
>>components[n+1].
>
>
> Unfortunately, if he wanted to make the topology more complicated, for
> instance having two components downstream, it would be much more
> cumbersome to inherit the list object and implement this.
>
I quite agree. That was why I began with "for example".
>
>>In short, your thinking about data representation might need to become a
>>little more sophisticated.
>
>
> That sounds a little arrogant. sorry!
>
Hmm, maybe it does, in which case I apologise retrospectively. But all
the more appropriate suggestions have definitely been pointing that way.

Circuit design is a complex problem. I was merely trying to indicate
that the naive approach was unlikely to succeed. Sure enough, a few
posts later the OP admitted that there needed to be sub-chains for
sub-circuits, and so on.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

wrote:
> Iain, thanks - very helpful.
>
> Really I'm trying to write a simulation program that goes through a
> number of objects that are linked to one another and does calculations
> at each object. The calculations might be backwards or fowards (i.e.
> starting at the supply or demand ends of the system and then working
> through the objects). And also, I might have multiple objects linked to
> a single object (upstream or downstream) - e.g. compressor -- multiple
> combusters - turbine
>
> I like your idea of using something like a setStreams method to
> establish the linking. The streams do reflect each other, although
> having many-to-one and vice versa will complicate that. I have not
> quite got my head around having multiple links. In C++ I would be
> thinking about something like a linked-list but I'm not sure that's the
> right approach here.
>
> Dave

You don't need linked-lists : python has a list type built in.
Example:

class Component():

upstream = []
downstream = []

def addUpstream(self, c):
self.upstream.append(c)
if not self in c.downstream:
c.addDownstream(self)

def addDownstream(self, c):
self.downstream.append(c)
if not self in c.upstream:
c.addUpstream(self)

def remUpstream(self, c):
c.downstream.remove(self)
self.upstream.remove(c)

def remDownstream(self, c):
c.upstream.remove(self)
self.downstream.remove(c)

def cascadeDownTest(self):
print self
# this could run forever if you connect components in a circle:
for c in self.downstream:
c.cascadeDownTest()

Iain

Paddy,

thanks for your mail.

> In Digital electronics we have what are called netlists, (and also
> component lists)

yes, years back I did a 3rd year project on a 'logic simulator' which
used the kind of thing you are talking about. I think spice does as
well. Fortunately my problem is a little simpler, phew. [by the way, as
an aside, check out modelia/dymola for some really powerful simulation
stuff http://www.dynasim.se/ - it uses powerful symoblic algebra
algorithms to derive system equations and the solve them numerically]

> With a bit more effort you can create component and link factories
> that will name instances with the variable they are assigned to
> without having to put that information in twice.

sorry - could you explain a bit more? sounds interesting and also
brings me onto another question that has been bugging me, which is, if
I want to create components (as object instances) at run time (rather
than through a python code imported in), how do I do this? i.e. if I
hardcoded something like
turbine1 = turbine(...)
then python knows that turbine1 is a turbine. but if I had say some
kind of user interface and I want to create turbine1 (or suchlike) on
the fly, how do I actually do that? how do I create objects after run
time?

Dave