proposal: API-breaking renaming "cf_boot" -> "cf_resample"

[kostrzewa]

Something that has really irked me over the past couple of years is that fact that we abuse cf_boot (and others) to also deal with jackknife samples. I'm implementing another type of container object right now and cringe as I write the resampling mixin constructor... Maybe this is something for 4.0? If course it would break things pretty badly...

[kostrzewa]

In the same process it would be nice to move away from t and t0 for samples and central values...

[martin-ueding]

While this would be done, we should also move away from the “is” and rather go to “has”. So a resampled cf would have the original cf as a member, and not also have all the same fields. I feel that the mixins are just a way to label the current state, but it would be much better to have distinct objects with “has” instead of “is”.

[kostrzewa]

Yes, it's probably a good idea to move into that direction. I'm sure that there are some edge cases where it might hurt because dealing with the presence or lack of members can get annoying and verbose.

[martin-ueding]

I would really prefer a setup where the fields present in a class are fixed, such that there is no ambiguity.

[kostrzewa]

I would really prefer a setup where the fields present in a class are fixed, such that there is no ambiguity.

This, I think, is not really possible in practice as demonstrated for example by a bootstrapped observable for which only the central value and error (samples) exist, but no "original data" (in the sense of the observable evaluated at each molecular dynamics time index).

[kostrzewa]

And when I say "lack or presence", I agree of course that the fields should always exist, they may be NA however.

[urbach]

Something that has really irked me over the past couple of years is that fact that we abuse `cf_boot` (and others) to also deal with jackknife samples. I'm implementing another type of container object right now and cringe as I write the resampling mixin constructor... Maybe this is something for 4.0? If course it would break things pretty badly...

Apart from obvious consistency improvements, what would we gain?

[kostrzewa]

Apart from obvious consistency improvements, what would we gain?

consistency in such a basic element of the framework should be enough in my opinion

[urbach]

> Apart from obvious consistency improvements, what would we gain? consistency in such a basic element of the framework should be enough in my opinion

As usual, for me this is also a question of man-power available.

[martin-ueding]

I found the whole »boot means samples« just irritating, not more. One needs to tell everyone. The one angle where we gain something is when somebody writes a function, and hard-codes sd instead of using an error_fn instead. Then one of us might assume that the function is valid for jackknife as well and gets really strange results. I would imagine that people not necessarily do that in hadron itself (we do code review) but perhaps in an analysis. When jackknife is added later on, error estimates will be wrong. But this is easily checked by comparing the error estimates. Also they will be so small that they become incredible and likely one spots it.

That is the only angle that I can see it being problematic, otherwise it is just itchy on a consistency level.