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

[Xiaodi Wu]

On Fri, Feb 17, 2017 at 12:34 PM, Nicolas Fezans <nicolas.fezans at gmail.com>
wrote:

>
> > 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++.
>

What you're asking for is a Swift-native math library! This is something
that people are interested in making, and I would want one too.

>
> > 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.
>

Yes, what you are describing is the syntax for a Swift math library. But
you're saying you're interested in designing only the syntax but not the
implementation! Swift Evolution proposals that are accepted actually get
implemented: someone actually needs to make things happen behind the scenes.

What I'm saying is that there are people who are actively designing Swift
math libraries. Although it may not look it based on the chains that get
the highest response, bikeshedding syntax isn't what this list is for. A
proposal needs to have a detailed design for implementing a feature, not
just propose a syntax. Elementwise operators need to come with a performant
implementation.

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).
>

Right, this is an excellent argument for a core math library in Swift. And
members of the core team have supported that idea. However, they have
stated that the _method_ to accomplish this is to actually implement a math
library, get people to use it, and then propose its integration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/dc223636/attachment.html>