hasktorch VS torchtyping

I assume you are getting https://github.com/hasktorch/hasktorch/issues/631? I suspect you need to upgrade to GHC 9.2 to work reliably on M1.

You might find the Deep Learning From The First Principles tutorials by Bogdan Penkovsky an interesting survey of native Haskell implementations of deep neural networks, and a bit more. It demonstrates some native charting capabilities, and Day 9 uses Hasktorch.

I'm new to Nix and I'm trying to set up a Jupyter notebook environment for Haskell that includes the Hasktorch package. I'm using the jupyenv project from Tweag as the foundation, and I've been able to get it working with some basic Haskell packages. However, I'm running into issues when I try to add Hasktorch to the mix.

That said, there are some things that try to do this. Haskell has a port of torch called HaskTorch that includes this kind of typed tensor shapes, and calls the Z3 theorem prover on the backend to solve type inference. It can get away with this because of the LiquidHaskell compiler extension, which has refinement types capable of solving this kind of typing problem, and is already pretty mature. Dex is a research language from Google that's based on Haskell and built to explore this kind of typechecking. Really you'd want to do this in Rust, because that's where the tradeoff of speed and safety for convenience makes the most sense, but rust is just barely on the edge of having a type system capable of this. You have to get really clever with the type system to make it work at all, and there's been no sustained push from any company to develop this into a mature solution. Hopefully something better comes along soon

As rightfully pointed u/gelisam, both Hasktorch and Pytorch are essentially the same things (bindings to existing Torch library). Therefore, it should be generally possible to use existing pretrained models. Here is an example.

I think it's likely that http://hasktorch.org/ is the library you will want to use for AI models, once you feel comfortable with Haskell.

IF (big if) it turns out you do need deep learning then doing it in Hasktorch http://hasktorch.org/ could be a fun learning project. The team making it is super nice and responsive, too

This said, if you want do do deep learning Python is the obvious choice atm, if only for copy-pasting code from examples (however do you know HaskTorch? https://github.com/hasktorch/hasktorch/ )

Not really an answer to your question, but there are Python packages that try to solve the problem of tensor shapes that you mentioned, e.g. https://github.com/patrick-kidger/torchtyping or https://github.com/deepmind/tensor_annotations

I disagree. I've had a serious attempt at array typing using variadic generics and I'm not impressed. Python's type system has numerous issues... and now they just apply to any "ArrayWithNDimensions" type as well as any "ArrayWith2Dimenensions" type.

Variadic protocols don't exist; many operations like stacking are inexpressible; the synatx is awful and verbose; etc. etc.

I've written more about this here as part of my TorchTyping project: [0]

[0] https://github.com/patrick-kidger/torchtyping/issues/37#issu...

also https://github.com/patrick-kidger/torchtyping

FWIW I'm the author of torchtyping so happy to answer any questions about that. :) I think people are using it!

The one thing I really *really* wish got more attention was named tensors and the tensor type system. Tensor misalignment errors are a constant source of silently-failing bugs. While 3rd party libraries have attempted to fill this gap, it really needs better native support. In particular it seems like bad form to me for programmers to have to remember the specific alignment and broadcasting rules, and then have to apply them to an often poorly documented order of tensor indices. I'd really like to see something like tsalib's warp operator made part of the main library and generalized to arbitrary function application, like a named-tensor version of fold. But preferably using notation closer to that of torchtyping.

Yes it does work with numerical literals! It support using integers to specify an absolute size, strings to specify names for dimensions that should all be consistently sized (and optionally also checks named tensors), "..." to indicate batch dimensions, and so on. See the full list here.