mcabbott

7 ms·

31.
by mcabbott 8y ago
Then challenge yourself to write some code completely agnostic to the indexing, which will force you to learn some neat features. Doing pointer arithmetic with your bare hands (however much muscle memory they have) is very seldom necessary,
32.
by mcabbott 8y ago
But that would sum everything, not just the parts which need it. You'd actually have to write this: \sum_a(A_ia x_a) + v_i + \sum_a(x_a y_a) ( w_i + \sum_b(B_ib z_b) ) My example is actually still easier without indices. (Although you
33.
by mcabbott 8y ago
You insert kronecker deltas: ∂M_ab / ∂M_cd = δ_ac δ_bd , and a,b here remain contracted with whatever M was originally contracted with. Then you simplify, δ_ac Z_xya = Z_xyc and so on.
34.
by mcabbott 8y ago
Right, changing the order would be a pain. Although if the reason for doing so is memory layout (for speed), then a lazy permutedims(A) would decouple index order from this. Perhaps when creating a tensor for the first time there ought to b
35.
by mcabbott 8y ago
I made a thing to audit that you are consistent with your indices [1] as an alternative to explicit named-tensor objects. And found, but have not used, another package in a similar spirit [2]. Although to be honest, simply writing A[n,μ,ν,c
36.
by mcabbott 8y ago
If you have just one term, then leaving out the summation sign saves little. But in larger expressions, the rule applies sums per term, and then the savings in clutter can be quite large. For example, here v_i is not summed, and the term wi
37.
by mcabbott 8y ago
There are also differences of building styles, maybe this is part of how we ended up with different terminology. The prototypical Parisian building has a paved driveway to the courtyard which is on the ground level. The prototypical New Eng
38.
by mcabbott 8y ago
I guess lots of things distinguish rows & columns which, for complex numbers, you can think of as up & downstairs -- rows are conjugated. But otherwise everybody seems to live in flat space. If you had reason to do so, it would be e
39.
by mcabbott 8y ago
But why should you have to care, why not just sum(range)? Or @threads for i in eachindex(object) and let the details about how many cores be written once, correctly, elsewhere?
40.
by mcabbott 8y ago
The julia DSL for this is closer to what you want: "M_ij = A_ik * B_kj" reads @einsum M[i,j] := A[i,k] * B[k,j] Or faster with @tensor from https://github.com/Jutho/TensorOperations.jl & the same
41.
by mcabbott 8y ago
It always seems a bit weird to me that np.einsum needs to parse a string in its own private syntax. I guess it's a good thing that at least it has tools for this!
42.
by mcabbott 8y ago
If you want to take it for a spin, challenge yourself not to write anything which cares about this. It will force you to learn the some neat features (e.g. for N-dim arrays) instead of indexing with your bare hands like you're in C. An
43.
by mcabbott 8y ago
Some operations are quite tensor-ish. For instance the re-shaping which einops writes like this Rearrange('b c h w -> b (c h w)') is literally a tensor product of the vector spaces indexed by c,h,w. The same space that
44.
by mcabbott 8y ago
Index notation is often less confusing than numbered dimensions, without requiring an you to use an explicit NamedTensor. Perhaps of interest, here's a quick prototype of how this could be useful. If you use an index "n"-for-