Dominik StaĆczak Nice, that worked! Hope you don't mind, I didn't want to keep yet another chat client installed :)
Dominik StaĆczak Anyway, I have a question to you all wonderful folk. This line of arviz code plots a nice clean 2D KDE:arviz.plot_kde(trace['T_e'], trace['n_e'], contour=False)Dominik StaĆczak But trying to do the same thing with an InferenceData object created from this same trace and PyMC3 model like this:
arviz.plot_kde(data, var_names = ["T_e", "n_e"])results only in a ValueError: Inference Data object detected. Use plot_posterior instead of plot_kde.
Dominik StaĆczak However, trying the following:
arviz.plot_posterior(data, var_names=["T_e", "n_e"])results in only marginalized 1D KDEs. Is there any way to create a 2D KDE out of InferenceData?
Dominik StaĆczak * Nice, that works well! I'll send in a PR for the error message :)
Dominik StaĆczak Thanks!
@canyon289 Hi Ravin, sorry for the late response. I had not checked back on gitter for a while and then received an email from them today. I think that your suggestion of adding the code to Arviz makes the most sense. I am wondering what unit tests would make sense for this. The obvious one I can think of is constructing a deterministic dictionary of posterior samples, converting it to ArviZ and then checking if the samples are the same.
@canyon289 I have created a fork of ArviZ and added two modules: https://github.com/michaelnowotny/arviz/blob/master/arviz/data/io_pyjags.py and https://github.com/michaelnowotny/arviz/blob/master/arviz/tests/external_tests/test_data_pyjags.py.
Please let me know if the code is ok
I have added an example at the end of the inference data cookbook -> https://github.com/michaelnowotny/arviz/blob/master/doc/notebooks/InferenceDataCookbook.ipynb
I have addressed some of the pylint warnings in my pull request but don't know how to best resolve the issues surrounding pytest fixtures. Pylint complains that using a fixture in a test function is redefining a name from the outer scope (which it is). Can we safely ignore this or should we find a work-around?
I was wondering if you had any tests for NetCDF files in InferenceData format.
When you mean test do you mean unittest or test netcdf files?
if its test netcdf files theres a couple "precompiled" https://github.com/arviz-devs/arviz/blob/master/arviz/data/datasets.py#L50
the ones in that url for example
if its unittests its all in the test folder https://github.com/arviz-devs/arviz/tree/master/arviz/data
I'm taking a quick look to see how hard it would be to generate InferenceData NetCDF directly from CmdStan (C++). If it's possible, the next decision would be software design... whether it makes sense to implement directly in CmdStan or whether it makes sense to just write a general C++ library (that conceptually could be at the ArviZ level).
For precedent on an external library arviz.jl is an example of an "external" library that provides functionality in another language https://github.com/arviz-devs/ArviZ.jl
not exactly one of the two options, but from the two you mentioned it sounds like either will work. I'm curious to see which route ends up working better
I am looking for adding log_likelihood in InferenceData from TFP trace. After computing log_likelihood, I am confused whether to add it as a variable in
sample_stats or as a separate group. I see it can be possible in both ways. But I am wondering if adding it in a certain way affects underneath computations. Any help in this regard? Thanks
and @Sayam753 great to see you here :)
I observed this channel for a few days before asking, suspecting if the community has moved to a new place.
The cookbook has a good example of this
And in case it helped, it used to be stored in the
sample_stats group with the name log_likelihood, but this approach was not really compatible with multiple likelihood functions nor with custom model comparison tasks which is why this was moved to its own group
Therefore, everything still works with both options, but the
log_likelihood group is preferred and is the only option that supports multiple likelihoods (as seen in this example)