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

Draft of OCaml Scientific Computing book

discuss.ocaml.org

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Draft of OCaml Scientific Computing book

#101

Post by gnufx »

TallGuyShort wrote: post #10

I've never encountered a real OCaml project or anyone who uses it in my career (same is true for Haskell). I have assumed these languages are a hobby for CS academics and get used for pet projects by their devotees. Not that that's bad - they're interesting and the ideas are cool. I would just be afraid of locking myself into an isolated ecosystem that it's hard to hire experienced people for. Is anyone on HN actuall…

An example of OCaml use in scientific computing is to derive the framework for the FFTW library, which is rather important. (No, the library isn't written in OCaml, as I've seen claimed.)

Re: Draft of OCaml Scientific Computing book

#102

Post by heavyset_go »

devmunchies wrote: post #54
rich_sasha wrote: post #35

I'm beginning to think of learning either OCaml or F# for data sciency-kind of things. Any points of comparison between those? Library ecosystem seems better on F#, but I must admit I'm somewhat wary of the behemoth that is .NET . What else should I consider?

Data science and interactive programming are actually the main focus of the next release of f#. Not saying it’s bad now, but Microsoft wants it to be a strong option in data workflows. https://devblogs.microsoft.com/dotnet/announcing-f-5-preview... I had originally been learning ocaml but switched to f# because it has much better tooling and more uses (e.g. better web server support since I use .net libs)

How much of F#, .net and its data science stack can be divorced from Windows?

Re: Draft of OCaml Scientific Computing book

#103

Post by gnufx »

smabie wrote: post #87

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

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.

Re: Draft of OCaml Scientific Computing book

#104

Post by cole-k »

srean wrote: post #73
cultus wrote: post #36

In my opinion, static languages don't bring a whole lot to the table with numerical math. There's not many types for one. You basically just use matrices and vectors of floats most of the time. What would really be a bigger deal is some limited dependent typing to avoid errors from mismatched array sizes. Until then though, Julia is a bit more practical choice for me.

These old papers might pique your interest Shape in Computing [ https://dl.acm.org/doi/10.1145/234528.234749 ] A Semantics for Shape [ https://www.sciencedirect.com/science/article/pii/0167642395... ] https://www.semanticscholar.org/paper/The-FISh-language-defi... https://link.springer.com/article/10.1007/s100090050037 The page for FiSH used to be online. I cant find it now.

This sort of thing (if I understand the abstracts correctly) can also be done with dependent types: https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/a....

This paper was my introduction to dependent typing, so if you have a little Haskell background, you should be able to grok its gist too.

Re: Draft of OCaml Scientific Computing book

#105

Post by smabie »

gnufx wrote: post #103
smabie wrote: post #87

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

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.

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.

Re: Draft of OCaml Scientific Computing book

#106

Post by smabie »

brmgb wrote: post #99
smabie wrote: post #83

Earlier quoted context omitted.

I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala. I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong. I've said this befor…

> I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml. The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the…

You're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits.

All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing.

All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behavior.

For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes.

You gotta admit there's something just really awesome about that.

Re: Draft of OCaml Scientific Computing book

#107

Post by centimeter »

brmgb wrote: post #97
centimeter wrote: post #81

Earlier quoted context omitted.

As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostly to do with some aspects of the module system and polymorphic variants. I strongly believe Haskell is: * More production ready (including insanely good multithreading - probably the best of any language except perhaps Erlang) * Better for learning - there are…

I see the Haskell community offensive on OCaml is still going strong. Having worked with both, I really like using OCaml but avoid Haskell like the plague. Being lazy by default makes it very difficult to reason about Haskell performance really fast. Admittedly another benefit of using OCaml is that you don't have to deal with the Haskell community and its obsession with looking smart. From experience, OCaml users te…

I'm not part of "the Haskell community", just a random hobbyist. You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist.

> Being lazy by default makes it very difficult to reason about Haskell performance really fast.

I think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all.

> practical matters like, you know, building softwares rather than lenses library.

This is the classic completely idiotic "haskell isn't practical" argument. Let me tell you what's not practical: not having multithreading. Not having a well-functioning asynchronous programming system (Async sucks).

Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness.

Re: Draft of OCaml Scientific Computing book

#108

Post by centimeter »

smabie wrote: post #83
centimeter wrote: post #81

Earlier quoted context omitted.

As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostly to do with some aspects of the module system and polymorphic variants. I strongly believe Haskell is: * More production ready (including insanely good multithreading - probably the best of any language except perhaps Erlang) * Better for learning - there are…

I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala. I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong. I've said this befor…

> Of course I guess I could use unsafePerformIO everywhere

I don't understand comments like this. This is obviously not something that Haskellers actually do, so the simplest conclusion (or, it seemed simplest to me starting Haskell) is that thinking this is necessary is simply indicative of not understanding how to program functionally/monadically. Indeed, once you figure out Haskell idioms this isn't ever an issue.

You might also say that OCaml suffers from using unsafePerformIO everywhere, all the time.

> modular implicits would be a game changer for OCaml.

They would be very nice!

Re: Draft of OCaml Scientific Computing book

#109

Post by brmgb »

smabie wrote: post #106
brmgb wrote: post #99

Earlier quoted context omitted.

> I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml. The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the…

You're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits. All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing. All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behav…

> For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes.

But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explicit) in its intent.

Re: Draft of OCaml Scientific Computing book

#110

Post by smabie »

brmgb wrote: post #109
smabie wrote: post #106

Earlier quoted context omitted.

You're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits. All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing. All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behav…

> For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explic…

But what if you're doing a bunch of category theory stuff? Passing in the right monoid or whatever to every function is such a drag. Alternatively using local open is also a drag.

Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful.

Not sure how it came to be that everyone totally ignores it.

Post reply on HN