Live data from Hacker News

Deep learning experiments in OCaml

blog.janestreet.com

51–60 of 99 posts

Re: Deep learning experiments in OCaml

#51
I'm not convinced that functional programming will grow in terms of devs using it daily, but it has been very useful for myself in certain contexts (especially when I wrote math based libraries using permutations, heavy recursion, etc). The results of this seminar are awesome!

Re: Deep learning experiments in OCaml

#52

I had a very unpleasant interview regarding deep learning with Jane Street. I spoke to a member of their HR team to try to get significant assurances that the interview would actually be focused on deep learning and not puzzles or brain teasers, and that the job would really focus on deep learning for their actual business, and not just be a proxy for being generally smart and then work on whatever existing inhouse m…

I applied for a more entry level software position at Jane Street, and while I would have failed the interview regardless, I had the same experience where the HR person had no idea what the interview was like. They assured me I'd be required to write OCaml, so I spent the weekend brushing up, and that I should bring my own laptop prepared with whatever development I wanted to use. In fact it was a couple "whatever la…

I don’t know how long ago, but in my experience of interviewing with Jane Street (at least as an intern), they were pretty upfront about the lack of expected OCaml experience, and I was able to complete all of the on site interviews in a language of my choice. The HR/recruiting team seem eager to improve their process based on people’s feedback, so maybe this is something that took time to get right.

Re: Deep learning experiments in OCaml

#53

Earlier quoted context omitted.

> “Say someone wants to implement a deep learning model with complex valued activations or quaternion valued activations. What then?” This sounds like premature abstraction to me...

Premature abstraction is a problem for engineering. But what about scientists who are not too fussed with engineering considerations but would like to explore such things? Then this extensibility can be valuable.

At some point one of those explorations becomes useful and it's no longer premature.

Re: Deep learning experiments in OCaml

#54
post #52

Earlier quoted context omitted.

I applied for a more entry level software position at Jane Street, and while I would have failed the interview regardless, I had the same experience where the HR person had no idea what the interview was like. They assured me I'd be required to write OCaml, so I spent the weekend brushing up, and that I should bring my own laptop prepared with whatever development I wanted to use. In fact it was a couple "whatever la…

I don’t know how long ago, but in my experience of interviewing with Jane Street (at least as an intern), they were pretty upfront about the lack of expected OCaml experience, and I was able to complete all of the on site interviews in a language of my choice. The HR/recruiting team seem eager to improve their process based on people’s feedback, so maybe this is something that took time to get right.

I don't blame the engineers at all. I thought the questions were fair and not gimmicky, just unusually difficult. I failed because I was straight out of college and it was my second real interview ever. The only issue was that the HR person was very misinformed and put me a little off balance.

Re: Deep learning experiments in OCaml

#55
post #48

So much bashing on static typing on deep learning:) Does any one from Google can explain the benefit since you guys are working on swift in tensorflow https://medium.com/tensorflow/introducing-swift-for-tensorfl...

Static typing for catching errors is only a small part of the vision for Swift on TensorFlow. The real advantage of static typing is that it enables the compiler to reason to about your code, e.g., to automatically rewrite it for a hardware accelerator with guaranteed correct semantics: https://github.com/tensorflow/swift/blob/master/docs/DesignO... This is obviously possible in Python as well (e.g., see Numba) but i…

Thanks! that's a very interesting idea! Definitely worth exploring. Not sure it is my false sense. It seems that many python deep learning people are so proud of their chose, it is difficult to convince them.

Re: Deep learning experiments in OCaml

#56
post #52

Earlier quoted context omitted.

I don’t know how long ago, but in my experience of interviewing with Jane Street (at least as an intern), they were pretty upfront about the lack of expected OCaml experience, and I was able to complete all of the on site interviews in a language of my choice. The HR/recruiting team seem eager to improve their process based on people’s feedback, so maybe this is something that took time to get right.

I don't blame the engineers at all. I thought the questions were fair and not gimmicky, just unusually difficult. I failed because I was straight out of college and it was my second real interview ever. The only issue was that the HR person was very misinformed and put me a little off balance.

Yeah likewise I hadn’t done a many real interviews before this so I guess I have nothing really to compare it to. I ended up with entirely programming questions rather than generic brain teasers, so maybe there’s a bit of a mixture of questions asked.

Re: Deep learning experiments in OCaml

#57
post #48

So much bashing on static typing on deep learning:) Does any one from Google can explain the benefit since you guys are working on swift in tensorflow https://medium.com/tensorflow/introducing-swift-for-tensorfl...

Static typing for catching errors is only a small part of the vision for Swift on TensorFlow. The real advantage of static typing is that it enables the compiler to reason to about your code, e.g., to automatically rewrite it for a hardware accelerator with guaranteed correct semantics: https://github.com/tensorflow/swift/blob/master/docs/DesignO... This is obviously possible in Python as well (e.g., see Numba) but i…

Static typing has very little to do with what the compiler can say about your code. You can have dynamic languages with very strong type systems and semantics as well as static languages with weak semantics. The only difference between static and dynamic languages is whether the compiler enforces completeness of the analysis or not.

Re: Deep learning experiments in OCaml

#59
post #23
post #8

Earlier quoted context omitted.

The type safety argument is total BS. First of all the training script will fail for the very first time if there is a type error. You'd be a moron to pass an argument of a different type 'a couple of hours' into the training. No sane programmer writes such code. What kind of nonsensical argument is this. What I have found static typing to be really useful for is in remembering what I have coded. It's quite hard to r…

> You'd be a moron to pass an argument of a different type 'a couple of hours' into the training Huh?! At least in non-ML code this happens all the time, data fetched by whatever thinggie that uses zillion chained libraries of code nobody has time to audit, comes in hours or days late in a long running service blowing it up... eg. "oops, point.x is now no longer and integer but more like a map[ErrorObject->vector[int…

in some other nodejs code

ML/DL is nothing at all like webdev :-) but these days you can compile OCaml to JavaScript if you want, I encourage you to check it out

Re: Deep learning experiments in OCaml

#60

Earlier quoted context omitted.

Yeah except flux code is way simpler than tensorflow code, both for the end user and internally as well. It's not a premature optimization, it comes "for free" in Julia. Besides, you don't know what someone might need. Say someone wants to implement a deep learning model with complex valued activations or quaternion valued activations. What then? There is no complexity added in flux to support arbitrary datatypes; Ch…

> “Say someone wants to implement a deep learning model with complex valued activations or quaternion valued activations. What then?” This sounds like premature abstraction to me...

There is work on rotationally invariant networks, e.g. for identifying galaxies, or cells under a microscope. For example:

https://arxiv.org/abs/1612.04642

https://arxiv.org/abs/1805.12301

I haven't looked closely enough to be sure if they literally had complex activations, but this seems like an obvious use. Maybe they would have, if only tensorflow made it easy.

Post reply on HN