7 ms·

Owl – OCaml Scientific Computing

190 points by alokrai 7y ago

krapht 7y ago
Kinda wish they had gone with F#. Would've been less work for them to write nice functional wrappers around existing .NET libraries. Of course, you can't get funding for something that unambitious, so I understand the tack. Still... I look forward to trying this out once more significant work has been done. I'm a big fan of OCaml-like languages, if that wasn't already obvious.
- mseri 7y ago
  What are the main missing features that make you wait?
- ernst_klim 7y ago
  >Would've been less work for them to write nice functional wrappers around existing .NET libraries. What? Why would they do it? Unix is a standard in the field of scientific computations, so wrapping blas and lapack totally makes sense. Besides, OCaml already had good blas, lapack bindings.
  - profquail 7y ago
    It's been feasible to run F# on Unix for years, first via Mono, and more recently with .NET Core.
  - BeetleB 7y ago
    F# works just fine in Linux. Better than OCaml in Windows. It is the reason I decided to pick F# over OCaml.
    - ernst_klim 7y ago
      >Better than OCaml in Windows. OCaml works great in windows and have good .Net bindings. LexiFi earns money nearly solely from OCaml on windows. >F# works just fine in Linux. Does it have bindings for the majority of popular libs? For example are there Gstreamer and Gtk F# bindings? Do they work on both .Net Core and Mono?
      - BeetleB 7y ago
        >OCaml works great in windows and have good .Net bindings. Perhaps I should clarify. While the language itself might work, the ecosystem didn't seem great. The last time I checked (less than a year ago), opam was mostly broken on Windows. opam is the officially recommended package manager. I didn't want to invest in a system where the official support was virtually nonexistent. Looking at it now, there does seem to be a port of opam for Windows, and the first commit in that repo was less than a year ago, so quite possibly after I last checked. If it works, I may just switch to it (although in my opinion any software requiring cygwin still means poor Windows support...). >Does it have bindings for the majority of popular libs? For example are there Gstreamer and Gtk F# bindings? Do they work on both .Net Core and Mono? There is GTK#[0], which claims support for both. There is Gst#[1], although they claim it is in early stage development. [0] https://www.mono-project.com/docs/gui/gtksharp/ https://www.mono-project.com/docs/gui/gtksharp/ [1] https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.html https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.htm...
        ernst_klim 7y ago
        >The last time I checked (less than a year ago), opam was mostly broken on Windows opam had windows version based on cygwin for a long time [1]. > any software requiring cygwin still means poor Windows support And software requiring .Net has good linux support? Since when requiring an additional runtime means poor support? >While the language itself might work, the ecosystem didn't seem great. Sure, just like .Net ecosystem, which is totally absent on linux. No wpf, media foundation. And bindings to local facilities, like gstreamer, are lacking. Yet the only real metric of the maturity of the support is the fact that people use it in production. And people heavily use OCaml on windows in production. [1] https://fdopen.github.io/opam-repository-mingw/ https://fdopen.github.io/opam-repository-mingw/
- srean 7y ago
  > around existing .NET libraries. Which ones ? A free one analogous to libmath that works with float32 would be a good start. Am serious, would love to know of some .Net libraries for number crunching that one would miss if one were to move out of the .Net platform. Or did you mean non-numeric libraries ?
  - pjmlp 7y ago
    There used to be some like IMSL, now discontinued, I guess there are others still.
    - srean 7y ago
      That's the problem. Everybody has to guess. Everyone thinks there is something out there that somebody else knows. This is a problem I dont have in some of the other ecosystems. That I would have to (i) write my own cos or (ii) take a dependency on a commercial 3rd party library that will likely not be around for long or (iii) call a native library through and FFI, for something as simple as a cos of float32 is not terribly exciting.
      - pjmlp 7y ago
        I have to guess because that kind of work was only relevant to me 5 years ago, so I lost track of what everyone doing data analysis with .NET is using nowadays.
        srean 7y ago
        Oh I have been guessing all year long for several years although it is very relevant to what I do. BTW I did not intend to mean that you are being unhelpful. Scientific computation just isnt a first class citizen of the .net ecosystem. Either you have to write your own or take a dependency on a commercial library for even the simplest stuff and pray that they will be around.
  - metta2uall 7y ago
    What about Math.NET?
- Cybiote 7y ago
  Ocaml and F# are great languages but, rather than lament what language this excellent math library/framework is implemented in, lament that there is no F# equivalent or that projects like Owl outside Python don't really get the attention they need. While having multiple such frameworks per language makes little sense, each language having its own mathlib ecosystem makes a lot of sense from a diversity perspective. We should want to see examples grow not just for F# or Ocaml but also Haskell, Rust, Scala and others. Then we should prioritize as much as possible, inter-operation of libraries, model definitions and outputs.
mirekrusin 7y ago
Scripting zoo with hash imports from gists is interesting idea.
marmaduke 7y ago
It's interesting to read through the contents here: http://ocaml.xyz/chapter/index.html They seem to be implementing the most popular parts of the Python numerical ecosystem from ndarrays to AD graph and neural nets, as well as plotting.
- toolslive 7y ago
  I guess it's bye-bye SciPy for me then.
  - marmaduke 7y ago
    Yeah it'd be great to see ports based on scipy. I didn't see signal or ndimage stuff in Owl, which are regular parts of my scipy based stuff.
improbable22 7y ago
What's the one-minute pitch for using this, over say Python or Julia? I couldn't figure this out from a quick skim.
- asplake 7y ago
  For me, as a Scipy/Flask/Postgres user it would be about completing the stack. Python’s great but for core things I’d love to have an ML-inspired alternative that’s even half as convenient. I watch this space with great interest.
  - phrmoy 7y ago
    A great choice of companion language to your Python stack would be Nim: https://nim-lang.org/ https://nim-lang.org/ (not necessarily ML-inspired) but extremely productive and extremely fast. Bonus, v1.0 is right around the corner for Nim. If you're willing to venture out to a place with an evolving scientific ecosystem, Nim is a great choice to do scientific computing as part of a CPython stack (easy integration both ways since Nim compiles to both C/C++).
- ernst_klim 7y ago
  Static typing. I'm doing a image-related and ml-related research at the moment, and I'm a seasoned OCaml user. So I've tried python for a bit, it was such a pain so I've decided to stick with owl. Without static typing, the discoverability is so low so that you're literally feeling pain tinkering with python. REPL experience with static types is so much better. With numpy and scipy, I had to stick to documentation all the time even to do the most trivial things. What kinds of arguments could I pass to the plotting function? Read the docs. Does this work with dense or sparse matrix? Does it work with array? Read the docs. In OCaml you could derive most of the information from the type, for example a plotting api http://ocaml.xyz/apidoc/owl_plot.html http://ocaml.xyz/apidoc/owl_plot.html Much of this is simply obvious within a REPL session without looking at the doc. Simple calling a function name would show you its type.
  - pjmlp 7y ago
examsumo 7y ago
Learn essential tips and tricks that can help you crack the JEE mains and advanced. Our experts provide study plan, important topics, mock test and tips to prepare for JEE mains. Click here: https://examsumo.com/ https://examsumo.com/
srean 7y ago
The first thing I did was to check how slicing and indexing works. If anyone else is curious it is explained here http://ocaml.xyz/chapter/slicing.html http://ocaml.xyz/chapter/slicing.html The syntax is quite verbose. Anyway to make it better with macros ? Coming from number crunching world makes me wish that the syntax for list and arrays in OCaml were swapped. On a different note, I hope Owl allows flexibility over memory layout in future. Inter-operating with Fortran is often necessary. Besides that, compile time reshaping n-dimensinal-arrays is very useful for having efficient code. As far as I know Julia can do this with macros, may be without macros too. > OCaml’s Bigarray can further use kind GADT to specify the > number type, precision, and memory layout. In Owl, I only > keep the first two but fix the last one because Owl only > uses C-layout, or Row-based layout in its implementation. > See the type definition in Ndarray module.
- marmaduke 7y ago
  I think flexibility becomes a double edged sword over time: when you need to read, understand and modify some code with overloaded operators it can take longer to figure out what's happening.
  - srean 7y ago
    > I think flexibility becomes a double edged sword over time Agreed in general. For the specific case of number crunching though, sooner or later you would like to call out to a Fortran library. That and with DNNs being so popular now, flexibility over how 'tensors' are laid out in memory by an upstream library or how it has to be laid out to call another library is quite crucial. > when you need to read, understand and modify some code with overloaded operators it can take longer to figure out what's happening. If overloading has been a resounding success anywhere that would be in scientific computing. Unless someone goes overboard it really helps rather than hinders understanding by matching traditional mathematical notation.
    - marmaduke 7y ago
      I had non arithmetic syntax in mind when making this comment, such as indexing. Those can be simple as in get the i'th element or get elements corresponding to a mask etc. This makes it easy to write, less easy to know what's actually happening later.
deleted 7y ago
[deleted]
phonebucket 7y ago
I am comfortable with Python, Julia and R, but the static typing and functional aspects of OCaml make Owl look enticing. Can anyone point me towards a good free online resource for learning OCaml?
- thedufer 7y ago
  https://dev.realworldocaml.org/ https://dev.realworldocaml.org/ is a good place to start.
- agumonkey 7y ago
  There's an ocaml mooc on the 'fun' Platforms (french and english lectures iirc)
Stubb 7y ago
What's the state of threading in OCaml? Can I do a multithreaded map() or reduce()?
- dna_polymerase 7y ago
  Not really, no. I recommend reading this: https://pl-rants.net/posts/ocaml-run-on-24-cores/ https://pl-rants.net/posts/ocaml-run-on-24-cores/
  - Stubb 7y ago
    Yikes—this makes me cringe having written CUDA and OpenMP code.
wolfspider 7y ago
I really dig the inception demo. I think this would be a great companion to FStar also written in OCaml.
StefanKarpinski 7y ago
How does Owl handle representing arrays of Float64s (for example) in BLAS-compatible format? That is, as contiguous memory blocks, instead of having each float value individually heap allocated and boxed with the array being an array of pointers to these values. That ability seems like the most basic requirement for a language in which scientific computing is done—if for no other reason than to call BLAS and LAPACK and other Fortran/C/C++ libraries. Vanilla OCaml doesn't support this (as far as I'm aware), so you'd need something like NumPy which grafts typed arrays onto Python, but for OCaml. Of course, OCaml already has typed arrays, unlike Python, there's just a legacy insistence that all collections work with pointers to values, since other wise you might need to compile generic code more than once (god forbid). Is such an "efficient array library" part of Owl? Any tidbits on how it works?
- srean 7y ago
  If I understand correctly its based on http://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray.h... What is a little strange is that Bigarray seems to support both C and Fortran order, but as of now Owl Ndarrays are C order only.
  - mseri 7y ago
    That’s correct. Afaik, in Owl, the choice to support just C was intentional to avoid overcomplicating the implementation
- tomp 7y ago
  OCaml has native support for unboxed ("flat") double arrays. https://github.com/ocaml/ocaml/blob/d3e73595e55e84250fa77f04e9c239dee1224b7b/runtime/caml/mlvalues.h#L279 https://github.com/ocaml/ocaml/blob/d3e73595e55e84250fa77f04...
  - StefanKarpinski 7y ago
    But only for doubles as a one-off thing? That's more than a little a bit unsatisfying...
nafizh 7y ago
By keeping Part 1 as a placeholder they are potentially missing out on a lot of new users who are not familiar with functional programming but are willing to learn it through the use case of scientific computing.

190 points by alokrai 7y ago

Kinda wish they had gone with F#. Would've been less work for them to write nice functional wrappers around existing .NET libraries. Of course, you can't get funding for something that unambitious, so I understand the tack. Still... I look forward to trying this out once more significant work has been done. I'm a big fan of OCaml-like languages, if that wasn't already obvious.

mseri 7y ago
What are the main missing features that make you wait?
ernst_klim 7y ago
>Would've been less work for them to write nice functional wrappers around existing .NET libraries. What? Why would they do it? Unix is a standard in the field of scientific computations, so wrapping blas and lapack totally makes sense. Besides, OCaml already had good blas, lapack bindings.
- profquail 7y ago
  It's been feasible to run F# on Unix for years, first via Mono, and more recently with .NET Core.
- BeetleB 7y ago
  F# works just fine in Linux. Better than OCaml in Windows. It is the reason I decided to pick F# over OCaml.
  - ernst_klim 7y ago
    >Better than OCaml in Windows. OCaml works great in windows and have good .Net bindings. LexiFi earns money nearly solely from OCaml on windows. >F# works just fine in Linux. Does it have bindings for the majority of popular libs? For example are there Gstreamer and Gtk F# bindings? Do they work on both .Net Core and Mono?
    - BeetleB 7y ago
      >OCaml works great in windows and have good .Net bindings. Perhaps I should clarify. While the language itself might work, the ecosystem didn't seem great. The last time I checked (less than a year ago), opam was mostly broken on Windows. opam is the officially recommended package manager. I didn't want to invest in a system where the official support was virtually nonexistent. Looking at it now, there does seem to be a port of opam for Windows, and the first commit in that repo was less than a year ago, so quite possibly after I last checked. If it works, I may just switch to it (although in my opinion any software requiring cygwin still means poor Windows support...). >Does it have bindings for the majority of popular libs? For example are there Gstreamer and Gtk F# bindings? Do they work on both .Net Core and Mono? There is GTK#[0], which claims support for both. There is Gst#[1], although they claim it is in early stage development. [0] https://www.mono-project.com/docs/gui/gtksharp/ https://www.mono-project.com/docs/gui/gtksharp/ [1] https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.html https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.htm...
      - ernst_klim 7y ago
        >The last time I checked (less than a year ago), opam was mostly broken on Windows opam had windows version based on cygwin for a long time [1]. > any software requiring cygwin still means poor Windows support And software requiring .Net has good linux support? Since when requiring an additional runtime means poor support? >While the language itself might work, the ecosystem didn't seem great. Sure, just like .Net ecosystem, which is totally absent on linux. No wpf, media foundation. And bindings to local facilities, like gstreamer, are lacking. Yet the only real metric of the maturity of the support is the fact that people use it in production. And people heavily use OCaml on windows in production. [1] https://fdopen.github.io/opam-repository-mingw/ https://fdopen.github.io/opam-repository-mingw/
srean 7y ago
> around existing .NET libraries. Which ones ? A free one analogous to libmath that works with float32 would be a good start. Am serious, would love to know of some .Net libraries for number crunching that one would miss if one were to move out of the .Net platform. Or did you mean non-numeric libraries ?
- pjmlp 7y ago
  There used to be some like IMSL, now discontinued, I guess there are others still.
  - srean 7y ago
    That's the problem. Everybody has to guess. Everyone thinks there is something out there that somebody else knows. This is a problem I dont have in some of the other ecosystems. That I would have to (i) write my own cos or (ii) take a dependency on a commercial 3rd party library that will likely not be around for long or (iii) call a native library through and FFI, for something as simple as a cos of float32 is not terribly exciting.
    - pjmlp 7y ago
      I have to guess because that kind of work was only relevant to me 5 years ago, so I lost track of what everyone doing data analysis with .NET is using nowadays.
      - srean 7y ago
        Oh I have been guessing all year long for several years although it is very relevant to what I do. BTW I did not intend to mean that you are being unhelpful. Scientific computation just isnt a first class citizen of the .net ecosystem. Either you have to write your own or take a dependency on a commercial library for even the simplest stuff and pray that they will be around.
- metta2uall 7y ago
  What about Math.NET?
Cybiote 7y ago
Ocaml and F# are great languages but, rather than lament what language this excellent math library/framework is implemented in, lament that there is no F# equivalent or that projects like Owl outside Python don't really get the attention they need. While having multiple such frameworks per language makes little sense, each language having its own mathlib ecosystem makes a lot of sense from a diversity perspective. We should want to see examples grow not just for F# or Ocaml but also Haskell, Rust, Scala and others. Then we should prioritize as much as possible, inter-operation of libraries, model definitions and outputs.

mirekrusin 7y ago

Scripting zoo with hash imports from gists is interesting idea.

marmaduke 7y ago

It's interesting to read through the contents here: http://ocaml.xyz/chapter/index.html They seem to be implementing the most popular parts of the Python numerical ecosystem from ndarrays to AD graph and neural nets, as well as plotting.

toolslive 7y ago
I guess it's bye-bye SciPy for me then.
- marmaduke 7y ago
  Yeah it'd be great to see ports based on scipy. I didn't see signal or ndimage stuff in Owl, which are regular parts of my scipy based stuff.

improbable22 7y ago

What's the one-minute pitch for using this, over say Python or Julia? I couldn't figure this out from a quick skim.

asplake 7y ago
For me, as a Scipy/Flask/Postgres user it would be about completing the stack. Python’s great but for core things I’d love to have an ML-inspired alternative that’s even half as convenient. I watch this space with great interest.
- phrmoy 7y ago
  A great choice of companion language to your Python stack would be Nim: https://nim-lang.org/ https://nim-lang.org/ (not necessarily ML-inspired) but extremely productive and extremely fast. Bonus, v1.0 is right around the corner for Nim. If you're willing to venture out to a place with an evolving scientific ecosystem, Nim is a great choice to do scientific computing as part of a CPython stack (easy integration both ways since Nim compiles to both C/C++).
ernst_klim 7y ago
Static typing. I'm doing a image-related and ml-related research at the moment, and I'm a seasoned OCaml user. So I've tried python for a bit, it was such a pain so I've decided to stick with owl. Without static typing, the discoverability is so low so that you're literally feeling pain tinkering with python. REPL experience with static types is so much better. With numpy and scipy, I had to stick to documentation all the time even to do the most trivial things. What kinds of arguments could I pass to the plotting function? Read the docs. Does this work with dense or sparse matrix? Does it work with array? Read the docs. In OCaml you could derive most of the information from the type, for example a plotting api http://ocaml.xyz/apidoc/owl_plot.html http://ocaml.xyz/apidoc/owl_plot.html Much of this is simply obvious within a REPL session without looking at the doc. Simple calling a function name would show you its type.
- pjmlp 7y ago

examsumo 7y ago

Learn essential tips and tricks that can help you crack the JEE mains and advanced. Our experts provide study plan, important topics, mock test and tips to prepare for JEE mains. Click here: https://examsumo.com/ https://examsumo.com/

srean 7y ago

The first thing I did was to check how slicing and indexing works. If anyone else is curious it is explained here http://ocaml.xyz/chapter/slicing.html http://ocaml.xyz/chapter/slicing.html The syntax is quite verbose. Anyway to make it better with macros ? Coming from number crunching world makes me wish that the syntax for list and arrays in OCaml were swapped. On a different note, I hope Owl allows flexibility over memory layout in future. Inter-operating with Fortran is often necessary. Besides that, compile time reshaping n-dimensinal-arrays is very useful for having efficient code. As far as I know Julia can do this with macros, may be without macros too. > OCaml’s Bigarray can further use kind GADT to specify the > number type, precision, and memory layout. In Owl, I only > keep the first two but fix the last one because Owl only > uses C-layout, or Row-based layout in its implementation. > See the type definition in Ndarray module.

marmaduke 7y ago
I think flexibility becomes a double edged sword over time: when you need to read, understand and modify some code with overloaded operators it can take longer to figure out what's happening.
- srean 7y ago
  > I think flexibility becomes a double edged sword over time Agreed in general. For the specific case of number crunching though, sooner or later you would like to call out to a Fortran library. That and with DNNs being so popular now, flexibility over how 'tensors' are laid out in memory by an upstream library or how it has to be laid out to call another library is quite crucial. > when you need to read, understand and modify some code with overloaded operators it can take longer to figure out what's happening. If overloading has been a resounding success anywhere that would be in scientific computing. Unless someone goes overboard it really helps rather than hinders understanding by matching traditional mathematical notation.
  - marmaduke 7y ago
    I had non arithmetic syntax in mind when making this comment, such as indexing. Those can be simple as in get the i'th element or get elements corresponding to a mask etc. This makes it easy to write, less easy to know what's actually happening later.

deleted 7y ago

[deleted]

phonebucket 7y ago

I am comfortable with Python, Julia and R, but the static typing and functional aspects of OCaml make Owl look enticing. Can anyone point me towards a good free online resource for learning OCaml?

thedufer 7y ago
https://dev.realworldocaml.org/ https://dev.realworldocaml.org/ is a good place to start.
agumonkey 7y ago
There's an ocaml mooc on the 'fun' Platforms (french and english lectures iirc)

Stubb 7y ago

What's the state of threading in OCaml? Can I do a multithreaded map() or reduce()?

dna_polymerase 7y ago
Not really, no. I recommend reading this: https://pl-rants.net/posts/ocaml-run-on-24-cores/ https://pl-rants.net/posts/ocaml-run-on-24-cores/
- Stubb 7y ago
  Yikes—this makes me cringe having written CUDA and OpenMP code.

wolfspider 7y ago

I really dig the inception demo. I think this would be a great companion to FStar also written in OCaml.

StefanKarpinski 7y ago

How does Owl handle representing arrays of Float64s (for example) in BLAS-compatible format? That is, as contiguous memory blocks, instead of having each float value individually heap allocated and boxed with the array being an array of pointers to these values. That ability seems like the most basic requirement for a language in which scientific computing is done—if for no other reason than to call BLAS and LAPACK and other Fortran/C/C++ libraries. Vanilla OCaml doesn't support this (as far as I'm aware), so you'd need something like NumPy which grafts typed arrays onto Python, but for OCaml. Of course, OCaml already has typed arrays, unlike Python, there's just a legacy insistence that all collections work with pointers to values, since other wise you might need to compile generic code more than once (god forbid). Is such an "efficient array library" part of Owl? Any tidbits on how it works?

srean 7y ago
If I understand correctly its based on http://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray.h... What is a little strange is that Bigarray seems to support both C and Fortran order, but as of now Owl Ndarrays are C order only.
- mseri 7y ago
  That’s correct. Afaik, in Owl, the choice to support just C was intentional to avoid overcomplicating the implementation
tomp 7y ago
OCaml has native support for unboxed ("flat") double arrays. https://github.com/ocaml/ocaml/blob/d3e73595e55e84250fa77f04e9c239dee1224b7b/runtime/caml/mlvalues.h#L279 https://github.com/ocaml/ocaml/blob/d3e73595e55e84250fa77f04...
- StefanKarpinski 7y ago
  But only for doubles as a one-off thing? That's more than a little a bit unsatisfying...

nafizh 7y ago

By keeping Part 1 as a placeholder they are potentially missing out on a lot of new users who are not familiar with functional programming but are willing to learn it through the use case of scientific computing.