OCaml bindings for PyTorch • Hacker News Board

Re: OCaml bindings for PyTorch

#21

Post by nestorD » Sun, Jan 20, 2019, 7:34 AM UTC

breatheoften wrote: post #20

Where are cutting edge type systems at for statically verifying the “dimensionality” of computations? I remember a long time ago reading about a language from sun called “fortress” which was going to include the option of assigning units to values in such a way that scientific domain model operations could be defined via a kind of type-sugar ... seems like that technology would work really well for ML (and data scien…

Note that units are implemented in F# : https://fsharpforfunandprofit.com/posts/units-of-measure/

Re: OCaml bindings for PyTorch

#22

Post by jvican » Sun, Jan 20, 2019, 9:13 AM UTC

nafizh wrote: post #16

At the heart of the machine learning that I do with pytorch, most of the errors come from wrong sizes of matrix multiplications, or some matrix input that has a wrong size somewhere in the middle of the net. How much an extra layer of wrapper of a functional language help with that? Pytorch is not much helpful in terms of the error messages. You have to print out the matrix sizes generated from intermediate operation…

The Scala community has some clever techniques to ensure that those properties can be proven at compile-time, for example, https://github.com/eaplatanios/tensorflow_scala for TensorFlow and https://github.com/ctongfei/nexus

Re: OCaml bindings for PyTorch

#23

Post by dunefox » Sun, Jan 20, 2019, 12:27 PM UTC

l-m-z wrote: post #15

dunefox wrote: post #10

Does this support all of the features of PyTorch?

Bindings author here. This should support most of the PyTorch ops - this is done by automatically generating the binding code as there are more than a thousand of these. Most of the models available in torchvision should also be there (with pre-trained weights) see https://github.com/LaurentMazare/ocaml-torch/tree/master/src... Finally it's also possible to export some python defined models and run them from ocaml. T…

Sadly, a lack of material is to be expected for anything but Python...