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 13:44:30

Am 30.11.18 um 13:27 schrieb Hans Dembinski:
> I can see that you did not read the rationale carefully yet.
I just did not understand everything ;)
> `i` is the index for the histogram here (!) not for the axis itself. The histogram is also not a container, but it acts more like one. It also has a size() method and the value really  includes all bins.
Ah ok. So the essence of your question was: What should the types be for 
histogram::size() and histogram::operator[]?
BTW: Where is an interface description of that histogram class? In the 
reference I only find a forward declaration and "unspecified type", so I 
don't know what members it has.

In this case I go with the "same-as-stdlib" approach:

- Types should be the same
- for(auto i = SizeType(0); i<h.size(); i++) h.at(i).doIt() should be 
possible and iterate over all bins

The 2nd point implies the *flow-bins should be at axis.size() and 
axis.size()+1

> Yes, but we are diverging from my original question now. Users are recommended to use the range adaptors and iterators provided by the library. For the adaptors and iterators, all cases can be gracefully implemented.
>
> But I know my potential users very well, they will also use integers as indices to loop over the histogram, because people in target community are often beginner programmers and using an integer index feels natural to them. The question is how to optimise the design for this use case and so that it does not clash with similar (mis)usage of STL containers.
See above. Especially for beginners it has to be consistent with other 
usage. for(int i=-1; i<=h.size(); i++) WILL confuse them.
If you are referring to conversion warnings: Same as with stdlib.
> No, not a good idea. If we do that, then toggling *-flow bins on/off changes your whole program as it is written up to now, it will do something completely different.
>
> A user should be able to code the analysis and then decide: "Ah crap, these extra bins cost too much memory and in my special case they are always empty anyway, because my values never go out of the range that I specified. So let's just turn them off". Doing that optimization should not change logic of the program you wrote so far.

True, ok thanks for the clarification. Then axis.size is what the user 
says and h.size()==axis.size||axis.size+2. Putting the *flow bins at the 
end allows iterating over axis.size OR h.size with the same code. You 
can even go from for(int i=0; i<axis.size(); i++) to iterating till 
h.size if you chose to include the extra bins in your iteration.

Regards, Alex