When to use a stack?

[Andrew]

Last night I was reading about implementing my own stack. The example
given pushes items on and off the stack at the start and end of each
procedure (ie. in a std module). What's not so clear is how this
would work with class objects. In this case do you have to push the
object on the stack at the start of every public procedure etc. in the
class and pop it off at the end? I can't see how else you can know
which object is active - or is this not normally a situation where a
stack is employed?

Thanks in advance,
Andrew

 

[Bob Kilmer]

Andrew,
I haven't done a lot of stack implementation, but my general understanding
is that one use of a stack is for storing procedure variables and memory
locations while processors call other procedures. All of the current
procedure variables get stuffed onto the stack to reserve their value, along
with the memory location to resume from, and the process continues execution
at the new memory location implied by the call. The new procedure may itself
call another procedure and store its info on the same stack, and so on.
Eventually the last procedure completes, returns control to the calling
procedure which pops its variables from the stack, eventually completes,
returns control, pops variables, etc. At least that is the myth I carry
around in my head. There are other uses for stacks, as in parsing streams of
input. I am sure you can find more academic explanations.

I can envision using a VB Collection for a stack, which, as a practical
matter, would store VB objects in an order that could be controlled with
indexes. I write a lot of business and engineering software and I do not
remember implementing something I would really call a stack. Linked lists,
b-trees, arrays, other data structures, some may have been used like a stack
on a small scale. A stack is a pretty low level data type not often
encountered as such in modern business programming where the goal often is
patching together encapsulated data types (objects), data streams and whole
applications using higher level languages.

My $0.02,
Bob

 

[Andrew]

Hi Bob,
Thanks a lot for your explaination.

I had thought maybe I could implement a stack to keep track of what
object was currently active but from what you describe using a stack
is more suited to procedures and even then of limited use since vba
will return automatically to the previous procedure once finished.

Is there any other way to identify the active object? In fact what I
really want is the object prior to the active one. Kind of like
Application.Caller but applicable to objects.

In any case, thanks for your thoughts on stacks - it sheds some light
on how a programming language may be working beneath the surface -
interesting.

Rgds,
Andrew

 

[Tom Ogilvy]

selection will identify what is selected.

Perhaps if you said what you are really trying to do, someone could make a
suggestion. (as opposed to asking questions specific to how to implement
aspects of your creative solution which may not be the best way to attack
the problem). Also, since you are posting in comp.lang.visual.basic
perhaps if you mentioned where the code will be running - in excel or from a
vb app manipulating Excel with with automation or something else altogether.

 

[Dana DeLouis]

If you would like to see an "Out of stack space" message in vba, here is one
way: In Excel XP, my limit is about 6,285. I think this limit was
increased from about 2,000+ in previous versions.

Option Explicit

Public n As Long

Sub Repeat()
On Error Resume Next
n = n + 1
Debug.Print n
Call Repeat
If Err.Number <> 0 Then
Debug.Print Err.Description
Stop
End If
End Sub

Dana DeLouis

 

[Andrew]

To clarify...
First up - I am working with vba running in xl.

I have been working my way through Ken Getz & Mike Gilbert's book, the
"VBA Dev's Handbk", over a period of time. Here I came across an
example of how to implement your own stack using two class objects.
So, from a learning point of view I am curious to know more about when
and for what you would use a stack. I can see (from the example) how
this could be used within standard modules although am not so sure why
you want to do that really. Bob's reply seems to indicate that as
well. In parallel, however, I am writing my own program - hopefully
applying some of what I learn along the way. My code is object based
so as part of my understanding of stacks I am curious as to whether a
custom stack can be used with class objects. As far as I can tell
this would be overly arduous.

Then comes my project specific question which I thought could be
solved by maintaining a stack - but you are right there may be a
completely different and more optimal solution out there.

Say I have 2 objects: cStream and cPipe. I create two instances of
cStream, Inlet and Outlet and one instance of cPipe, MyPipe. Pointers
to Inlet and Outlet are held by MyPipe. When the inlet stream is
passed a pressure value an event is raised which is picked up by
MyPipe. If MyPipe is able to calculate the pressure drop across it,
dP, then it should pass the downstream pressure to the outlet stream
(ie. Outlet.Pressure = Inlet.Pressure + Me.dP). Conversely, if outlet
pressure is set then inlet pressure should be calculated.

The trick is though, I need to also record where the outlet pressure
(or inlet pressure) came from because if Outlet.Pressure is calculated
but then someone tries to enter a value for it then I need to raise an
error. But I don't want to raise an error if inlet pressure is
changed and a new outlet pressure is calculated. This is where I
thought a stack could be of use.

Sincere apologies for kind of confusing two questions in one.

Thanks for your help,
Andrew

 

[Tom Ogilvy]

On pg 440 they tell you why you might want to use a stack. In your example,
I don't see any match to using a stack. Your explanation for an application
appears asynchronous - having no set pattern or sequence. A stack is used
when a sequential path is followed and then reversed. I would see a stack
storage paradigm being applicable to a search, such as a depth first search
where your confronted with multiple choices (as to path) along the way
[basically a tree structrue]. When you reach the bottom of one path, you
would walk backup to the next juncture. This would involve pushing and
popping information on the stack. You would always want the information for
the last node visited, which the stack provides. The stack is basically a
LIFO queue. Now if you were traversing some type of pipe network, then
perhaps a stack would be appropriate.

That said, you do say you want to know how the value was set. I think you
would have to have all your code that could set the value, update you stack.
Then your procedure could check the stack to see how the the variable was
set. However, if you don't need to move back "up" the stack, but only know
about the most recent setting, then a global variable, class attribute, or
similar should add all the functionality you need

Unfortunately, when you mention stack, most people immediately focus on the
calling stack which uses the stack storage paradigm. Thus Dana has shown
you how to overflow that stack.

 

[Steve Gerrard]

| To clarify...
| First up - I am working with vba running in xl.
| |
| Then comes my project specific question which I thought could be
| solved by maintaining a stack - but you are right there may be a
| completely different and more optimal solution out there.
|
| Say I have 2 objects: cStream and cPipe. I create two instances of
| cStream, Inlet and Outlet and one instance of cPipe, MyPipe. Pointers
| to Inlet and Outlet are held by MyPipe. When the inlet stream is
| passed a pressure value an event is raised which is picked up by
| MyPipe. If MyPipe is able to calculate the pressure drop across it,
| dP, then it should pass the downstream pressure to the outlet stream
| (ie. Outlet.Pressure = Inlet.Pressure + Me.dP). Conversely, if outlet
| pressure is set then inlet pressure should be calculated.
|
| The trick is though, I need to also record where the outlet pressure
| (or inlet pressure) came from because if Outlet.Pressure is calculated
| but then someone tries to enter a value for it then I need to raise an
| error. But I don't want to raise an error if inlet pressure is
| changed and a new outlet pressure is calculated. This is where I
| thought a stack could be of use.
|
| Sincere apologies for kind of confusing two questions in one.
|

I've been following this thread, waiting for something interesting to
pop up. Then you mentioned pipe pressures, a subject I mess with at
work, and my ears perked up.

On the stack question: an example of when you might need a stack would
be if you had a string of multiple pipe, and you had to work your way up
the chain to find a starting pressure, then work your way back down to
calc the pressure in each pipe, or something of that sort.

Not particularly likely, but possible for certain kinds of calculations.
You would push each pipe onto a stack, then go on to the next one, until
you were ready to turn around. Then you would pop each pipe off of the
stack, process it, and continue until the stack was empty again.

On the Inlet vs Outlet: you say that either the outlet or inlet pressure
can be specified, and the other is to be calculated. I think you are
saying that once one is specified, you then want to block users from
trying to specify the other. If you really want to do that, you could
use a flag of some sort inside of MyPipe to keep track of which one is
entered and which one is calculated.

My own view would be that if the user specifies the inlet pressure, you
calculate the outlet pressure. If they then try to specify the outlet
pressure, you happily calculate the new inlet pressure for them,
replacing what they entered. If users don't get that they can only
specify one, you add a checkbox or something so they have to indicate
which one they want to enter.

 

[Andrew]

Hi Tom,

Thanks again for the reply.
Your example of multiple choices - some sort of search tree - makes
more sense to me. The thing that I didn't quite get in the p440
example is that it talks about opening forms and then backing out of
them in the opposite order. When I've done this before I've just left
the calling form open and once the called form closes there you are
again. The same is true for procedures because once one is completed
you always return to the one that called it anyway. I guess if you
were dealing with a lot of forms maybe you would want to close the
calling form and then open it again upon exiting the called form to
save memory?

In terms of my specific problem it seemed more robust to keep the
tracking of value sources internal to the objects rather than creating
a public class attribute. I guess that still leaves the global
variable option...

Perhaps the most elegant solution would beublic Property Let Pressure(NewValue As Single, Optional Source As
Integer)
OR
Public Property Let Pressure(NewValue as CustomType)
Where CustomType is defined as:
MyValue As Single
Source As Integer

But I can't get either of these to work.

On the other hand, if I could access the vba internal stack that would
be even better but apparently that's not possible.

Thanks,
Andrew

On pg 440 they tell you why you might want to use a stack. In your example,
I don't see any match to using a stack. Your explanation for an application
appears asynchronous - having no set pattern or sequence. A stack is used
when a sequential path is followed and then reversed. I would see a stack
storage paradigm being applicable to a search, such as a depth first search
where your confronted with multiple choices (as to path) along the way
[basically a tree structrue]. When you reach the bottom of one path, you
would walk backup to the next juncture. This would involve pushing and
popping information on the stack. You would always want the information for
the last node visited, which the stack provides. The stack is basically a
LIFO queue. Now if you were traversing some type of pipe network, then
perhaps a stack would be appropriate.

That said, you do say you want to know how the value was set. I think you
would have to have all your code that could set the value, update you stack.
Then your procedure could check the stack to see how the the variable was
set. However, if you don't need to move back "up" the stack, but only know
about the most recent setting, then a global variable, class attribute, or
similar should add all the functionality you need

Unfortunately, when you mention stack, most people immediately focus on the
calling stack which uses the stack storage paradigm. Thus Dana has shown
you how to overflow that stack.

 

[Andrew]

Hi Steve,

Thanks for your thoughts.

On the stack question: an example of when you might need a stack would
be if you had a string of multiple pipe, and you had to work your way up
the chain to find a starting pressure, then work your way back down to
calc the pressure in each pipe, or something of that sort.

I think provided the pipes all had pointers to one another you
wouldn't need a stack but I guess if they didn't, or if they only had
pointers in one direction, then that would be essential.

On the Inlet vs Outlet: you say that either the outlet or inlet pressure
can be specified, and the other is to be calculated. I think you are
saying that once one is specified, you then want to block users from
trying to specify the other. If you really want to do that, you could
use a flag of some sort inside of MyPipe to keep track of which one is
entered and which one is calculated.

That's exactly what I want to do. The problem is that I'd like to set
that flag internally rather than having to go
Outlet.Pressure=10
Outlet.PressureSource = 1 (eg for calculated)
I wrote some other ideas on this in my reply to Tom.

In this case there is a bit of a risk that someone using my stream and
pipe objects to write their own code might overwrite the source value.
In any case there is no need for them to set a value so I would
rather them not have the option of doing so (less confusing).

My own view would be that if the user specifies the inlet pressure, you
calculate the outlet pressure. If they then try to specify the outlet
pressure, you happily calculate the new inlet pressure for them,
replacing what they entered. If users don't get that they can only
specify one, you add a checkbox or something so they have to indicate
which one they want to enter.

I think this would be okay for a simple stream-pipe-stream set up on a
userform. But I want to be able to link an number of objects
together, for example: stream-pipe-stream-pump-stream-pipe-stream.
As the cases get more complicated there is a higher chance of
inadvertently overspecifying the problem and the pressure value that
would preside would just be the last one to be set - could get a bit
nasty to untangle.

 

[Tushar Mehta]

Specific to your problem...

How have you implemented the In/Outlet and the Pipe entities? Are
Inlet and Outlet members of the same class? I assume Pipe is a
separate class. Would that be correct?

Suppose the In/Outlets are members of the class InOutLet. Then, that
class module might contain something like:

Option Explicit

Dim PressureBasedOn As Integer, dPressure As Double
Const cPressureSpecified As Integer = 1, _
cPressureCalculated As Integer = 2, _
cPressureUnknown As Integer = 0

Property Get Pressure() As Double: Pressure = dPressure: End Property
Property Let Pressure(ByVal uPressure As Double)
Select Case PressureBasedOn
Case cPressureUnknown:
dPressure = uPressure
PressureBasedOn = cPressureSpecified
Case cPressureSpecified: dPressure = uPressure
Case cPressureCalculated:
'Set error condition vis-a-vis specifying a calculated value
MsgBox "Cannot specify a calculated value!"
Case Else:
'System integrity error; PressureBasedOn has unexpected value!
End Select
End Property

Public Sub calculatePressure(ByVal StartPressure As Double, _
ByVal PressureDrop As Double)
Select Case PressureBasedOn
Case cPressureUnknown:
dPressure = StartPressure + PressureDrop
PressureBasedOn = cPressureCalculated
Case cPressureSpecified:
'Set error condition vis-a-vis calculating a specified value
MsgBox "Cannot calculate a specified value"
Case cPressureCalculated:
dPressure = StartPressure + PressureDrop
Case Else:
'System integrity error; PressureBasedOn has unexpected value!
End Select
End Sub

For test purposes, use something like:

Option Explicit

Sub testIt()
Dim x As New InOutLet
x.Pressure = 10
x.calculatePressure 10, 1
MsgBox x.Pressure
Set x = New InOutLet
x.calculatePressure 10, 1
x.Pressure = 10
MsgBox x.Pressure
End Sub


--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

 

[Tushar Mehta]

You are correct in the sense that a stack is used to keep track of the
state of the current 'object' though, actually it is more than an
object. One of its uses is to keep track of the current state of the
system, which may be a single variable or a single object, but can be
as many variables as are necessary to define the current system state.
Basically, a stack is a data structure concept that doesn't restrict
the kind of information in it.

It's very useful in systems programming since one needs a snapshot of
the certain system information (return memory address for example) and
the values of the arguments to a called procedure just before actually
calling it. So, one gathers up all that information, pushes it into a
stack, and calls the routine.

The use of a stack in 'day to day' programming is limited since in most
cases it is easier to use a recursively coded routine. That
effectively shifts the responsibility of managing the stack passes to
the language/compiler. This is especially true when dealing with cases
where the push/pop stack operations occur with some sense of
predictability.

That leaves the stack as a very useful data structure for
'unpredictable' instances where one needs to preserve system state.
And, in the age of event-driven programming, there are opportunities
galore. [And, when one thinks about it, calling a procedure is an
'unpredictable' event.]

One recent instance where a stack was the appropriate data structure
that comes to mind was when I was developing a PowerPoint based add-in
for a client. The add-in would monitor a slide show timing on a slide-
by-slide basis. Part of the requirement was that a slide show could
have one or more slides from which the presenter could branch to a 2nd
show. When that show ended, the presentation would resume from the
slide in the 1st show.

While the client did not expect to ever nest more than one show deep,
the correct data structure for this problem was a stack. And, that
meant I could implement n-deep nesting at no extra cost to me. So,
that's what I did. Every time a 'SlideShowBegin' event happened, my
code took all the variables that defined the system state and stuffed
them into a stack. When a 'SlideShowEnd' event occured, I saved the
information for the current slideshow in a file, and popped the stack.

--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

 

[Steve Gerrard]

(comments in line)

| Hi Steve,
|
| Thanks for your thoughts.
|
| I think provided the pipes all had pointers to one another you
| wouldn't need a stack but I guess if they didn't, or if they only had
| pointers in one direction, then that would be essential.
|

I agree you usually wouldn't need one.Use of stacks in programming with
objects is generally fairly limited. Tushar had one good example in one
of his posts, with nested slide shows.

| That's exactly what I want to do. The problem is that I'd like to set
| that flag internally rather than having to go
| Outlet.Pressure=10
| Outlet.PressureSource = 1 (eg for calculated)
| I wrote some other ideas on this in my reply to Tom.
|

Assuming that MyPipe knows its inlet from its outlet, I would have kept
the flag inside of MyPipe, with a private variable mCalcedEnd:
Outlet.Pressure = 10
mCalcedEnd = 2 'outlet is calced
or, if the inlet gets calced,
Inlet.Pressure = 10
mCalcedEnd = 1 'inlet is calced

| In this case there is a bit of a risk that someone using my stream and
| pipe objects to write their own code might overwrite the source value.
| In any case there is no need for them to set a value so I would
| rather them not have the option of doing so (less confusing).
|

The situation to anticipate is that the user changes their mind. They
might enter an inlet pressure, look at the result, and realize that they
want to enter the outlet pressure instead.

| I think this would be okay for a simple stream-pipe-stream set up on a
| userform. But I want to be able to link an number of objects
| together, for example: stream-pipe-stream-pump-stream-pipe-stream.
| As the cases get more complicated there is a higher chance of
| inadvertently overspecifying the problem and the pressure value that
| would preside would just be the last one to be set - could get a bit
| nasty to untangle.

Yes, it does get a bit more complicated. I have dealt with a similar
task involving calculations with survey points. Depending on which
things are entered by the user, it has to calculate stations,
coordinates, elevations, and angles at every point.

I think there are two key things to making this work on a robust level
that can handle a wide variety of situations.

1. The individual objects (stream, pipe, pump, etc), should have two
sets of properties: the EnteredValues, and the CalcuatedValues. So for
instance you would have both EnteredPressure and CalculatedPressure for
each object. Each object keeps track of whether or not it has an entered
pressure.

2. Perform the calculations at the collection or list level, not within
any of the individual objects. So instead of MyPipe responding to a
change in its inlet pressure, the PipeLineList object responds to a
change, and recalculates the whole line, or the affect portion.

During the re-calculation, the user-entered values are simply copied to
the calculated values of the objects, unless they are in conflict with
other entries. The result is that the calculated values for all objects
show the final result for the whole line.

 

[Andrew]

Steve, Tushar,

Thanks alot for the time and effort you've put into your responses. I
have mucked around with the 'Property Let' statement some more and
finally figured out how optional parameters work, ie.

Public Property Let Pressure(Optional Source as Integer = 1, Value As
single)

This is quite nice because most people typing "Stream.Pressure = 100"
from a std module will likely not even notice the optional "Source"
parameter. If they do then I will enumerate the constants (+ provide
help) so that shouldn't provide too much confusion. However, when
setting pressure from some other object I can pass source and store it
in the receiving object (after checking for inconsistencies). This
will avoid having to keep track of the active object external to the
objects themselves.

In case you're interested my code will look something like:
Private With Events p_objStrmIn As clsStream
Private With Events p_objStrmOut As clsStream

Private Sub objStrmIn_PressureChange()
' try to calculate dP - If successful (ie. all other rqd values
available)...
p_objStrmOut.Pressure(Source:=2) = p_objStrmIn.Pressure + dP
' will need some additional checking since this will trigger the
outlet stream
' event
' objStrmOut will raise an error if there is a conflict in source
End Sub
Private Sub objStrmOut_PressureChange()
' As per above but calculate StrmIn pressure
End Sub
Public Property Let Pressure(Optional Source as Integer = 1, Value As
single)
' Check for inconsistencies
' Store the value & source where default source (=1) is user input
RaiseEvent PressureChange
End Property

This avoids needing the CalculatePressure sub. Pressure is returned
via the same attribute whether calculated or input.

Thanks for all the input and thanks for the powerpoint example of
stacks - can relate to that one.

Andrew

 

[Tushar Mehta]

Hi Andrew,

If you are comfortable with the solution, go with it. Not many people
leverage that particular capability of a property. It sure can be a
powerful tool.

In this instance, I rejected that approach because it seemed to make
more sense to move the calculation of the pressure into the class
module rather than have each client duplicate that work. However, you
know your application better than I do and if it makes sense to you...

--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

 

[Andrew]

Hi again Tushar,

If you are comfortable with the solution, go with it. Not many people
leverage that particular capability of a property. It sure can be a
powerful tool.

I just realised that this is more of a "hack" than I thought at first.
When I create my 'Property Get Pressure()' it also needs to contain
the same optional parameter as the Prop Let otherwise I get a comiler
error (makes sense I guess). So it seems the "other" parameters in a
Prop Let/Get are anticipated to be more to do with defining the state
of the main variable that is passed rather than being attributes in
their own right.

I had envisaged:
objStream.Pressure(Source:=cUP_STRM_OBJ) = 100

whereas infact the following would make more sense:
objStream.Pressure(ValueType:=cSOURCE) = cUP_STRM_OBJ
objStream.Pressure(ValueType:=cVALUE) = 100

This of course is not what I want though so I think I will stick with
the first (kind of "incorrect") line and then just ignore the Source
parameter in the Prop Get:
Property Get Pressure(Source as Integer) As Single
Pressure = x 'regardless of any source value passed
End

A little bit messy but no solution seems quite perfect to this
problem.

In this instance, I rejected that approach because it seemed to make
more sense to move the calculation of the pressure into the class
module rather than have each client duplicate that work. However, you
know your application better than I do and if it makes sense to you...

The pressure drop calculation certainly belongs in the pipe and not
the stream. Whether you use this to set the stream pressure in the
stream or from the pipe is up for choice. I don't like the public sub
CalculatePressure because I think for a user it becomes unclear since
this is not a function that they would need to call. But, thinking
along similar lines I did consider raising a dP_Change event.
Trapping this in the stream is more or less the same as your
CalculatePressure sub. What's not so neat is that then to actually
determine the stream pressure it has to go back through the pipe to
get the pressure of the stream further upstream of the pipe. Plus
StreamIn would also catch the event* - can be handled but... Seemed a
bit inefficient.

So then I started wondering about stacks - but you already know that
part

* since streamIn can be streamOut of some other pipe even further
upstream.

Best regards,
Andrew