11–20 of 28 posts
Been a while since GR, but I'm pretty sure some of those indices are supposed to be on top. A_{ij} = B_i^k * C_{jk} possibly, but don't quote me on that.
In some fields, e.g. condensed matter physics, you need you need to deal with contracting multidimensional tensors all the time, and with out Einstein notation it would be difficult.
The simples example is so-called matrix product state (http://en.wikipedia.org/wiki/Matrix_product_state), which is similar to Markov process. But for more interesting scenarios (e.g. 2d) one needs to use at least 4 dim tensors.
What the author call "black magic" I call abstraction. Why would you need to know at all times what summation and multiplications of what rows and columns are going on in your matrices? That's why use matrices, to not have to think about those all the time.
You can write `a mmu b` in KDB, but what the author refers to as no clue on the surface to tell me what is A, B, or C is about the need for improved notation, not an extended maths library.
That said, I think the author's notation is terrible, so I'll use a different one. In K you can write
+/+*\:
{+/+x*\:y}
This allows me to see that:
(2 3f;4 0f)*\:(1 2f;5 -1f)
((2 4f;15 -3f);(4 8f;0 -0f))
+/+((2 4f;15 -3f);(4 8f;0 -0f))
This extends to the second example as well: +/1+!x (sum one plus til x) is much more clear than:
int sum=0,i,a[100];
for(i=0;iDo you still think we need a sumcode abstraction now? Or do you understand the value of better list comprehension?
Been a while since GR, but I'm pretty sure some of those indices are supposed to be on top. A_{ij} = B_i^k * C_{jk} possibly, but don't quote me on that.
Since these are Euclidean spaces, the difference between contravariant and covariant indices is non-existent. So it doesn't matter whether the indices are upstairs or downstairs.
Been a while since GR, but I'm pretty sure some of those indices are supposed to be on top. A_{ij} = B_i^k * C_{jk} possibly, but don't quote me on that.
A_i^j = B_i^k*C_k^j .Been a while since GR, but I'm pretty sure some of those indices are supposed to be on top. A_{ij} = B_i^k * C_{jk} possibly, but don't quote me on that.
Since these are Euclidean spaces, the difference between contravariant and covariant indices is non-existent. So it doesn't matter whether the indices are upstairs or downstairs.
Earlier quoted context omitted.
Since these are Euclidean spaces, the difference between contravariant and covariant indices is non-existent. So it doesn't matter whether the indices are upstairs or downstairs.
I would say not 'nonexistent', but rather 'avoidable'; or, even better, that there is an isomorphism in an appropriate sense. (Compare the situation for strings and lists of characters; the types are isomorphic, but I wouldn't say that the difference between them is non-existent!)
This is a good example of a situation where something like lisp's macro system would be very useful. But I don't understand what the author means by
On the other end of the spectrum, lisp is designed for its upper layer elegance. Its macros are structured all the way to the top. However, to achieve that, it limits its lower level representations. In fact, it takes work-around for simple switches and loops.
What's the work-around? Common Lisp and Clojure have built in conditionals and loops.