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 21:00:13

> On 24. Sep 2018, at 18:33, Mateusz Loskot via Boost <boost_at_[hidden]> wrote:
> 
> On Mon, 24 Sep 2018 at 16:19, Hans Dembinski via Boost
> <boost_at_[hidden]> wrote:
>>> 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.
> 
> I'm not great in naming things, but perhaps:
> 
> size()
> shape    -> capacity()  // as total size including optionally enabled space

I was also thinking of capacity(), but it may be raising the wrong association? In a sense, it fits: capacity() in a std::vector tells you how much memory for how many items has been actually allocated, while the number of items that you requested is size() items. But people should not think that the existence of capacity() implies that the axis can grow more bins beyond the initial configuration.

Wider feedback from the list on this would be very much appreciated.

> uoflow()    -> tails()

Currently, over/underflow is configured with the enum class uoflow_type, so it makes sense to call the accessor uoflow(). If this things is called tails(), then we should also have an enum class tails_type. I am not 100 % happy with "uoflow", but I am not sure if "tails" should replace it.