Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at