The addressing transform

[bessiambre]

The addressing transform

[stuhlmueller]

This sounds right to me. Naming choices based on stack addresses is a substantial improvement over sequential naming, but there is no guarantee that it gives the best possible naming scheme.

In practice, it seems to do pretty well, and in cases with obvious misalignments (as in your tourist example), it is generally possible to rewrite the model in a way that results in more conservative proposals. Here, "conservative" means that the change to the random world caused by a proposal tends to result in a smaller change in posterior probability.

It could be interesting to think about more explicit ways to specify naming schemes. In that case, I'd start by collecting examples of models where naming based on stack addresses goes wrong and where the fix is nontrivial.

[ngoodman]

yep, good question and i agree with andreas.

if we had some meaty examples it would spur code changes.

there's an easy and obvious way -- allow users to specify (dynamically
constructed) names as strings at 'sample' statements -- but it's easy to
shoot yourself in the foot that way (using non-unique names)....

-N

On Wed, Nov 26, 2014 at 10:37 AM, Andreas Stuhlmüller <
[email protected]> wrote:

This sounds right to me. Naming choices based on stack addresses is a
substantial improvement over sequential naming, but there is no guarantee
that it gives the best possible naming scheme.

In practice, it seems to do pretty well, and in cases with obvious
misalignments (as in your tourist example), it is generally possible to
rewrite the model in a way that results in more conservative proposals.
Here, "conservative" means that the change to the random world caused by a
proposal tends to result in a smaller change in posterior probability.

It could be interesting to think about more explicit ways to specify
naming schemes. In that case, I'd start by collecting examples of models
where naming based on stack addresses goes wrong and where the fix is
nontrivial.

—
Reply to this email directly or view it on GitHub
#13 (comment).

[bessiambre]

Thank you both for the answers. I get lost in my thought experiments and a discussion helps clear things up a bit. I wonder what the general principle should be for the rules of naming. It seems to me that there may need to be a direct correspondence between the tags and specific instances or parts of instances of things being modelled.

This makes me uneasy as it seems to potentially make the programming language almost too dependant on real world things or modelizations of things and making it less mathematically pure.

But then again, a lot of programming languages implement polymorphism with subtyping or interfaces, which can be seen as crude models of things and often make the instance a basic language concept.

I suppose making the naming scheme relative to some kind of polymorphic instance would be akin to relying on heap address instead of stack address. A new name would be generated on instantiation and when tracing through method calls or functions that are somehow related to an object instance, you could then rely on the name of the instance along with the method name.

This half baked idea brings up all kinds of questions in my mind. Could we have a probabilistic version of polymorphism? Could instances probabilistically "implement" some methods and thus be seen as probabilistically implementing an interface or probabilistically be of a type or subtype? In a way, it seems to have intuitive appeal to how humans organize concepts and maybe even make more sense than overly strict class hierarchies found in nonprobabilistic languages.

I guess back to thinking :-)