You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should keep an eye on DataTree and see what can be upstreamed, but I think we should have an azbase accessor defined here where we reimplement some of the methods of InferenceData so they behave in the most similar way possible. For example, I use .map a lot. I basically use it for any operation that needs to be done on multiple groups at once. The closest thing to InferenceData.map would be DataTree.map_over_subtree which clearly does not fit the bill because 1) it has no way of indicating in the function call to which subset of groups the function should be applied to 2) the signature of the function has to be func(node.dataset, *args, **kwargs) -> Datasetand datasets don't have a name attribute so the function can't decide to return the node as is or transform it based on the name.
There are also other methods that differ from general xarray behaviour such as extend or add_groups but that are quite common in use, so having them mimicked via DataTree.azbase.extend or things like this would be nice and would help make the transition easier.
Why azbase or arviz? So far, the idea is to have the splitted pacakges be mostly independent. Thus it should be possible to use them on their own (that is, installing arviz-base but no arviz-stats nor arviz-plotting). However, while we want this to be possible, I don't expect that to be the most common case, so we should also expose a full-fledged arviz. If we use azbase and azstats for the accessors in the splitted packages, the arviz package can then be a mostly metapackage that installs all 3 at the same time, exposes their functions via a common namespace arviz. and could also combine the azbase and azstats accessors into a single arviz accessor.
The text was updated successfully, but these errors were encountered:
We should keep an eye on DataTree and see what can be upstreamed, but I think we should have an
azbase
accessor defined here where we reimplement some of the methods ofInferenceData
so they behave in the most similar way possible. For example, I use.map
a lot. I basically use it for any operation that needs to be done on multiple groups at once. The closest thing toInferenceData.map
would beDataTree.map_over_subtree
which clearly does not fit the bill because 1) it has no way of indicating in the function call to which subset of groups the function should be applied to 2) the signature of the function has to befunc(node.dataset, *args, **kwargs) -> Dataset
and datasets don't have aname
attribute so the function can't decide to return the node as is or transform it based on the name.There are also other methods that differ from general xarray behaviour such as
extend
oradd_groups
but that are quite common in use, so having them mimicked viaDataTree.azbase.extend
or things like this would be nice and would help make the transition easier.Why
azbase
orarviz
? So far, the idea is to have the splitted pacakges be mostly independent. Thus it should be possible to use them on their own (that is, installing arviz-base but no arviz-stats nor arviz-plotting). However, while we want this to be possible, I don't expect that to be the most common case, so we should also expose a full-fledgedarviz
. If we useazbase
andazstats
for the accessors in the splitted packages, thearviz
package can then be a mostly metapackage that installs all 3 at the same time, exposes their functions via a common namespacearviz.
and could also combine theazbase
andazstats
accessors into a singlearviz
accessor.The text was updated successfully, but these errors were encountered: