3 ms·

As someone that likes and uses OCaml a lot but uses Julia for scientific computing, it's not worth it, just use Julia. The Julia code is going to be shorter, f

by smabie 6y ago

As someone that likes and uses OCaml a lot but uses Julia for scientific computing, it's not worth it, just use Julia. The Julia code is going to be shorter, faster, and more elegant. The libraries will be sooo much better. The static typing of OCaml doesn't really help in this area and sometimes actually hurts (statically typed DataFrames don't work so well).

gnufx 6y ago
What makes Julia code shorter and more elegant generally? I strongly disagree with static typing not being useful in scientific computing. Most of that I see isn't dealing with data frames, though I've seen confusion with types in those with R users.
- smabie 6y ago
  I would say the biggest difference is broadcasting. So let's say I have an array of returns, r: r = [0.0001; -0.00002...] I might be interested to find the cumulative returns: cumprod(1 .+ r) .- 1 Or just apply a function f to it: f.(r) In Ocaml I can't vectorize any notation: List.map ~f:(fun x -> x - 1)) @@ List.cumprod(List.map r ~f:((+) 1)) List.map r ~f:f Julia allows you to write code in a very vectorized, array language style. OCaml does not. This is big big issue, imo. Also with multi-dimensional arrays and slice notation, Julia is just very convenient for working with higher dimensional data. OCaml, to put it mildly, is not very good at this. Scientific computing and array languages go hand in hand. Also the lack of polymorphic functions is a big problem in OCaml. For example it would be impossible to define an addition function in OCaml that transparently worked with arrays: 1 .+ [1; 2; 3] == [2; 3; 4] 1+1 == 2 [1; 2; 3] .+ 1 == [2; 3; 4] [1; 2; 3] .+ [1; 2; 3] == [2; 4; 6] Julia makes this easy. A real array language like kdb+/q or J is even better. This is great for linear algebra (matrices and tensors). You can write very math-like equations using very high level functions. With OCaml you will always be burdened with the nitty gritty of mapping and folding over the lists/arrays.
  - mseri 6y ago
    owl ndarrays come with operations that support broadcasting though

by smabie 6y ago

gnufx 6y ago

What makes Julia code shorter and more elegant generally? I strongly disagree with static typing not being useful in scientific computing. Most of that I see isn't dealing with data frames, though I've seen confusion with types in those with R users.

smabie 6y ago
I would say the biggest difference is broadcasting. So let's say I have an array of returns, r: r = [0.0001; -0.00002...] I might be interested to find the cumulative returns: cumprod(1 .+ r) .- 1 Or just apply a function f to it: f.(r) In Ocaml I can't vectorize any notation: List.map ~f:(fun x -> x - 1)) @@ List.cumprod(List.map r ~f:((+) 1)) List.map r ~f:f Julia allows you to write code in a very vectorized, array language style. OCaml does not. This is big big issue, imo. Also with multi-dimensional arrays and slice notation, Julia is just very convenient for working with higher dimensional data. OCaml, to put it mildly, is not very good at this. Scientific computing and array languages go hand in hand. Also the lack of polymorphic functions is a big problem in OCaml. For example it would be impossible to define an addition function in OCaml that transparently worked with arrays: 1 .+ [1; 2; 3] == [2; 3; 4] 1+1 == 2 [1; 2; 3] .+ 1 == [2; 3; 4] [1; 2; 3] .+ [1; 2; 3] == [2; 4; 6] Julia makes this easy. A real array language like kdb+/q or J is even better. This is great for linear algebra (matrices and tensors). You can write very math-like equations using very high level functions. With OCaml you will always be burdened with the nitty gritty of mapping and folding over the lists/arrays.
- mseri 6y ago
  owl ndarrays come with operations that support broadcasting though