making Blitz part of Boost?

[slayoo]

Just wondering what would be the pros and cons?

Certainly, it would clarify the way to go with docs, build system, boost dependencies (serialization, MPI, preprocessor), packaging issues, etc

Some legal clarifications would need to be done (but perhaps with benefit for Blitz). Blitz would definitely benefit from Boost review process. Boost folks might be interested given the Boost.MultiArray seems outdated, the overlap with Boost.ublas seems unclear.

Any thoughts?

[citibeth]

Blitz is not up to the standards required for boost. I would like to write a new blitz that is

On Sun, Jul 15, 2018 at 1:14 PM Sylwester Arabas notifications@github.com wrote:

Just wondering what would be the pros and cons?

Certainly, it would clarify the way to go with docs, build system, boost dependencies (serialization, MPI, preprocessor), packaging issues, etc

Some legal clarifications would need to be done (but perhaps with benefit for Blitz). Blitz would definitely benefit from Boost review process. Boost folks might be interested given the Boost.MultiArray seems outdated, the overlap with Boost.ublas seems unclear.

Any thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/blitzpp/blitz/issues/46, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1cd41DLo5MW8E1oewmL0sItMSd0mKPks5uG3h-gaJpZM4VQUZs .

[vukics]

I think in C++ there is a lack of a standard-like multi-array, like numpy.ndarray in Python.

It would be very nice if Boost had something like this, perhaps in the form of a synthesis of Boost.MultiArray and Blitz.

One conceptual problem in Blitz that the Boost people wouldn’t like in my opinion is that it is meant to exhibit reference semantics (ok, it has reference counting – but that might be an overkill anyway…), yet, it doesn’t present all the possibilities of const-ness: non-const reference to non-const, non-const reference to const, const reference to const, const reference to non-const. A blitz::array is either const or non-const.

I think this causes significant mental friction. An elegant solution would be if P_numtype could be specified as a const, which could be treated as the reference-to-const case.

Boost.MultiArray treats this problem nicely in the form of (const_)array_views.

[citibeth]

Blitz++ doesn't follow normal C++ semantics, that is the problem. It acts sort of like a value, and sort of like a shared_ptr. It cannot be put in a collection. These are the reasons I don't think the current version would be a good fit for Boost. I think these problems can be fixed with some thinking through and starting with C++11.

-- Elizabeth

On Sun, Jul 15, 2018 at 3:25 PM, vukics notifications@github.com wrote:

I think in C++ there is a lack of a standard-like multi-array, like numpy.ndarray in Python.

It would be very nice if Boost had something like this, perhaps in the form of a synthesis of Boost.MultiArray and Blitz.

One conceptual problem in Blitz that the Boost people wouldn’t like in my opinion is that it is meant to exhibit reference semantics (ok, it has reference counting – but that might be an overkill anyway…), yet, it doesn’t present all the possibilities of const-ness: non-const reference to non-const, non-const reference to const, const reference to const, const reference to non-const. A blitz::array is either const or non-const.

I think this causes significant mental friction. An elegant solution would be if P_numtype could be specified as a const, which could be treated as the reference-to-const case.

Boost.MultiArray treats this problem nicely in the form of (const_)array_views.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/blitzpp/blitz/issues/46#issuecomment-405112311, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1cdwxkQBHH-uxWLGLikWiVaV-c4Zffks5uG5c0gaJpZM4VQUZs .

[vukics]

By the way, this subject came up already in the blitz++ SF mailing list. It did not generate much echo apart from a brief reaction by myself.

[slayoo]

Given the above and the b11 initiative (#48), let me close this one fully agreeing with @citibeth that it's much more practical to concentrate efforts there.