<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 10:51 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><br class="Apple-interchange-newline"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">There's nothing, afaik, which stands in the way of that syntax today. The proposal is to extend the standard library to add syntax for a math library. The idea of having a core math library has already been mentioned on this list, to great approval, but it should come in the form of an actual library, and not a syntax only!</span></div></blockquote></div><br class=""><div class="">Right. IMO the way to do this is to develop such a library outside of the stdlib to the point that it’s useful enough to be employed for real work and people can evaluate what works and what doesn’t. That may require small language and stdlib changes for support, which should be brought-up here.</div><div class=""><br class=""></div><div class="">Once such a library were reasonably mature, it would be reasonable to propose it for inclusion in swift proper. I expect this process will take a couple *years*.</div><div class=""><br class=""></div><div class="">FWIW, I personally despise MATLAB .operator notation, though I accept that it’s pretty much achieved saturation at this point. It looks reasonably nice for simple single-operand expressions, but it imposes a large burden on the compiler (and often leads to inefficient code). In this regard, they are something of an attractive nuisance. Consider your example:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>3.0 .* A .* B ./ (C.^ 4.0)</div><div class=""><br class=""></div><div class="">with the most obvious implementation, this generates four calls to vector functions:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- multiply array by scalar (tmp0 <— 3 .* A)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- elementwise multiplication (tmp1 <— tmp0 .* B)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- elementwise exponentiation (tmp2 <— C .^ 4)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- elementwise division (result <— tmp1 ./ tmp2)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">On the other hand, the stupid obvious loop:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for i in 0 ..< count {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>result[i] = 3*A[i]*B[i]/(C[i]*C[i]*C[i]*C[i])</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class="">or the cleaner, with a little sugar:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>zip3(A,B,C).map { 3 * $0.0 * $0.1 / ($0.2 ^ 4) }</div><div class=""><br class=""></div><div class="">requires a tiny bit of boilerplate, but only a single pass through the data and allows the compiler to vectorize. Even if the four vector functions use by the .operations are perfectly hand-optimized, the multiple passes and extra memory traffic they entail often makes it *slower* than the stupid for loop.</div><div class=""><br class=""></div><div class="">I don’t mean to be too discouraging; all of these issues are surmountable, but I (personally) think there’s a lot of development that should happen *outside* of the stdlib before such a feature is considered for inclusion in the stdlib.</div><div class=""><br class=""></div><div class="">– Steve</div></body></html>