[SciPy-Dev] Boost for stats

[Tyler Reddy]

Probably good to make sure that aarch64 build times remain relatively
stable since I think we're already doing quite a few gymnastics on that
platform for wheel builds (and we're quite limited on iterations with
Travis CI resources there).

On Sat, 13 Feb 2021 at 12:32, Evgeni Burovski <evgeny.burovskiy at gmail.com>
wrote:

> Hi,
>
> Borrowing from Boost.Math sounds great indeed. (Great if it seems
> advantageous by boost devs, too).
> There is really no reason to keep using parts of e.g. cdflib which are
> superseded by Boost.Math.
>
> However, playing devil's advocate somewhat:
>
> - does the scipy PR need the whole Boost.Math? If it only needs a
> select subset (e.g., do we need root-finding etc?), then maybe the
> size can be reduced.
> - do we need the whole thing? e.g. ufunc loops only need a select
> subset of types.
> - if we do go this route of taking parts / applying scipy specific
> patches, what is easier to do or better maintenance-wise: vendor
> original code + patches, or do the work once by porting relevant parts
> to standalone C or C++ subset?
>
> Obviously, all these should be weighted with other implications of
> adding a dependency. The immediate concerns are distribution size and
> build times.
>
> Cheers,
>
> Evgeni
>
> On Sat, Feb 13, 2021 at 4:06 PM Hans Dembinski <hans.dembinski at gmail.com>
> wrote:
> >
> > Hi Nicholas,
> >
> > as a Boost developer (I wrote Boost.Histogram and contributed to several
> other Boost libs), I think it would be great to build SciPy on Boost.Math,
> it is a win-win.
> >
> > > On 12. Feb 2021, at 22:50, Nicholas McKibben <nicholas.bgp at gmail.com>
> wrote:
> > >
> > > The initial PR includes the zipped Boost headers only (~24MB zipped),
> but adding Boost as a submodule might be a more maintainable approach if
> changes to Boost need to be made in the future.
> >
> > Including it as a submodule seems like a good approach.
> >
> > > Inclusion of the entire Boost library is a virtual necessity for the
> Boost.Math module. Manual attempts to strip away unnecessary files and bcp
> (Boost's utility to provide stripped down installations) fail to create
> smaller sizes.
> >
> > I was a bit shocked to hear this, but you are right:
> > https://pdimov.github.io/boostdep-report/master/math.html
> > Math depends on everything.
> >
> > We have a long-term goal to reduce the coupling between Boost libs, but
> this also incurs costs. Library maintainers then have to copy the relevant
> bits from other Boost libraries to not depend on them, which is actually a
> terrible idea: you loose the synergies offered by a rich shared code base.
> In my view, the coupling is not a bug, it is a feature.
> >
> > It is impressive to see how you use generators to create the binding
> code in Cython. I had a lot of trouble with Cython as it does not support
> all C++ features. The best way to wrap (modern) C++ is pybind11, which is a
> painless experience. It does the code generation at compile-time with TMP.
> >
> > Best regards,
> > Hans
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20210214/9292fc32/attachment.html>