Re: [Multi] Proposal (was Re: Boost Digest, Vol 7345, Issue 1)

From: Seth (bugs_at_[hidden])
Date: 2024-09-22 15:13:07

On Sat, Sep 21, 2024, at 7:10 PM, Artyom Beilis via Boost wrote:

> See, this is exactly the problem. Why would I need something like that
> if I need to go to all the 3rd party libraries to actually use one
> efficiently?

Can you give arguments why "I don't see why I need this" is an argument against a library existing?

> But if you don't provide algorithms, maybe I'd better take a
> library/framework that does.
Perhaps.

> But, you making numpy-like library... otherwise you wouldn't be
> interfacing cblas.

A clear case of diyd/diyd ("Damned If You Do, Damned If You Don't"). Of all the features you're missing here you decry "At least show ways to interoperate with existing thirdparty libraries". Now, they went and did that (if I'm not mistaken, clearly marked as an extension that might not even be part of the proposed library), and you decry that. There's no winning. 

> It [OpenCV] ain't perfect by any means. But it works, well debugged, understood
> and is a widely available library that does the job.

It's also a pretty heavy dependency, especially if you didn't need all the other stuff, and appears to be an example of an intrusive framework (for good reason, IFF you need the rest)

> To make your code compilation slower and more horrible? 

This seems a weird argument to me. The year is 2024. Perhaps you need to update your tools.

> Yeah... good luck with that in numerical context. But Ok. In OpenCV
> you can just get several pointers and work with them

And enjoy bugs without guard-rails. I've implemented serialization on both Cv* and Eigen types, and remember getting it very very subtly wrong without noticing for a long while.

> Exceptions are useful. And claiming that you don't throw ones means
> you don't use new...

Many things don't require allocation. Meanwhile `new(std::nothrow)` has existed since c++11.

> Regards,
> I highly doubt the practicality of the library in the current form.
> While generic multi-array can be nice to have, but actually it is
> stuck at being little bit more that MultiArray [...]

These two sentences are your review! I cannot disagree here, and you have been right in voicing your concern...

> [...] but too far even from basic numpy.

... but this seems to cross over to normative apples/oranges comparison. I could say your review is too far even from basic poetry with equal merit.

>
> My $0.02
>
> Artyom

I have no real clue here, I'm here to learn from both your viewpoints. However mdarray/mdspan facilities are an oft recurring thing - including in the standard - so I'm tempted to think there is demand.

I'm reminded of the once-common schism between game-dev C++ and non-game-dev C++: for a long time useful things were blocked from C++'s evolution because game-devs didn't see the need for them. I'm pretty happy the community grew past that (even though it gave us some wind-eggs like std::async and possibly other stunted features in the future)

Cheers,
Seth