Hacker News Reader

Comment by stared | Hacker News Reader

I've found that PyTorch is the smoothest for math <-> programming (at least when it comes to vector-like calculus).

See for example gradient descent in maths (LaTeX) and in PyTorch: https://colab.research.google.com/github/stared/thinking-in-...

For the smoothest math <-> programming

View on HN

I have the contrary impression. Fortran and matlab/octave are great for numeric math. Julia is also very good. The python math stuff (either torch or numpy) is always an unreadable mess, you are always fighting against the language. The matrix product and exponentiation operators look like a bad joke. I do not understand how people can take this stuff seriously.

To some extent, it is a matter of taste. Personally, I love functional notation (technically, in PyTorch its chaining) e.g.:

x.matmul(y).pow(2).sum()

This way we can rite a lot of things, and we don't need to make up a new combination of punctuation marks and special characters for an operation.

For example, while one can write in Python:

torch.sum((x @ y) 2)

I consider it less readable. I mean, here maybe it is fine, but once it gets longer, more complicated, or we want to add new operations, it turns into a mess.

Vide "style" section in: https://github.com/stared/thinking-in-tensors-writing-in-pyt...

Both of your examples are equally ugly and equally unreadable to me. Why cannot it be something like Σ(x*y)^2 ? Why the extraneous words "torch", "matmul" and the ridiculous operator @ ?

I'm of the same opinion. In Julia it would be

sum(A * B) ^ 2

If you define sum as Σ then you can do

Σ(A * B) ^ 2

yes I like Julia very much because it seems to put the natural instincts of mathematicians upfront. When programming in Julia you do not have the impression of fighting against the language continuously. Everything that you want to do is accessible, and it is alright if you implement your computation in the most natural way possible. If I try to do that in python, I always end with an ugly mess of numba, numpy and calls to C code used at different places for different reasons.

I think you mean sum((A*B)^2)? That's one character shorter than pytorch if you import sum out of it, and Σ = torch.sum would be fine in Python too.

No, the parent example was sum(A * B)^2.

I don't think you can use * if you want to backprop, for example in layer regularisation. You'd need to use only PyTorch operations such as torch.mul(A, B).pow(2).sum().

The point here isn't that PyTorch can't look similar to Julia in this small example, rather that I can just use regular, concise Julia syntax - unlike in Python + PyTorch where I need to use PyTorch constructs that are outside of Python.

Well, there's the notational ambiguity!

In maths notation, Σ(x * y)^2 would mean Σ((x * y)^2), but in most programming notation, treating Σ as a function, it would be as you say. I'm going with the original formula in https://news.ycombinator.com/item?id=23508661.

I don't know PyTorch, but regular Python, Numpy, Sympy, etc. seem very similar to Julia in this instance.

You're right, that was my mistake - but I wouldn't say that it's extremely ambiguous in this case, I just wasn't consequent enough in reading the formula.

> I don't know PyTorch, but regular Python, Numpy, Sympy, etc. seem very similar to Julia in this instance.

If you need PyTorch to record the operations for the backward pass later on I believe you need to use PyTorch versions of *, +, etc.: torch.mul, torch.sub, torch.add, etc. In Julia you can just use built in functions and let Flux handle the backward pass.

Σ(x*y)^2 is the closest to the traditional notation, which does not mean that it is the best one.

I have a strong preference for notations that can be read consistently from left to right (vide pipe operators, chaining, etc). A litmus test is if when I read something I use the word 'of'.

If you do anything more complicated that only vector-matrix operations (i.e. a lot of quantum information, all deep learning), with all multiplications you need to specify dimensions somehow. Having only two operators for multiplication is not enough.

why is "@" so bad? i mean it's a huge glyph but it's just an operator like +-×÷•, you get used to it

It's bad because it's a special operator for this operation because Python is not made for scientific programming. That's exactly why you have np.matmul, np.dot, etc. all over the place.

Looks like the two asterisks cancelled each other out in

  torch.sum((x @ y)**2)

While I like PyTorch very much I have found Julia + Flux to be even better.

Could you show some examples?

I did try to use Julia quite a few times (including, I don't know 8 years ago), as I loved the philosophy (brief yet fast, types). Sadly, I never considered it readable - a mix of new concepts, legacy MATLAB syntax, and in general disregard for this part (even function names didn't have consistent naming).

If it moved a lot with that respect, I would be happy some nice examples.

I mean, that's a strange thing to say since PyTorch and especially Python are much further from the math than Julia and Flux.

For example, if I want to regularise a layer:

PyTorch:

    l2 = layer.pow(2).sum()

    loss += lambda * l2

Julia:

    l2 = sum(layer .^ 2)

    loss += λ * l2

I can just use regular Julia functions whereas in PyTorch I need to use special PyTorch functions as to not detach the tape. This only gets worse and less readable the more complex things I want to do.

I guess one core thing is that I don't think that the traditional mathematical notation is particularly consistent. (For a reference, I published over a dozen mathematical papers.)

I love when the "data-flow" is consistent, from left to right.

The Julia code (and traditional mathematical notation) reads: middle, right, left.

Plus, instead of inventing infix notation, I find it cleaner to write custom methods/functions rather than rely on (a fixed, limited, and non-apparent) set of built-in inflix operators.

Made-up .^

Reply on news.ycombinator.com