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

[Abe Schneider]

> 
> Well I was rather thinking of making a Swift-only library (at least at first) but that would also be available for other platforms e.g Linux or maybe some day on Windows => also working with reduced performance without the Accelerator Framework but leveraging it on Apple Platforms (and possibly leveraging others on the other platforms). This said I am open to discussion on this... but having a very nice syntax for swift and having an close to one-to-one equivalent also for Objective-C will probably add quite some difficulties.
> 

While still very much in its infancy, just to add the libraries out there, there is: https://github.com/abeschneider/stem <https://github.com/abeschneider/stem> . However, the library currently suffers from design issues related to dispatching correctly from generic functions. That said, I was able to recreate a large part of the Numpy functionality while allowing the ability to leverage the Accelerator Framework and OpenCL/CUDA.

> > again, with the obvious implementation, this wastes space for temporaries and results in extraneous passes through the data. It is often *possible* to solve these issues (at least for some the most common cases) by producing proxy objects that can fuse loops, but that gets very messy very fast, and it’s ton of work to support all the interesting cases.
> 
> This is clear to me and to be honest with you I am not really sure of the best strategy to make this. 

The most successful method I’ve seen for dealing with this is let the user write what is most natural first (allowing for temporaries) but provide a path to optimize (using in-place operations). While expression trees can automate this for the user, it also has the potential for being much more difficult to debug and may not be as optimal as a hand-crafted expression.

> 
> I don't think that the primary target for the library should be to deliver the highest performance possible.
>   => People who do need that level of performance would still need to analyze and optimize their code by themselves and/or directly call the Acceleration Framework or other specialized libraries.
> 
> What I would like to reach instead is rather what I would call "the highest usability possible with decent performance". Some programmers will be satisfied with the level of performance and will enjoy the readability and maintainability of the code based of the library, whereas other will go for more performant libraries (and that is perfectly fine!). Actually, I would even expect later that some of those who belong to the latter category will start experimenting with the easy but less performant library (lets call it here "easy maths library") and optimize their code based on a high performance library only in a second step.

If you can define your operations at the right granularity you can write really optimized Accelerate/OpenCL/CUDA code for the low level parts and string it together with less optimize code.

> 
> My idea of a possibly pragmatic roadmap (which can be followed in that order) to make such a library almost from scratch with the long-term goal of being quite performant but primarily very easy to use could be:
> 
> 1) think about the integration to the language, the syntax, the high-level user documentation, etc. and demonstrate all this based on a relatively low performance implementation
> 
> 2) generate a collection a typical operations where the low-level libraries offer very nice performance or where a clever handling of the temporary variables is possible

For (1) and (2), it’s worth taking a look at what libraries exist already. People have spent a lot of time organizing and re-organizing these. While not perfect, Numpy has become one of the most successful matrix libraries out there.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/1c85ec7c/attachment.html>