Remove `psignifit(..., debug=True)`

[otizonaizit]

From an email by @pberkes:

Remove psignifit(..., debug=True) . Do we really need to delete the posterior information by default? The data occupies some space in memory and on disk, but users are likely to regret not having it as soon as they try doing a more advanced plot.
Specifically I would:

1. Remove the "debug" option, and make True the default
2. Store the posterior, prior, and bounds data in the Results object, not in a "debug" dictionary
3. Remove all the checks in the plot functions and other methods that look for the "debug" dictionary
4. Make sure that tests check that the serialization of the Result object works even with the additional data

[otizonaizit]

The thing is that if the posterior is included, the size of the Result objects changes from a couple of KB to several MB. With the basic example we use in the docs, the exact size is 5.0K for debug=False and 4.9M for debug=True (when exported with pickle).

In itself is not a problem, but the serialized result object without debug is readable by a human, the serialized result object with the debug dictionary is not readable, because the text file is more or less impossible to navigate: it crashed my vi session, for example ;-)

And note that the size I mention here is for the binary pickle protocol. If we consider a text representation in JSON the difference is going to be even bigger.

We need a solution so that the serialized result object is a readable text-file. This ensures that you can read by naked eye the parameters you used for a fit even in 10 years and do not depend on anything else. You won't care about the posterior in 10 years from now.

4. Make sure that tests check that the serialization of the Result object works even with the additional data

A full serialization is at the moment not possible because the result object with debug=True includes the priors as functions. Those are needed for the plots but are not serializable in any way. So we would still need some gimmicks for plotting.

All in all in my opinion the debug dictionary seems a good compromise. Re-doing the fit if you forgot to set debug=True is a matter of waiting another 20 seconds, but a non-readable serialized result object is a pain forever :-)

[otizonaizit]

From an email by @pberkes :

Several MB in 2025 is alright I think.
Of course, a large 5D matrix of floating points should not be stored in a JSON, but we could output a ZIP file containing the JSON and the posterior matrices as separate files.

For the prior we would need to understand what the intent is, but I'm sure they can be saved somehow.

If we agree about the intent, I'm sure we can come up with a practical technical solution.

[otizonaizit]

Well, of course several MB is OK. What I am saying is that a text file which is several MB is not useful for being read by naked eye, and that it is hard to work with.

Yes, we could store what is currently stored when debug=False in a JSON file and the stuff that is added when debug=True in a different file format, for example in NPY format with np.savez.

But serializing functions is not going to be easy. I don't know of a way of doing it in a portable way.