Re: [boost] [histogram] should some_axis::size() return unsigned or int?

Subject: Re: [boost] [histogram] should some_axis::size() return unsigned or int?
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-11-30 07:51:32

> Conventionally your size_type should be the same type returned by 
> size() and used for indexing.  So I would expect that type to be int, 
> given the above.
>
> Having said that, you're already departing from standard container 
> conventions by having size() return a number that is *sometimes* 2 
> smaller than the "real" number of bins, which might frustrate generic 
> algorithms.
>
> Completely without tongue in cheek, I wonder if it might be better to 
> not provide a size() method at all (to avoid container implications 
> which you do not satisfy) and spell it as bin_count() or something 
> distinct instead.
>
>
> Another possibility that might sidestep all of this could be to remove 
> the underflow/overflow bins from the standard indexing and make them 
> only accessible through separate underflow_bin() methods (or similar) 
> instead.  But this might complicate other cases such as a 
> find_bin_for_value() that needs to return an underflow/overflow 
> (though that could be solved by returning a bin iterator, not an index). 

A high +1:

Having size() makes on expect that "for(i=0;i<size();i++) h[i]" iterates 
over everything which it seems it does not. Hence it should not be 
called `size()`

 > I think representing the underflow bin with -1 and the overflow bin 
with the value returned by size() is very intuitive and elegant.

IMO this is against expectation of every C++ programmer: Being able to 
index a container with -1 and size() so in every review of code using 
this it will come up at least as a raised eyebrow.
Other idea: If those bins are so special that they don't fit into the 
[0, size()) range, why not use a different function for getting them, 
which is not the index operator? high_bin()/low_bin() come to mind.

But WHY was this chosen? Wouldn't it be ok if 0 is the first bin which 
starts at -inf and size()-1 to be the last one spanning to inf? This 
would allow a histogram of size 1 which has a single bin holding all 
values. This makes me wonder to if you *always* want the +-inf bins or 
if there are reasonable use cases NOT wanting them and expect 
out-of-range values to be dropped.
Disclaimer: I'm not familiar with Boost.histogram and see this from a 
users perspective only.