> On Feb 17, 2017, at 10:51 AM, Xiaodi Wu via swift-evolution
> <[email protected]> wrote:
>
> 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!
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.
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*.
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:
3.0 .* A .* B ./ (C.^ 4.0)
with the most obvious implementation, this generates four calls to vector
functions:
- multiply array by scalar (tmp0 <— 3 .* A)
- elementwise multiplication (tmp1 <— tmp0 .* B)
- elementwise exponentiation (tmp2 <— C .^ 4)
- elementwise division (result <— tmp1 ./ tmp2)
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.
On the other hand, the stupid obvious loop:
for i in 0 ..< count {
result[i] = 3*A[i]*B[i]/(C[i]*C[i]*C[i]*C[i])
}
or the cleaner, with a little sugar:
zip3(A,B,C).map { 3 * $0.0 * $0.1 / ($0.2 ^ 4) }
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.
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.
– Steve_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
