I would never put KMP and Coppersmith-Winograd into same place in terms of practicality.
KMP gives you very good and fast results on some data (especially data with repeated sequences). Coppersmith-Winograd (and even Strassen) will never be practical on any reasonable data we will see in near future (http://www.ics.uci.edu/~fastmm/FMM-Reference/paoloA.ishp-vi....)
There is no reason to implement fibonacci heap for Dijkstra.
Either you have relatively small data (up to 10 mil. nodes and edges) and normal heap is a way faster or you have bigger data and you should start thinking about things like A* where fibonacci heap is again useless.
You should note, that log n factor is so small (up to 40 on the biggest data you will ever see), that it can be easily dominated by other constant factors in implementation (like cache locality, ...).
Why would you not use A* from the beginning? It's a trivial extension to Dijkstras and is often orders of magnitude faster when an informative heuristic is available.
Also, both algorithms require identical data structures. After all, Dijkstras is just A* with a zero heuristic.
I do agree about the constant factor, though: it's likely that a binary heap would be faster on most data sets.
"2) it demystifies machine learning -- you have to write your ML from scratch, without the help of all those wonderful Python libs, and I think this exercise shows you that it's not so mysterious after all." - you can demystify machine learning in any better language.
JS and PHP are slow, crappy and bug prone. Sane languages (like Python, C++) have tools to make your job easier (like numpy, blas, eigen and other libraries). They provide fast and reliable math routines so you don't have to worry about some eigenvalue decomposition, matrix multiplication and other problems.
I'm not sure I understand the point you're trying to make. Are you telling me I should not have written this series? That it's somehow not valuable because you don't like JS? That I can't effectively teach basic machine learning concepts to interested people without forcing linear algebra onto them? That, as a teacher, I can't try to use any and all tools and techniques available to the group I'm trying to teach?
I've even explicitly mentioned that I'm staying away from algorithms that rely on linear algebra, because I'm trying to bring these concepts to people who may not have a CS or mathematical background.
JS isn't particularly slow any more, thanks to the massive efforts invested in the optimization of the various competing JS engines. It is generally faster than Python 3 (http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...) and not just a little. Just for the hell of it I compared node and python on naive fibonacci. That is anecdotal, of course, but node is 30 times faster. I do agree with you that JS has horrid, bug-prone semantics, but it's impressively well optimized.
I also agree that other languages offer better tools. For instance, Python has Numpy. However, that's written in C++, not in Python. You can write plugins for Node in C++ too, so nothing would stop someone from writing a Numpy equivalent for JS. You might even be able to run it in some browsers through something like Emscripten with a performance overhead of 2-3x (I think?)
What are advantages of this thing against apache or nginx? Is it faster? Handles more concurent request? Or does it exists just for the sake of writing server in PHP?
One of the advantages obviously IS, that it will be faster than ngix (Apache is too slow to really compare it) because it allows you to hold objects persistent in memory what no other web server actually can. So we have Magento running within the application server, and had awesome performance improvements around 50 % (means about 100 ms for a category page instead of 150 ms on nginx). As it is multithreaded (not forked) AND faster, it also allows you to handle more concurrent requests.
But that is only one thing, because a application server, beside the web server (what is only one component and maybe will run behing a nginx that delivers static content like pictures, CSS or JS), provides you with additionally services like a message queue or a time service that will be very helpful in nearly any bigger PHP project.
A very interesting thing will be to combine appserver.io and HHVM to improve performance. If this will be possible, we think it will make the servlet container part of appserver.io for sure the fastest webserver available.
As the appserver.io is completely written in PHP it allows you and any other PHP developer to help fixing bugs or to improve it by adding new enhancements like HTTP 2.0 protocol in the future. With such a big community, like the PHP community is, we can be much faster to improve appserver.io than waiting for Apache or nginx to came up with new features. These are the main reasons why we think that PHP community should have their own application server for PHP written in pure PHP.
It's an application server, not a web server. You would run this behind a web server. E.g. web server takes HTTP request, distills information from the request and passes it on to the app server for processing.
Ehm. But sometimes stupid linux kernel prefers moving something usefull to swap and caching some shit instead of keeping stuff in ram and not doing caching.
So linux sometimes eats your RAM (but in different way).
