[swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

[Nicolas Fezans]

> If you're simply looking for elementwise multiply without performance
> requirements, map(*) is a very succinct spelling.

Yes, it is (combined with zip), but:
1) zip map will not enforce same size (which shall be done to fail hard
early), nor allow to combine with an array of a single element, nor with a
single element (same type but not even wrapped in the array)
2) the syntax becomes a bit uglier if you want an element-wise
multiplication of two [[[Double]]]
3) And the syntax I propose allow scientist to write things like (here
Version 2)

    3.0 .* A .* B ./ (C.^ 4.0)

which is extremely clear to read and look pretty much as we would write in
maths. BTW some of the functionalities I am mentioning here are existing
with no specific libraries with the std::valarray in C++.

>
> Performant implementations for these operations like you have in Matlab
rely
> on special math libraries. Apple platforms have Accelerate that makes this
> possible, and other implementations of BLAS/LAPACK do the same for Linux
and
> Windows platforms.
>
> There has been talk on this list of writing Swifty wrappers for such
> libraries. The core team has said that the way to get such facilities into
> Swift corelibs is to write your own library, get broad adoption, then
> propose its acceptance here. Currently, several libraries like Surge and
> Upsurge offer vectorized wrappers in Swifty syntax for Apple platforms; it
> would be interesting to explore whether the same can be done in a
> cross-platform way.
>
> But simply adding sugar to the standard library will not give you the
> results you're looking for (by which I mean, the performance will be
> unacceptable), and there's no point in providing sugar for something that
> doesn't work like the operator implies (Matlab's elementwise operators
offer
> _great_ performance).
>


Yes this is clear to me. My proposal is rather on bringing these syntax to
the language and the code given is only here to illustrate the kind of
behavior that I desire. Whether the computations are delegate to external
libraries, etc. is something that is very important for the performance but
that *should happen behind the scene* and which is IMO relatively decoupled
from the syntax exposed to the programmers.


I would like to insist on a particular point which is of daily concern to
me at work, where I cannot really use swift (at least not yet) and do these
kinds of things in C or C++. One issues that we have in academia is that we
often have algorithms developed independently by different groups of people
in different projects and for many years with no intentions to bring them
together.

Team A decides to built a solution based on a dedicated library libA
whereas team B decides to use another library libB for providing these
functionalities. Often it might even be the same library but in completely
different versions because there was 10 years between both developments.
Now a project C started and need to reuse pieces from project A and B but
the libraries do not "talk to each other": a matrix-type from libA is
different from a matrix-type from libB and you must refactor most of the
code to get the whole thing work together.

This situation also never happen (or to a very limited extend) in Matlab,
because the whole basic objects, matrices and so on are directly part of
the language and not provided by external libraries. The call to the highly
performant BLAS/LAPACK libraries happen behind the scenes and in
99.999999999% of the cases you never have to take care of anything. If
swift was integrating the right syntaxes in the language, my guess is that
many scientists who currently use C++ would be very interested (just as
most of them were preferring FORTRAN to C/C++ a long time ago).



Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/26ed3457/attachment.html>