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

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-05-13 19:02:32

On Wed, 13 May 2020, 20:07 Debabrata Mandal, <mandaldebabrata123_at_[hidden]>
wrote:

> On Wed, May 13, 2020 at 11:09 PM Mateusz Loskot <mateusz_at_[hidden]>
> wrote:
>
> > On Wed, 13 May 2020 at 18:12, Debabrata Mandal
> > <mandaldebabrata123_at_[hidden]> wrote:
> > >
> > Yes, as what Pranam suggested and I agreed to as well,
> > a single channel does sound reasonable to start with and focus on.
>
>
> Great, so should I start thinking of possible user invocation syntax for
> the histogram calculation and related algorithms and share them in an
> upcoming email?
>

Whenever you wish to request comments, you can post a new thread here or
ask on Slack (if questions are not too elaborate) or open a GitHub PR, if
you want to show any code for review.
I mean, just as suggested in the initial welcome email.

> Yes, as image and operation complexity increases, we may need to narrow
> > histogram container choices.
> >
>
> So for now can we assume support only for STL containers (not nested) and
> Boost.Histogram?
>

Works for me.

> I did not suggest anything other than what has been proposed:
> > - generic 1D, 2D, 3D histogram functions
> > - 1D, 2D cumulative histogram function
> > In fact, I assumed we may only be able to provide calculations of
> > 2-3 D histograms during this project, nothing else.
> >
> >
> The original project page in Github had suggested some algorithms like
> adaptive histogram equalisation, so I had decided to add some more powerful
> and better algorithms to my project proposal to cover the span of 3 months.
> I had not anticipated the immense number of choices that one had to choose
> from while selecting what is best for everyone. I had approximated it as
> making some simple type checks and providing specialisations, which does
> seem absurd now. So, I think I will need to review my work plan and reorder
> things a bit.

Sure, I don't object adjustments to the initial plan.

Should I post the list here that I had proposed initially so
> that we can vote on what to keep and what to eliminate for now.
>

I think it isn't necessary.

We have the list of proposed features
You likely have items that you're certain about, that you want to do for
sure, for those items you can open feature issues on GitHub (as suggested
in welcome email).
Such issues can make up a nice TODO list, then items are ticked via PRs.
For others, we decide and pick as we go, and we can add them to the TODOs.

Mateusz Loskot, mateusz_at_[hidden]
(Sent from mobile, may suffer from top-posting)

>