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

From: Debabrata Mandal (mandaldebabrata123_at_[hidden])
Date: 2020-06-08 05:47:44

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, but at the same time
hashing the keys is not a bad idea. Although this will only be evident
through tests, we might want to look into the issue deeper.

And, what should we do about its multi-dimensional counterparts? I remember
your advice of making it work for the simpler cases first, but a quick
glance at OpenCV's SparseMat
<https://docs.opencv.org/master/dd/da9/classcv_1_1SparseMat.html> suggests
that we should support the higher dimension cases as well. This will
require the usage of a hash function to map the keys to the bins, which
might be difficult to incorporate later if we stick with the current
approach. Any suggestions?
Thanks.
Deb.