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

21–30 of 80 posts

Re: Owl – OCaml Scientific Computing

#21

Post by yomly »

ernst_klim wrote: post #9
improbable22 wrote: post #6

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

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…

int32int64 boundaries deep in python models has cost my team many an hour in debugging

Re: Owl – OCaml Scientific Computing

#22

Post by srean »

yomly wrote: post #21
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…

int32 int64 boundaries deep in python models has cost my team many an hour in debugging

Ugh dont remind me, seems we are siblings in pain.

Re: Owl – OCaml Scientific Computing

#25

Post by ryanrhymes »

improbable22 wrote: post #6

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

A large part of benefits originate from OCaml language per se IMO. Owl inherits these advantages for free. E.g., taking advantage of various compiler backends so you can (almost) use the same code for both web backend and frontend if you are a full-stack developer.

From numerical lib designers' perspective, a holistic design (note which does not necessarily mean a monolithic lib) leads to a more coherent and consistent design (e.g. APIs), which makes a large software system easier to optimise and maintain. As a young and experimental system, Owl seems doing a quite decent job so far IMO.

However, from a (broad) users' perspective, being very honest, I never believe which one should replace which despite how much I love Owl myself. Each tool has own pros and cons deeply root in its internal design, depends on the language it uses, its design assumptions and goals. I think the choice of tools is really a matter of project requirements, coders' own skill, personal taste, management choice, as well as the context (i.e. what kind of apps you are going to build for whom and where).

liang

Re: Owl – OCaml Scientific Computing

#26

Post by seanmcdirmid »

pjmlp wrote: post #17
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…

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.

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

Re: Owl – OCaml Scientific Computing

#27

Post by chewbaxxa »

ernst_klim wrote: post #9
improbable22 wrote: post #6

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

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…

How do you deal with data you haven’t seen before? Importing a large csv for example where a lot of the data is the wrong type or the wrong format.

Re: Owl – OCaml Scientific Computing

#28

Post by marmaduke »

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…

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.

Re: Owl – OCaml Scientific Computing

#29

Post by srean »

marmaduke wrote: post #28
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…

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.

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

Re: Owl – OCaml Scientific Computing

#30

Post by pjmlp »

seanmcdirmid wrote: post #26
pjmlp wrote: post #17

Earlier quoted context omitted.

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.

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

JuliaPro IDE apparently has good completion, plus the language might be dynamic, but uses the same approach as Dylan regarding type inference, meaning although dynamic it infers possible types from context.

Plus there are always type annotations as well.

Post reply on HN