s = 0 for k in range(0, N): s += a[k]
Ok, I have more cores/CPUs, could I do it in parallel? Sure
v1 = Sum(0, N/2) v2 = Sum(N/2, N) s = v1 + v2
I even could do it on asymmetric cores (like most phone CPUs today)
v1 = Sum(0, K) v2 = Sum(K, N) s = v1 + v2
I could do a bit more complicated things, like calculating means. For that, I have to make a monoid
def mean(from, to, a): m = 0 for k in range(from, to): m += a[k] N = to - from return (m/N, N)
Here I'm returning tuple, and for that to be a monoid I have to state composition law:
def compose(M1, M2): A1, N1 = M1 A2, N2 = M2 N = N1+N2 return ((A1N1 + A2N2)/N, N)
If my identity is (0,0) tuple, it is quite easy to verify that indeed I have a monoid. Nice, simple, composable ranges.
For closed [1...N] ranges this is NOT nice, NOT simple, just plain fugly exercise. Sorry, looks like code samples are screwed up a bit, don't know how to fix it
@threads for i in eachindex(object)
Sure, if you have single infinitely fast CPU. In real life, we have to decompose problem, run it in parallel and compose it back.
> Or @threads for i in eachindex(object) & let the details about how many cores be written once, correctly, elsewhere?
Here I'm explicitly talking about details, how it should be done, importance of composition, monoids etc. I understand, that if someone did it for you, you might not care - well, more power to you then. But some basics rules about Pyton ranges are pretty good:
1. [0...K) + [K...N) = [0...N)
2. Given range [K...N), number of elements in the range is N-K, in case of [0...N) number of elements is N-0=N.
Simple, elegant, composable. I can't say the same about Julia
[1...N] = [1...N+1) = [1...K+1) + [K+1..N+1)
So the real loss is your point (2) - which, I agree, makes the implementation much less elegant and simple.
you could make them work, but improper abstraction leaks out in so many fugly ways. F.e. in Python you could compose functions, not only ranges. What do you pass in? Simple, [0, len(a)). What you get out? Simple, len(a). So you could operate on ranges composing function calls like in FP. Even works for unknown beforehand sequences/streams, just count along the sequence how many events you processed, and return it as length, and it could go into composition function. With Julia you have to think what is passed and what is returned. Shall I always return len(a)? Or maybe len(a)+1? What to return in case of streaming events? Sometimes len(a) and sometimes len(a)+1 with tons of comments and warnings? It is not a good way to deal with all that and not a good way to build API. Could be done and probably was already done, sure. BUt simplicity, elegance and composability is missing in the base design.
function mean(a, l, r)
s = 0
N = r-l+1
for k in l:r
s += a[k]
end
s/N, N
end
function mean2(a)
N = length(a)
lr1 = (1,div(N,2))
lr2 = (div(N,2)+1,N)
v1, N1 = mean(a, lr1...)
v2, N2 = mean(a, lr2...)
N = N1+N2
(v1 * N1 + v2 * N2) / N, N
end
function compose(M1, M2)
v1, N1 = M1
v2, N2 = M2
N = N1+N2
(v1 * N1 + v2 * N2) / N
end
function mean3(a)
N = length(a)
lr1 = (1,div(N,2))
lr2 = (div(N,2)+1,N)
compose(mean(a, lr1...), mean(a, lr2...))
end
No, they are not. I'm talking about ability to build (and build upon) underlying algebraic structure.
ok, could you make a monoid out of your/Julia closed ranges? What would be a unit in this monoid? How would you make a null/empty range?
Say I have an index `idx` into a very large array and I want to select a symmetric window of `N` indices before and after that index. In Julia:
A[idx .+ (-N:N)]
A[idx-N:idx+N+1]
Heck, in Julia I can even easily determine what the OOB behavior should be. It's an error above, but I can easily change it. This, for example, will ensure no indices go out of bounds by repeating the final endpoint as necessary.
A[clamp.(idx .+ (-N:N), 1, end)]
Could you make proper monoid out of Julia ranges? What would be a unit in that monoid? Could you tell me how empty range looks in Julia (in Python/C++ it looks trivial)?
> Python cannot even index lists by ranges (or other lists)
sure, Python has deficiencies as well.
C++ STL iterators/ranges are made in the same way, and for a good reason - composability first. It described very well in Alex Stepanov book (https://www.amazon.com/Mathematics-Generic-Programming-Alexa...), as well as how it helps when we move to parallel algorithms (http://stepanovpapers.com/p5-austern.pdf).
It is even more explicit in upcoming Ranges library in C++20
split(r) = r[1:end÷2], r[end÷2+1:end]
A zealous adherence to one strategy or another will simply blind you to the ways in which the other might be easier at different times.
True for python lists, but not true for numpy arrays.