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.
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 :-)
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by Boost-Gil-Owners