Changes for v1.0.0 after all these years

[Samreay]

@renecotyfanboy here are some ideas I have:

1. Obviously type hint everything
2. Have a single way to specify chain attributes. Right now there's both c.configure and c.add_chain. I'd like this to become a more explicit:

chain = Chain(df, **options)
consumer.add(chain)

So there's only one place to go to.

3. Swap from sphinx to material mkdocs

And a bunch of other smaller things.

What changes were you wanting to make to help with the integration into your tool?

[renecotyfanboy]

Hi !

What changes were you wanting to make to help with the integration into your tool?

My first concern was about the maintaining of ChainConsumer in the next years, so glad to see you back. Following your propositions, I deeply agree on a common interface create and use Chain objects. Without being specific to dataframe, I think a class with several constructors would be good depending on the use cases of the community, i.e.

chain_1 = Chain.from_pandas(df, **kwargs)
chain_2 = Chain.from_dict(dictionary, **kwargs)
chain_3 = Chain.from_arviz(inferenceData, **kwargs)
...

I planned to do this on my tool's side at first but since you're back it would be great to put this directly here

As I was mentioning in mails, the InferenceData standard is growing in Bayesian computing community, and arviz is really a great tool for diagnosing results, but unusable when it comes to publication, because oh God it is ugly. For my tool, I would have thought of a workflow ending with arviz diagnostics and then results exportation using ChainConsumer, both relying on InferenceData.

I would be glad to implement here and there some high-level methods to interface this, and in general to help on the maintaining of ChainConsumer following your vision.

[Samreay]

Ah, its difficult to code things up when its been actual years since I've used anything at all from this. But okay, I could use jax to provide a simple example for numpyro that anyone can use to extend to other formats, like the hdf5 format

[renecotyfanboy]

I can take care of this if you want, specify me what you have in mind, and I'll push in on a new branch with pleasure!
I edited the previous post with a no JAX solution too

[Samreay]

Oh sure thing. So what I was going to do was:

1. Add jax or whatever is needed using poetry as an --extra dependency
2. Create a translator package and put a from_jax.py file in it, which would have a single function and no global jax import
3. Do the normal try and import, raise an error if jax isnt installed
4. Create a thin classmethod like you have in your comment that simply calls the translator, gathers the dataframe and any other kwargs back (maybe some formats specify a chain name, or have a specific column they put the weights in), and then invokes chain with the combination of the translation package plus any other kwargs
5. Add a test or two using some dummy data

[snwnde]

Option One: Class methods to handle each type. Chain.from_arviz, Chain.from_numpro, etc

Benefits: Using class constructors is very common and easy to understand.
Downsides: Kwarg autocompletion is harder to infer due to the **kwarg unpack

For the record, the downsides are alleviated upon the adoption of PEP 692 and pylance already supports it.

[Samreay]

@snwnde Yeah thats a big step forward, I just dont want to have to redefine everything as a TypeDict. I raised a feature request over on the python typing repo to see if they'd be open to converting providing Unpack compatibility with a dataclass, or a way to easily go from dataclass to typeddict (without needing code to be run).

Feel free to comment and upvote it here: python/typing#1495

[Samreay]

Current changes are in #101

What a weekend its been

[Samreay]

@renecotyfanboy 1.0.0 going out now!

[renecotyfanboy]

It appears that the PlotConfig object is not documented, do you plan to make a specific section or just include it through its docstring ?

[Samreay]

Just forgot the line, should be out now