Boost logo

Boost :

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-05-13 14:47:59

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
knowing that in future it will have to be extended for

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:


that convinces me there is more stuff that we don't know
than stuff we do know, at the moment :-)

Best regards,

Mateusz Loskot,

Boost list run by Boost-Gil-Owners