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

51–60 of 80 posts

Re: Owl – OCaml Scientific Computing

#51

Post by socialdemocrat »

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…

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

I don't think that has anything to do with static vs dynamic typing. I can do all of that in Julia which is a dynamically typed language. 1) I can start typing a function name and hit tab to complete it, or show matching alternatives with possible argument combinations and their types listed.

2) As I start typing arguments I can hit tab more times to see matching completions. The REPL will take into account the type of arguments I've already given when offering possible completion alternatives.

3) If I got a type, which I am not sure what I can do with I can write methodswith(sometype) to get a list of all functions taking an argument of type sometype.

4) Wonder if something works with dense, sparse, arrays etc? Check the function signature. Usually it will say AbstractArray and sparse matrix and dense matrix are subtypes of AbstractArrays. Not sure, you can quickly check that on the REPL by asking AbstractSparseArray Having said that I might want to check out Owl in the future. I have had a number of temporary engagements with statically typed functional languages. Haskell was interesting, but I found it to be impractical and too much of a time investment. OCaml may be more pragmatic, but it has often seemed a bit verbose to me.

Re: Owl – OCaml Scientific Computing

#52

Post by BeetleB »

ernst_klim wrote: post #7
krapht wrote: post #2

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.

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

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

Re: Owl – OCaml Scientific Computing

#53

Post by socialdemocrat »

o09rdk wrote: post #46
seanmcdirmid wrote: post #26

Earlier quoted context omitted.

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

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…

Julia does not have optional typing. Type annotations are used to specify what function implementation applies to a specific argument types.

E.g. if I write a function definition as foo(x::Int, y::String) that means that code is run whenever the first to arguments are Int and String. While if another definition is specified as foo(x::DateTime, y::Float64), means that this other definition applies to when the arguments are dates and floating point values.

Types are not used to improve performance. Rather they are a necessity to tell Julia what chunk of code should be run for particular types.

Often you use it to narrow down what types a function applies to. E.g. bar(x::Number) means bar function requires some sort of number. You cannot provide a string. However the compiler will not warn you if you use a string in a bar call. Instead you get an exception at runtime telling you there are no variants of bar, which takes string as argument.

Re: Owl – OCaml Scientific Computing

#54

Post by socialdemocrat »

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?

In Julia every function has a number of associated variants. We call them methods, not to be confused with methods in OOP.

So for every function there is a table of methods. Each method takes a different number of arguments or arguments with different types.

The REPL is able to introspect this table. So when you type a function name in Julia and hit tab, it will essentially dump this table. If you start filling in some arguments, it will use the types of those arguments to filter this table, showing you the only remaining choices.

You can even go in reverse. The function `methodswith` allows you to provide a type and Julia will search through the methods of every function to show every method accepting that type as one of its arguments.

Julia stores a lot of metadata with object and functions. You will be surprised how powerful this system is once you start using it. E.g. you can jump to the definition of a function, that was generated on the fly in a for loop. The function when created keeps track of what file and line number it was created, even if that happened through meta programming.

Re: Owl – OCaml Scientific Computing

#55

Post by srean »

metta2uall wrote: post #48
srean wrote: post #15

Earlier quoted context omitted.

> around existing .NET libraries. Which ones ? A free one analogous to libmath that works with float32 would be a good start. Am serious, would love to know of some .Net libraries for number crunching that one would miss if one were to move out of the .Net platform. Or did you mean non-numeric libraries ?

What about Math.NET?

Doesnt support float32

Re: Owl – OCaml Scientific Computing

#56

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

Re: Owl – OCaml Scientific Computing

#57

Post by ernst_klim »

BeetleB wrote: post #52
ernst_klim wrote: post #7

Earlier quoted context omitted.

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

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

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

Re: Owl – OCaml Scientific Computing

#58

Post by dmix »

socialdemocrat wrote: post #53
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…

Julia does not have optional typing. Type annotations are used to specify what function implementation applies to a specific argument types. E.g. if I write a function definition as foo(x::Int, y::String) that means that code is run whenever the first to arguments are Int and String. While if another definition is specified as foo(x::DateTime, y::Float64), means that this other definition applies to when the argument…

Multiple dispatch is so helpful when designing programs and interfaces. It’s one of the biggest things I miss from Erlang/Elixir when I’m using JS/Ruby, besides pattern matching and function guards.

Re: Owl – OCaml Scientific Computing

#59

Post by srean »

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.

Re: Owl – OCaml Scientific Computing

#60

Post by ska »

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…

A lot of those benefits are not direct properties of static typing. For example, common lisp(s) can have a very nice REPL experience like this. With numeric stuff you have probably typed the interface anyway, and your environment can interrogate that. I always liked CL for research code for this reason.
Post reply on HN