Consider renaming Deterministic to store_in_trace

[ricardoV94]

Description

Deterministic does not convey the meaning of what it does. It stores an arbitrary computation (including stochastic nodes) in the trace, between sampled points.

From experience with Discourse users (most recent example), I think Deterministic is a source of confusion. Some users feel they need it for everything that is not a pm.Distribution. This is

1. Not true,
2. A potential waste of computation and slowdown
3. Can make the model API seem quite "uglier/verbose" than it actually is.

We should keep the Deterministic as an alias for quite some time, but start using the new name in docs and examples.

Alternative names welcome

[cuchoi]

That makes a lot of sense to me... are there any other uses for pm.Deterministic? We could put a deprecation warning on pm.Deterministic, but that might be a bit noisy given its adoption level.

[ricardoV94]

Storing in trace and showing in graphviz are the only uses I can think of.

[fonnesbeck]

Perhaps something like store_values? If you are using VI, there will not be a trace per se, so may as well be agnostic there.

[ricardoV94]

Short would also be nice, maybe something like record?

[fonnesbeck]

Was also thinking about capitalization/camel case here. I assume we will also need to pass a name, so might be odd to have these using a lower case/underscore convention while everything else in the model is camel cased. The camel case convention sort of implies that it is a first-class variable in the model, which I like.

theta = store_values('theta', alpha + beta * X) or theta = record('theta', alpha + beta * X)

versus

theta = StoreValues('theta', alpha + beta * X) or theta = Record('theta', alpha + beta * X)

[fonnesbeck]

Alternative names:

• Memoize
• Track
• Register

feel free to add others if anyone has ideas.

[ricardoV94]

Not Register, because we "register" all variables. Others sound good.

Does github have polls?

[fonnesbeck]

Here's a quick poll. Use the associated emoji to vote.

• Memoize 🎉
• Track ❤️
• Store 🚀
• Record 😄
• none of the above 👎

[twiecki]

[fonnesbeck]

Its a virtual tie internally, so let's go with Record.

[twiecki]

Final results

[ricardoV94]

This user was getting OOM problems because of the behavior of Deterministic: #6852

OTOH calling something Deterministic sounds nice for targeting by the do and observe functionality that will soon move from pymc-experimental to pymc. That makes me a bit reluctant about the renaming

[twiecki]

I don't follow.

[ricardoV94]

with pm.Model() as m:
  ...
  x = pm.Deterministic("x”, ...)
  ...

new_m = observe(m, {x: data})

new_m = do(m, {x: intervention})

Is more intuitive when x was defined as a "Deterministic" vs as a "store_in_trace".

[ricardoV94]

https://discourse.pymc.io/t/out-of-memory-during-transforming-variables-step-using-numpyro-increasing-postprocessing-chunks-doesnt-seems-to-help-what-should-i-do/13061/5?u=ricardov94

[twiecki]

with pm.Model() as m:
  ...
  x = pm.Deterministic("x”, ...)
  ...

new_m = observe(m, {x: data})

new_m = do(m, {x: intervention})

Is more intuitive when x was defined as a "Deterministic" vs as a "store_in_trace".

I don't feel the same holds quite true for Record(). Another way would be NamedDeterministic()/NamedDet(), or StoredDeterministic()/StoredDet().

[trendelkampschroer]

Thanks for the great package and making it freely available. It's a pleasure learning Beyesian data analysis through the many great examples and pymcs modeling language.

In addition emphasising the potential caveats of using pm.Deterministic in the examples, e.g here would be helpful to new users.

Especially for hierarchical models, cf. here lead me to include "deterministics" into models and end up with unnecessarily large traces and compute times for e.g. arviz.summary(trace).

Also consider the usage of 'deterministics' here which might also be confusing - at least when starting with pymc.