[mathisfun123]

> Torch, Jax

Both of these "make it available". Just because people don't know how to use/find them doesn't mean they're not "available".

> Eigen

This is not an ML anything, it's a linear algebra library.

> like commenting '# (b, n, t)' on every line, or suffixing shapes to variable names

There's a difference between tracking shapes in the compiler and specifying shapes in the model.

[ainch]

I think we're talking at cross purposes. The reason I'm excited about the Pyrefly work is that it leverages the type system to infer array shapes statically, which makes it simpler to reason about them when you're writing the code and catch bugs. The fact that people have developed these janky approaches to shape tracking suggests that there's a gap to be filled.

Jax and Torch don't do that statically. They obviously have to do it at runtime, but that doesn't address this particular issue. I mention Eigen because array shape hinting is generally useful for any linalg library, not purely for ML applications.

[mathisfun123]

> Jax and Torch don't do that statically. They obviously have to do it at runtime, but that doesn't address this particular issue.

You don't understand what you're talking about.

Jax is explicitly mentioned in your pyrefly link as having a parallel (but slightly weaker) system. In addition Jax is built on stablehlo which uses shape dialect, which is part of the compiler (and therefore statically known).

Torch has a symbolic shape inference system that I helped build:

https://github.com/pytorch/pytorch/blob/main/torch/fx/experi...

> The fact that people have developed these janky approaches to shape tracking suggests that there's a gap to be filled.

I have already said it: the fact that people do not know how to use the tools does not mean the tools are lacking - it means the users are unsophisticated. Let me put it this way: almost everyone that is employed to work with these tools is aware of these features and therefore eschews those kinds of comment strings.

[imtringued]

Every single comment you've posted was unhelpful and demeaning and you've constantly had to backtrack every single time you've had to respond. This is extremely poor form and I see zero goodwill here.

ainch doesn't care about the inference engine knowing the shapes. This is obvious. He has been talking about developer ergonomics and you've basically said "only idiots don't know where the ergonomics features are", while linking to a file which explicitly states that it is a experimental/private API that is only needed in niche situations which is basically doubling down on having poor ergonomics.

If you can't understand the problem as a developer working on those features and you had to link to the source you've written rather than the docs, you're basically admitting that you're the problem.

[mathisfun123]

This is the whiniest response I've ever seen on hn. Congrats.

> you had to link to the source you've written rather than the docs, you're basically admitting that you're the problem.

God forbid i expect people using complex tools to know how they actually work.

Edit: there are two categories of devs out there - those that expect code to be a fully perfected product delivered to them on a silver platter (only requiring docs, which must be perfect btw), and those which understand all code is merely a suggestion. For the latter a code pointer is more than enough. I leave you to infer which are more productive.

[ainch]

Thanks for the reply - you're clearly much more experienced with the internals here, but I believe we're still talking at cross-purposes. I believe you're talking about compilers like jax.jit or torch.compile performing symbolic shape inference. I'm talking about the ergonomics of tracking shape information while writing Python code that calls these libraries. I don't use Torch much, so I'll just comment on the Jax side.

> Jax is explicitly mentioned in your pyrefly link as having a parallel (but slightly weaker) system

Jaxtyping is limited to runtime-only checks (which might as well be assert statements), and doesn't infer shapes based on operations. I'm interested in Pyrefly because I've run into the limitations of Jaxtyping in my own usage.

> Jax is built on stablehlo which uses shape dialect, which is part of the compiler (and therefore statically known).

It's true that JAX does shape inference when it compiles down to HLO - but that isn't available to the Python typing system. The Pyrefly development is addressing that, so you get static analysis before even running anything, or without having to add eval_shape calls all over your codebase. I think that's helpful, and will catch bugs. When I say Jax does inference at runtime, I mean that you have to run for the jit compiler to kick in - you don't get feedback as you edit.

> the fact that people do not know how to use the tools does not mean the tools are lacking... almost everyone that is employed to work with these tools is aware of these features and therefore eschews those kinds of comment strings.

The examples I took are from Andrej Karpathy and Noam Shazeer - maybe the disconnect is that they're more on the research side. Perhaps only unsophisticated users rely on these hacks - but as one such user I'm very excited that Pyrefly is addressing a problem I have. I suspect part of the misunderstanding that's evolved here is that these tools serve audiences with different needs.