Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Owl – OCaml Scientific Computing

ocaml.xyz

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Owl – OCaml Scientific Computing

#71

Post by octachron »

srean wrote: post #16

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 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-opera…

There are some change in the pipes that should make the syntax for slicing lighter in OCaml 4.10 by eliminating the need of the outermost [| |] or [ ]. For instance,

  let a = x.%{ [|2; 3; 4|] }        
  x.%{ [|2; 3; 4|] }
might be simplified to:

  let a = x.%{ 2; 3; 4 }
  x.%{ 2; 3; 4 }
It is possible to go further with ppxs(OCaml version of macros), but at a greater readability cost.

Re: Owl – OCaml Scientific Computing

#72

Post by 6thaccount2 »

socialdemocrat wrote: post #51
ernst_klim wrote: post #9

Earlier quoted context omitted.

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 al…

> 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 arra…

Yea as someone with a little Julia experience looking at this, OCaml just seems to have a lot of boilerplate in weird areas.

The first thing I do when evaluating languages for myself is to look at processing text files line by line or all at once and splitting strings. If that is complicated, then the language might not be well suited to my needs.

With types, a repl, native support for scientific computing and sparse matrices, LLVM JIT, LLVM assembly code inspector, all kinds of macros and support for macros, s-expression macro inspector, speed, easy package manager, large community, good graphics packages...etc, I'm really liking Julia.

Re: Owl – OCaml Scientific Computing

#73

Post by Stubb »

dna_polymerase wrote: post #66
Stubb wrote: post #42

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

Not really, no. I recommend reading this: https://pl-rants.net/posts/ocaml-run-on-24-cores/

Yikes—this makes me cringe having written CUDA and OpenMP code.

Re: Owl – OCaml Scientific Computing

#74

Post by newen »

BeetleB wrote: post #70
newen wrote: post #64

Earlier quoted context omitted.

You should try using R. You're missing out.

In the context of this conversation (dynamic vs static), R is in the same boat as Python. And I don't know about today, but when I used pandas years ago, it was much faster than R.

R's data.table package is much faster and much nicer to use than pandas.

Re: Owl – OCaml Scientific Computing

#75

Post by metta2uall »

srean wrote: post #55
metta2uall wrote: post #48

Earlier quoted context omitted.

What about Math.NET?

Doesnt support float32

It does at least to some extent. Core types like Vector are generic and there is some specific float32 code like:

https://github.com/mathnet/mathnet-numerics/commit/3a0d55fd2...

https://github.com/mathnet/mathnet-numerics/pull/481/commits...

Re: Owl – OCaml Scientific Computing

#76

Post by mseri »

StefanKarpinski wrote: post #56

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 a…

Bigarray[1] allows you to do that and share the memory between C and OCaml.

[1]: https://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray....

Re: Owl – OCaml Scientific Computing

#77

Post by ernst_klim »

BeetleB wrote: post #62
ernst_klim wrote: post #57

Earlier quoted context omitted.

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

>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 b…

>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/

Re: Owl – OCaml Scientific Computing

#78

Post by srean »

metta2uall wrote: post #75
srean wrote: post #55

Earlier quoted context omitted.

Doesnt support float32

It does at least to some extent. Core types like Vector are generic and there is some specific float32 code like: https://github.com/mathnet/mathnet-numerics/commit/3a0d55fd2... https://github.com/mathnet/mathnet-numerics/pull/481/commits...

Sorry I wasnt clear. Meant it does not (unless I missed a recent change) support Float32 for trig functions, exp and likes and special functions.

Re: Owl – OCaml Scientific Computing

#79

Post by mseri »

srean wrote: post #59
StefanKarpinski wrote: post #56

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 a…

If I understand correctly its based on 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.

That’s correct. Afaik, in Owl, the choice to support just C was intentional to avoid overcomplicating the implementation

Re: Owl – OCaml Scientific Computing

#80

Post by o09rdk »

ddragon wrote: post #49
o09rdk wrote: post #46

Earlier quoted context omitted.

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…

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…

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.

Post reply on HN