Open RossBoylan opened 2 years ago
John votes for treating each function type's parameters as separate (in conversation just now).
Seems reasonable to me as the number and type of the set of parameters for different functions can, in general, vary.
Sent from this stupid iPhone
On Jan 26, 2022, at 2:57 PM, RossBoylan @.***> wrote:
John votes for treating each function type's parameters as separate (in conversation just now).
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were assigned.
The functional priors share many common parameters, like
decay
andscale
, across many of the sub-types. Strictly speaking, they share the names of the parameters. Should we take those to be shared values across some or all of the priors, or should we treat each as independent? I believe the earlier code treated them as shared values.As a concrete example of why this might matter, suppose one changed from a prior with a Banded Inverse Power Decay to a Linear Decay in the GUI. Would it be more natural if those "common" parameters were copied between types, or should the values come from the previous values for that particular type (Linear Decay), if available, or the defaults for Linear Decay otherwise?
I'll note the current code provides default values for many of those parameters, and the defaults are the same regardless of the specific subtype within the functional priors. For example, the initialization of InversePowerDecay uses the same
scale
,scale_origin
, anddecay
default values as the other 2 functional priors.The Empirical prior also has
scale
andscale_origin
, but the default value ofscale
is 1.0 and its interpretation is probably quite different from the other cases (it is used to multiply the standard deviation of the prior).