Live data from Hacker News

Owl – An OCaml Numerical Library

github.com

31–40 of 48 posts

Re: Owl – An OCaml Numerical Library

#31
post #24

Earlier quoted context omitted.

Is it the same as automatic differentiation? Is this native support (as opposed to there being a library for it)?

> Is it the same as automatic differentiation? Yes, "algorithmic differentiation" is the modern term for what was formerly called "automatic differentiation". > Is this native support (as opposed to there being a library for it)? I didn't look into the details, but it seems to be essentially the "operator overloading" approach, not the "source transformation" approach. However, given the optimizing compiler and OCaml…

when did that happen? i have never heard AD referred to as algorithmic differentiation. seems weird to me as automatic is already a good name. algorithmic, to me, conjures up ideas more related to numerical differentiation. there are algorithms in the implementations but the concept really is automatic.

Re: Owl – An OCaml Numerical Library

#32
post #29
post #20

This is going to be extremely useful! I just recently settled on OCaml as my language of choice for most projects, after working with dozens of others, from C to Haskell. I was actually looking for a good numerical library, supporting complex numbers, matrix operations, and multi-dimensional arrays. I'm looking forward to using and contributing to this one!

What are some of the factors that contribute to OCaml being your language of choice / do you feel limited by the poor multicore parallelism story?

Not OP but also OCaml user here, I consider Haskell's laziness to be the wrong default and think it makes it harder to reason about programs, and I prefer the 'mostly pure' approach of ML languages to strict purity.

For me OCaml or the ML family hit the sweet spot of language design.

I will agree that the parallelism issue can be a problem.

Re: Owl – An OCaml Numerical Library

#33
post #29

Earlier quoted context omitted.

What are some of the factors that contribute to OCaml being your language of choice / do you feel limited by the poor multicore parallelism story?

Not OP but also OCaml user here, I consider Haskell's laziness to be the wrong default and think it makes it harder to reason about programs, and I prefer the 'mostly pure' approach of ML languages to strict purity. For me OCaml or the ML family hit the sweet spot of language design. I will agree that the parallelism issue can be a problem.

Then you should try Idriss. This language is haskell with dependent typing and static by default.

Re: Owl – An OCaml Numerical Library

#35
post #6

I looked at OCaml a few years back for scientific computing, but was turned off by the global lock GC for multithreading (similar to python). Anyone know if this has been changed yet? Edit: doesn't look like this has changed, but there's an effort at https://github.com/ocamllabs/ocaml-multicore that is slowly making progress

A lot of scientific computing is done in python (numpy) and even in Lua (using torch the great tensor library). Much of the computations are done in the GPU anyway.

Re: Owl – An OCaml Numerical Library

#36
post #26

Any hope for windows users? Hopefully OPAM works under windows OOTB.

Have you tried the recent Linux subsystem for Windows, or Ubuntu for Windows? I have had a lot of success running various development tools in it. You can use pre-compiled Ubuntu binaries or compile your own stack, and it all runs at native speed, since there is no virtualization or emulation of any kind. https://news.ycombinator.com/item?id=11390545 https://news.ycombinator.com/item?id=14741714

I prefer mingw all the way.

Re: Owl – An OCaml Numerical Library

#37
post #16
post #15

Earlier quoted context omitted.

> I think multicore capabilities will be here soon. Just a word of caution to set expectations. The "will be here soon" status has been there for a while, to the extent that it now evokes memories of GNU Hurd, Duke Nukem Forever. It will be ready whenever it will be ready, its in good hands, but don't hold your breath, try to work around it for now.

Multicore is picking up pace, and there will be a paper on the formalised memory model at this year's OCaml Workshop in Oxford in September. There are a series of milestones to hit: the runtime GC, the memory model, the low-level programming model using one-shot continuations, and how it affects libraries running over it (e.g. algebraic effects). Each of these have associated papers and talks (see the ocamllabs.ionew…

I second on this. The multicore support is not far away. Right now we have a memory model for multicore OCaml and even a multicore OCaml ARM64 backend.

Re: Owl – An OCaml Numerical Library

#38
I find this design clean and appealing. Compared to the current fashion of all these Python libraries, it's a breath of fresh air. But I wonder if it can work. Python has going for it: kitchen sink of tools, easy to learn, tooling that took 20 years to develop, you already know it.

Question: What's wrong with Matlab? Is it that it's closed and costs money? Other than that it seems clean, purpose-built, complete and not really expensive. Why all the open-source attempts to replace it?

I really thought Julia was going to do that, but it's been years and they never got the tooling. They never solved the ridiculous, self-inflicted problem of having to recompile the entire system every time you run it. You're code will execute in 300ms, but only after 10 minutes of compiling. (Or did they make progress? I haven't checked in in a while.)

Anyway, serious question: Why not Matlab?

Re: Owl – An OCaml Numerical Library

#39
post #29

Earlier quoted context omitted.

What are some of the factors that contribute to OCaml being your language of choice / do you feel limited by the poor multicore parallelism story?

Not OP but also OCaml user here, I consider Haskell's laziness to be the wrong default and think it makes it harder to reason about programs, and I prefer the 'mostly pure' approach of ML languages to strict purity. For me OCaml or the ML family hit the sweet spot of language design. I will agree that the parallelism issue can be a problem.

Please tell me about the parallelism problem? I love that Haskell can auto-parallelize and is very safe. But, I'm ready to kick it to the curb over stupid lazyiness-induced memory explosions. But I'd be sad to go back to having to worry about threads and safety.

I'd love to give OCaml a go. Tell me why I'll end up disgruntled.

Re: Owl – An OCaml Numerical Library

#40
post #6

I looked at OCaml a few years back for scientific computing, but was turned off by the global lock GC for multithreading (similar to python). Anyone know if this has been changed yet? Edit: doesn't look like this has changed, but there's an effort at https://github.com/ocamllabs/ocaml-multicore that is slowly making progress

Does it matter a lot for this sort of application (which I assume is interactive data analysis)? I think if you're worried about performance then you want a back-end to map your computation out to a big cluster, no? Like, write OCaml, target hadoop would be the logical thing if you need HPC. Of course someone will have to write that compiler (not it). :P
Post reply on HN