Reuse skeleton code in rprocess?

[dcnorris]

Since my rprocess() Csnippet includes some deterministic relations, I wonder if it would be possible to abstract these to a skeleton component that the rprocess could then reference explicitly or (ideally!) automagically. If pomp allows for this, would there be any continuous-time example code I could follow?

[kingaa]

An interesting question, @dcnorris! I had just been thinking along these lines myself. In particular, if one were to pass a 'pomp' object, with a defined skeleton component, say, as an extra argument to pomp() (or another pomp elementary function) one could call skeleton() within any basic model component via the userdata facility. However, this is not quite what you're asking: it seems you're seeking a way of referring to other components of the current 'pomp' object within its own basic components. In other words, an analogue of the C++ this pointer or python's self. I actually don't know if there is any such thing for S4 classes; a very brief web search reveals no leads (although I did see this with respect to S5 reference classes).

If you do discover a way to do this, please let me know!

As it stands, I think the best way to achieve your aim is to re-use code. If the code in question is not long, this may even be advantageous (since more transparent). If it is long, an alternative is to code the common routines in a library that is linked to the 'pomp' object codes and call them from each of the skeleton and rprocess components. Intermediate between these two would be to pass the common subroutines to pomp() using the globals argument. They would then be available to the C snippets for the other basic model components.

Finally, it is probably worth asking at this point whether this is really what you want, i.e., whether the deterministic skeleton components are exactly what you need for your stochastic rprocess component. If you don't mind, it might be instructive for the community were you to say a bit more about what you're trying to achieve and why.

[dcnorris]

This is an interesting take on my question, @kingaa! I hadn't appreciated that the userdata facility was so ambitious, and I'll speculate below on how it could provide one way to implement a suitable solution using globals.

What brought this issue to my attention was that I decided to try some trajectory matching with my model, and realized ('duh!') that a surprising amount of my model was already deterministic. It seems to me that, for a model that mixes deterministic with stochastic relations, the skeleton is the natural place for the deterministic parts. Perhaps some relations defined in the skeleton have stochastic generalizations one might implement in rprocess by simply overriding the skeleton. Although it is not syntactically declarative, pomp does seem to me to achieve a great deal of semantic declarativeness through its plug-and-play principle. An ability to express all intrinsically deterministic aspects of the model in a skeleton component (and to have this reused if not overridden within rprocess) would further accentuate this valuable aspect of pomp for me.

I suppose what I have in mind is something like a macro facility, such that you could write #include skeleton at the top of the rprocess. That naturally invites comparison with your globals feature. But the trouble would be that (as I understand it) the skeleton is defined as a vectorfield, whereas the appropriate lines of rprocess are defined using differentials.

I'm not at liberty to share the model now, but I do hope I'll be able to share my model with the community at some point. I can say, however, that it's a clinical pharmacology application where some of the compartmental relations are best kept deterministic, so that appropriate focus can be placed on the meaningful sources of stochasticity.

[kingaa]

It's an interesting idea. It does run slightly against the grain of the main ideas behind the organization of pomp. In particular, pomp conceives of a model as a collection of distinct probability distributions (the "basic model components"). The skeleton component is the odd man out in that one naturally thinks of a deterministic process as a degenerate distribution, so that it would be natural to dispense with skeleton altogether and allow for degenerate rprocess components. Indeed, this would be preferable from the point of view of the organizing principles of pomp. There are technical difficulties associated with this, in that computationally one has to treat a degenerate distribution differently. Your observation regarding vectorfields, etc., is an example.

It strikes me as less natural to divide up individual components into deterministic and stochastic parts. For example, such a decomposition is not unique. It is not clear to me either whether such a decomposition serves any theoretical purpose, or is a purely computational convenience.

As for the narrower issue of your specific model, I think you could write the deterministic portions common to the skeleton and the rprocess as a function (or even a snippet of code defined using a C macro) and include this in the globals. Then, as you envision, simply including a call to this function (or an #include of this macro) in the appropriate places in the skeleton and rprocess C snippets would achieve the desired effect. Let me know if this isn't sufficiently clear.

[dcnorris]

Many thanks, @kingaa; this helps me better appreciate pomp's design. With any deterministic part of a model being in some sense degenerate, this puts my intentions into a 'set of measure zero' with respect to pomp's intent. Closing as answered.

[dcnorris]

Answering per @kingaa's reply above:

It does run slightly against the grain of the main ideas behind the organization of pomp. In particular, pomp conceives of a model as a collection of distinct probability distributions (the "basic model components"). The skeleton component is the odd man out in that one naturally thinks of a deterministic process as a degenerate distribution, so that it would be natural to dispense with skeleton altogether and allow for degenerate rprocess components. Indeed, this would be preferable from the point of view of the organizing principles of pomp.