Fix to colouring for missing plots

[williamjameshandley]

Description

This PR added a failing test that shows the issue noted in #19. It now fixes that test by reordering the 'blank plots' in MCMCSamples.plot

Fixes #19

Checklist:

• I have performed a self-review of my own code
• My code is PEP8 compliant (flake8 anesthetic tests)
• My code contains compliant docstrings (pydocstyle --convention=numpy anesthetic)
• New and existing unit tests pass locally with my changes (python -m pytest)
• I have added tests that prove my fix is effective or that my feature works

[lukashergt]

So far I was using plot_type (which is popped in samples.plot) to decide what kind of 1D plot I want. Now, providing the kwarg plot_type results in

TypeError: plot() got multiple values for keyword argument 'plot_type'

Code to reproduce:

pc = NestedSamples(root="./tests/example_data/pc")
pc.plot_1d(['x0', 'x1'], label="pc", plot_type='hist');

[williamjameshandley]

Ah, I had noticed that MCMCSamples.plot_1d was missing a 'types' argument, in analogy to MCMCSamples.plot_2d. In this PR I've made them more consistent in preparation for the finer-grained control suggested in #41 .

The fix is to pass types='hist' rather than plot_type='hist'. I acknowledge that this is technically a breaking change, although only to undocumented (and, tbh unknown on my part) functionality.

[williamjameshandley]

One of the things I'm considering is deprecating the cryptic types arguments, with the plan to replace them with subplot_types, which is more informative.

[lukashergt]

By the way, the error actually also happens in the 2D case:

pc = NestedSamples(root="./tests/example_data/pc")
fig, axes = pc.plot_2d(['x0', 'x1', 'x4', 'x5'], label="pc", plot_type='kde');

Might it be more consistent to allow plot_type as a kwarg for plot_2d that broadcasts the provided string to all subplots?

[lukashergt]

I'm not sure how to fix this, but having plot_type and types in parallel like this seems wrong to me. If types is the one intended to be passed to plot_1d then plot_type should not be a valid kwarg.

I acknowledge that this is technically a breaking change, although only to undocumented (and, tbh unknown on my part) functionality.

Not undocumented with #24. Actually, plot_type was one of my major motivations for suggesting #24.

In this PR I've made them more consistent in preparation for the finer-grained control suggested in #41 .

The thing is, plot_type and types don't quite have the same role, so I'm not sure whether this is really more consistent. The need for types arises because in the 2D case we distinguish between 3 different families of plots (diagonal, lower and upper) which all need a plot_type assignment. This is a 2D specific feature and, thus, types is unnecessary in the 1D case.

One of the things I'm considering is deprecating the cryptic types arguments, with the plan to replace them with subplot_types, which is more informative.

Replacing types with a more general subplot_types that determines e.g. which plot type for which parameter would be an option. At the same type plot_type could be replaced with e.g. default_plot_type that broadcasts the plot type across all subplots and subplot_types can then be used to pick and alter specific parameters.

[lukashergt]

In any case, might it be better to revert this specific change and address all this in a separate PR that targets #41 ?

[williamjameshandley]

Agreed, reverted in 61e3f6b