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

From: Pranam Lashkari (plashkari628_at_[hidden])
Date: 2020-05-31 08:51:31

After going through the first PR for the histogram created by Debabrata
Mandal, I have a few suggestions

Looking at the current design in the PR, in my opinion, it is not going to
be maintainable when we'll have much code around it, second thing from the
user perspective I think this design is a bit confusing(at least I felt it).

According to me, we should have our own container for the histogram. This
does not have to be much complicated or advanced as we are going to use
standard containers. I think we can use an implementation like we have for
the kernel. This will also solve most of the problems mentioned in the PR
and we'll have less complex code to maintain with a simpler interface.

On Wed, May 13, 2020 at 8:16 PM Mateusz Loskot <mateusz_at_[hidden]> wrote:

> On Wed, 13 May 2020 at 14:55, Pranam Lashkari <plashkari628_at_[hidden]>
> wrote:
> > On Wed, May 13, 2020 at 6:13 PM Mateusz Loskot <mateusz_at_[hidden]>
> wrote:
> > >
> > > By asking some questions I did not suggest they should be answered now.
> > > I just hoped to direct the thinking/discussion towards quite obvious
> > > conclusion:
> > > - do not focus on unnecessary stuff (e.g. controlling details of of
> > > histogram)
> > > - focus on what we know to start prototyping/implementing early
> > > - start from easy to complex
> > >
> > > Obviously, solving a problem for a single channel is easier than
> > > solving it for multiple channels and dimensions.
> > >
> >
> > On the other hand, I forgot to mention things related to boost.histogram.
> > In my opinion, we should use it only if we are going to use it
> > permanently(not a lifetime but a long time, you know what I mean). It may
> > make our work a little simple for now, but if we are gonna remove it
> > eventually and we know it at the point then why to use it now? it just
> > increases the workload for the future.
>
> I don't see how making such shortcut for the time being may increase
> workload.
>
> It is not different to solving calculation problem for a function
> foo(std::vector<T>)
> knowing that in future it will have to be extended for
> foo(std::set<T>)
> foo(T*)
> etc.
>
> An output container does not really affect an algorithm, does it?
>
> Besides, I expect permanent integration with Boost.Histogram.
> It just will become optional, that is, if a user wants to enable it,
> she includes specific header, e.g.
> #include <boost/gil/extension/boost_histogram.hpp>
>
> However, I don't want to impose any approach, but if I see we are
> brainstorming all possibilities of parameters:
>
> imgHist(srcview,hist);
> imgHist(srcview,hist,channels,range,colormap,sparsefill,accumulate);
>
> that convinces me there is more stuff that we don't know
> than stuff we do know, at the moment :-)
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
> Boost-gil mailing list
> Boost-gil_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-gil
>

-- 
Thank you,
Pranam Lashkari