Dzugaru

Pretty much this. In the real world you have to deal with

- Too few labeled / garbage labeled data (70000 digits? How about only 1000 complex class objects?)

- Obscure bugs in custom implementation (yeah my custom layer works and gradient is correct... or wait why it diverges after 10k iteration? hmm).

- Timing/RAM constraints (it should segment an image under 10ms on Jetson TX1, well, good luck with GoogLeNet)

Even if you develop an "intuition" for known tasks (like classification) - there are so many problems that are not tackled yet and no one has any "intuition" yet. Common sense very often doesn't work there (in high-dimensional spaces ;)).

For example I've only recently stumbled upon an "Explaining and harnessing adversarial examples" article - and that completely changed my perception about my current work in computer vision.

Don't know about Haskell, but what really got me (a long time CSharp programmer) into functional programming was this awesome site [1] (and a man behind it with his awesome talks) - which is focused on core aspects of FP (applicable in most languages nowadays) in real-world applications.

[1] https://fsharpforfunandprofit.com/

Well, I meant that being outnumbered easily can be an advantage - (ex. you're unique, noticeable etc.), that's why "despite being outnumbered" sounds really strange. "Despite facing barriers" - ok.

Not saying that those statistics can be heavily biased due to imbalanced classes - but other commenters already mentioned that multiple times.

> despite still being heavily outnumbered

Despite?

Not every programmer likes to share his side-project code on public places like GitHub - for many reasons. Or pullrequest to some opensource mess. Code you write and problems you solve at work usually can't be shown on GitHub either.

So, this "show me your GitHub" thing for me is no different from "show me your Facebook, wait what, no FB account??" experience with non-technical HRs ;)

Conventional resume is totally OK for a first step in recruitment, I don't understand the need for extra fanfare.

Well yeah, but this assumes I don't know the fact the physical access had place and proceed to enter the passphrase revealing the key unawaringly afterwards. If this is what "having physical access" means - then yes, I agree, game over, and ORWL solves it.

But if I know the attack took place (FBI broke into my house, the computer is locked in a safe etc.) - the data should be secure.

> If someone has physical access to your computer with secure documents present, it’s game over!

Err, why? Is AES encryption not sufficient? And the key is secure in my head - not something someone could steal.

So, why is this even a thing?

Who even needs this on Mac or Windows? iOS/Android/WP is what is needed.

She was just trying to be friendly...

Have yet to see an illustration that grasps multichannel convolution filters (MCCF) concept clearly. Why those channel stack size keep growing? How are they actually connected?

The thing that each conv filter consists of kernels in multiple channels (that's why first layer filter visualisations are colored btw - color image is a "3-dimensional" image) - and we convolve each kernel with corresponding input channel, then sum (that's the key) the responses. Then having multiple MCCF (usually more at each layer) yields a new multi-channel image (say, 16 channels) and we apply new set of (say, 32) 16-channeled MCCFs to it (which we cannot visualise by themselves anymore, we need a 16-dimensional image for each filter) yielding 32-channel image. That sort of thing is almost never explained properly.

Doesn't work when you like doing functional programming or similar activities ;)

HubPress app.js can do what it pleases with my github password, am I right? And I couldn't find non-minified sources easily.

P.S. found sources at dev.hubpress.io on another branch

> learn distributions from streaming data

That's unsupervised learning afaik - clustering, manifolds etc. Where is "reinforcement" part there (agent, environment, reward)?

Used simple RL (finite states, no neural nets) for gamedev - finding optimal policies for player behavior helps in fixing balance issues.

Anyways...

Part of ffmpeg open-source library

http://www.ffmpeg.org/~michael/ffv1.html

Ah, my bad. Disregard everything :)

---

Awesome, thanks!

That's an impressive thing you do.

Can't find if you're using GPGPU for (maybe some simple, but not complex?) workers or not?

> which was never done

Highly doubt that.

Oh, and when I see a phrase "millions of things interacting" and don't see a word "GPU" anywhere I feel strange. Just saying.

Interesting, would like to see comparison with FFV1. Arithmetic coding beats Huffman all day every day, and pixel-aware predictors are a thing.

> Telegram is one of my bets on a good, sane messaging platform for the future

Why? It was made by VK (russian Facebook) devs and there are many concerns about its security.

If you ask me about ML I'll say that starting with convolutional nets for images is starting on the wrong side (end instead of beginning). Andrew Ng course is better, but still somewhat lacks theory and general ML insights.

I'd recommend new Coursera Washington University ML course (https://class.coursera.org/machlearning-001/lecture) as a solid foundation. You'll learn key ML concepts (bias vs variance, bayes theory etc.) and the lector is simply the best I've seen.

Following that Ian Goodfellow book http://www.deeplearningbook.org/ is very good.

If you want to learn foundations of Reinforcement Learning I'd recommend Sutton & Barto https://webdocs.cs.ualberta.ca/~sutton/book/ebook/the-book.h...

I'm not an expert in programming languages design and I've read about Etherium just a couple of days ago. But when I saw that "Solidity is like JavaScript and Python" - I was like "What? I'd pick some functional programming language for that!".

Wouldn't trust programmers, who make illogical graphs like that one :D

The whole point is - it's not about a concrete language (CUDA-C syntax is almost the same as C, you know). It's about the way of thinking and completely different parallel algorithms like Blelloch scan.

There is no compiler for any language, which can turn an arbitrary sequental algorithm into parallel, and will never be.

That's not "C is inefficient", it's "Sequental computation is inefficient". Want a lot of "number-crunching"? Learn CUDA (or similar non-hardware-locked thing). It's quite simple to get into and you can get orders of magnitude speed boost. Screw Fortran, it's 2016!