Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY

Subject: Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2018-09-24 14:20:22

> On 24. Sep 2018, at 13:24, <a.hagen-zanker_at_[hidden]> <a.hagen-zanker_at_[hidden]> wrote:
> 
>> shape() is more concise  than `size() + has_overflow() + has_underflow()`, and the doxy string explains what it returns. If you have a better name, let me know
> 
> I suppose total_size() or full_size() is more intuitive, but of course not so elegant to have both size() and total_size().

total_size() is less ambiguous than shape(), so I am half-convinced. I would like to have one-word method instead of two-word method.

> [...]
> 
>> Secondly, spellings mistakes are unlikely. When do you add histograms? When you have generated several histograms in parallel and then you want to add them all up. The individual histograms will be generated by the very same code, so no spelling mistakes.
> 
> No need to check for identical labels either then.

Even if you reject the second of my two arguments, the first one still stands, but I also don't agree with you here. What if you have two programs which generate histograms which differ only in labels and then write them to files. Then you have another program to add histograms from filenames that you provide on the cmd-line. Not an artificial scenario, but one that I encountered. Checking labels prevents the second program from accidentally adding logically-different kinds of histograms.

If you are worried about the run-time cost of comparing labels, it is negligible if your axes types have empty labels.

> [...]
> 
>> This is explained in detail in the guide. You are basically saying: why do I need to make a choice between std::array, std::vector, and std::tuple. They are all containers, how they work is an implementation detail. When you can use compile-time configured histograms, they are much better, but sometimes you can't. Therefore, the library also supports histograms which are configured at run-time. Under the hood, these two implementations are very different. For the most part, the difference is hidden from you. You just either use make_static_histogram or make_dynamic_histogram and that's it. I cannot hide the difference completely, so I need to inform the user about it.
> 
> I didn't object to make_static_histogram() / make_dynamic_histogram(), as you explain these reflect a choice the user has to make.
> 
> I did object to:
> 
> auto h =  histogram< vector<axis_any> > { move(my_axis _vector)};

Ok, very well. Perhaps then there should be a make_histogram(…) function that accepts any container of axis types and creates a static histogram if the argument allows it, and a dynamic histogram otherwise.