Re: [gsoc2020] Answer to histogram design questions from Slack

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-06-09 14:57:11

On Mon, 8 Jun 2020 at 07:48, Debabrata Mandal
<mandaldebabrata123_at_[hidden]> wrote:
>
> I have a few questions Pranam Lashkari,
>
> > *Answer to the post above* : I had mentioned unordered_map due to the
> > > reason it employs hashing which is similar to the way Boost.Histogram
> > maps
> > > keys to unique bins in a storage class. This will become particularly
> > > useful for signed images of any channel type. At the same time an
> > > unordered_map does not guarantee key value mapping to be present for
> > every
> > > pixel value in a given range. So a sequence container like array or
> > vector
> > > would be better in this case.
> > > The histogram class has a clear distinction from the kernel class, in the
> > > sense that the kernel needs a contiguous storage while the histogram does
> > > not.
> > >
> > Yes, in this case, it makes sense to use the unordered map and the problem
> > of not having all the key map value mapping can be solved with inheriting
> > and creating a new class from unordered_map and then overriding
> > `operator[]` and `at()` because all the non-existing keys would have
> > value zero and this may make things simpler. Correct me if I am missing
> >
>
> Do you mean we should fill in the non-existing keys also apart from the
> valid keys in the histogram? We could anyways do that on demand with the
> way you just mentioned by overriding the specific operators.
>
> Also, I am not sure of the performance implication of using an
> unordered_map against a random access container

At this point, I would not spend too much time on wondering about the
performance
of the container itself. If we have boost::gil::histogram, we can
switch the underlying
container in future, *after* we can observe/measure related bottlenecks.

> And, what should we do about its multi-dimensional counterparts?

For the N dimensional variant of boost::gil::histogram, why not the simplest
option: multiple underlying arrays based on std::vector?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net