
Owl – OCaml Scientific Computing - alokrai
http://ocaml.xyz
======
srean
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
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
> 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
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.

------
marmaduke
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
I guess it's bye-bye SciPy for me then.

~~~
marmaduke
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.

------
StefanKarpinski
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?

~~~
tomp
OCaml has native support for unboxed ("flat") double arrays.

[https://github.com/ocaml/ocaml/blob/d3e73595e55e84250fa77f04...](https://github.com/ocaml/ocaml/blob/d3e73595e55e84250fa77f04e9c239dee1224b7b/runtime/caml/mlvalues.h#L279)

~~~
StefanKarpinski
But only for doubles as a one-off thing? That's more than a little a bit
unsatisfying...

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

~~~
dna_polymerase
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
Yikes—this makes me cringe having written CUDA and OpenMP code.

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

~~~
ernst_klim
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
Although Julia is a dynamic language, the way it uses type inference and type
annotations, you can also achieve a similar experience.

Naturally OCaml benefits from almost 20 years existence.

~~~
seanmcdirmid
How does Julia’s dynamic typing augment discoverability? Does it magically tie
into a code completion engine somehow?

~~~
o09rdk
My understanding/experience is that Julia has optional typing. Meaning it's
dynamically typed, but supports type annotation that often improves
performance and can be used to enforce types (I think).

A lot of Julia code looks statically typed, but if you want to code "pure"
dynamically (e.g., for prototyping or just because it's more convenient or
better for whatever reason) in style you can. Type annotation is seen as
increasing information for the compiler to use, and to increase clarity in
specification, but not a necessity.

This is different from other dynamic languages I'm familiar with where type
specification and annotation isn't built in to the same extent, and different
from static languages that require type specification all the time.

To me, Julia's approach feels the best of the languages I've used. I've grown
to like statically typed languages more over time, but there are some
situations where it can create huge headaches (e.g., where the type structures
of a library, etc. are poorly organized or unclear).

~~~
ddragon
Actually, type annotations in Julia do not improve performance (and in some
pathological cases can even reduce performance). The Julia JIT compiler will
always infer the type at compile-time regardless of annotation and will
(almost) always produce the optimal code.

The reason for type annotations are for the multiple dispatch (multimethods),
documentation, to deliberately restrict the polymorphism of a function and for
the rare times when the compiler will not be able to infer the best type.

~~~
o09rdk
Interesting. I swear for a long time this (the assertion that type annotations
can improve performance) was in the Julia documentation, so much so I stopped
reading it. But maybe something changed? There have been a lot of changes.

Then again, maybe I just misunderstood something.

------
phonebucket
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
[https://dev.realworldocaml.org/](https://dev.realworldocaml.org/) is a good
place to start.

------
nafizh
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.

------
mirekrusin
Scripting zoo with hash imports from gists is interesting idea.

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

------
krapht
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.

~~~
ernst_klim
>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.

~~~
BeetleB
F# works just fine in Linux. Better than OCaml in Windows. It is the reason I
decided to pick F# over OCaml.

~~~
ernst_klim
>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
>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.htm...](https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.html)

~~~
ernst_klim
>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/)

