Context
In spectracles, parameters may be shared across parts of the model, despite the fact that Equinox models are trees, and trees may not share leaves. This is handled by tracking the Parameter objects provided by the user at initialisation time and then performing tree surgery on __call__ on the arrays that below to Parameter objects.
Conceptually this is confusing when actually it's more like a while branch is shared. For example, two emission lines might use the same GP field for their velocities. Under the hood, the Fourier coefficients and kernel parameters are shared while the actual GP class gets cloned. This is deliberate, and robust. It has the potential to be confusing though, since the user probably provided the same GP object when assembling the model.
spectracles also has nice utility to inspect the sharing structure with ShareModule.plot_model_graph. This displays a Directed Acyclic Graph (DAG) that illustrates spectracles's internal representation of the model as a tree, with links indicating the sharing structure enforced by tree surgery at call time. I recently added an optional argument sharing_level="parameter" or sharing_level="component". "parameter" is the previous and in some way more honest representation, where the sharing plotted is at the parameter level. sharing_level="component" on the other hand is intended for users, and it essentially factorises up the tree such that the illustrated sharing is at the branch level (i.e. two arrows to one GP, instead of two arrows to their parameters).
Issue
This implementation has the slight problem that the shared model component node actually has two names. Maybe they're the same by chance. Often they are not. Right now one is just picked. This can be very confusing to inspect for the user, and needs to be resolved in some way.
Solution
The most straightforward choice is to display both names. The node usually shows the name and the type. The type is the same by construction so that's easy.
Other choices might include making a second "ghost" node that just hosts one of the names and points to the other node. This option seems bad because it's even less honest about the underlying model structure, and adds more nodes to fit in the plot.
Context
In
spectracles, parameters may be shared across parts of the model, despite the fact that Equinox models are trees, and trees may not share leaves. This is handled by tracking theParameterobjects provided by the user at initialisation time and then performing tree surgery on__call__on the arrays that below toParameterobjects.Conceptually this is confusing when actually it's more like a while branch is shared. For example, two emission lines might use the same GP field for their velocities. Under the hood, the Fourier coefficients and kernel parameters are shared while the actual GP class gets cloned. This is deliberate, and robust. It has the potential to be confusing though, since the user probably provided the same GP object when assembling the model.
spectraclesalso has nice utility to inspect the sharing structure withShareModule.plot_model_graph. This displays a Directed Acyclic Graph (DAG) that illustratesspectracles's internal representation of the model as a tree, with links indicating the sharing structure enforced by tree surgery at call time. I recently added an optional argumentsharing_level="parameter"orsharing_level="component"."parameter"is the previous and in some way more honest representation, where the sharing plotted is at the parameter level.sharing_level="component"on the other hand is intended for users, and it essentially factorises up the tree such that the illustrated sharing is at the branch level (i.e. two arrows to one GP, instead of two arrows to their parameters).Issue
This implementation has the slight problem that the shared model component node actually has two names. Maybe they're the same by chance. Often they are not. Right now one is just picked. This can be very confusing to inspect for the user, and needs to be resolved in some way.
Solution
The most straightforward choice is to display both names. The node usually shows the name and the type. The type is the same by construction so that's easy.
Other choices might include making a second "ghost" node that just hosts one of the names and points to the other node. This option seems bad because it's even less honest about the underlying model structure, and adds more nodes to fit in the plot.