<div dir="ltr"><br>&gt; If you&#39;re simply looking for elementwise multiply without performance<br>&gt; requirements, map(*) is a very succinct spelling.<br><br>Yes, it is (combined with zip), but:<br>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)<br>2) the syntax becomes a bit uglier if you want an element-wise multiplication of two [[[Double]]]<br>3) And the syntax I propose allow scientist to write things like (here Version 2)<br><br>    3.0 .* A .* B ./ (C.^ 4.0)<br><br>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++. <br><br>&gt;<br>&gt; Performant implementations for these operations like you have in Matlab rely<br>&gt; on special math libraries. Apple platforms have Accelerate that makes this<br>&gt; possible, and other implementations of BLAS/LAPACK do the same for Linux and<br>&gt; Windows platforms.<br>&gt;<br>&gt; There has been talk on this list of writing Swifty wrappers for such<br>&gt; libraries. The core team has said that the way to get such facilities into<br>&gt; Swift corelibs is to write your own library, get broad adoption, then<br>&gt; propose its acceptance here. Currently, several libraries like Surge and<br>&gt; Upsurge offer vectorized wrappers in Swifty syntax for Apple platforms; it<br>&gt; would be interesting to explore whether the same can be done in a<br>&gt; cross-platform way.<br>&gt;<br>&gt; But simply adding sugar to the standard library will not give you the<br>&gt; results you&#39;re looking for (by which I mean, the performance will be<br>&gt; unacceptable), and there&#39;s no point in providing sugar for something that<br>&gt; doesn&#39;t work like the operator implies (Matlab&#39;s elementwise operators offer<br>&gt; _great_ performance).<br>&gt;<br><br><br>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 <u>should happen behind the scene</u> and which is IMO relatively decoupled from the syntax exposed to the programmers.<div><br></div><div><br></div><div>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.</div><div><br></div><div>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 &quot;talk to each other&quot;: 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.</div><div><br></div><div>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).</div><div><br></div><div><br></div><div><br></div><div>Nicolas</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><br><br></div></div>