idbfs
idbfs on Hacker News
Cool! I had been thinking about trying this as well, after reading about the idea in one of Cosma Shalizi's notebooks [0]. I'd love to see how something like this performs when "trained" on a corpus the size of the web when given the same kind of computational resources used to train modern LLMs.
[0] http://bactra.org/notebooks/nn-attention-and-transformers.ht...
Worth noting that the release announcement was written by Eli Bendersky, of
https://eli.thegreenplace.net/ fame. It's a fantastic technical blog with literally decades of content.
The authors of these slides also wrote a well-regarded textbook, Engineering a Compiler.
About once a year I see a cool new programming font and decide to try it out. Then, shortly after, I invariably switch back to DejaVu Sans Mono.
I suspect that if I gave myself more time to acclimatize to the new font, I might even grow to prefer it. That, or perhaps DVSM is simply the perfect font for me.
I knew what this was going to be as soon as I saw "aux.h" in the screenshot.
Some years ago I was working on an embedded system that involved DisplayPort. For those unaware, DP's control channel is called AUX. One day, my new co-worker who used Windows asked me, who used Linux, why my AUX-related code wasn't checked in - which it most certainly was.
And that, folks, is how I learned about this absurd property of Windows that exists to this day.
I was wondering the same thing. It's either a horrible human-written article, or an impressive machine-written one.
A paper that changed my approach to designing state machines is "Statecharts: A Visual Formalism for Complex Systems" by Harel (
http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.p...).
Statecharts (also called hierarchical state machines) are essentially generalized state machines which allow for nesting and parallel composition of states. The 'nesting' part is my favourite, since it allows one to delegate event handling logic shared by multiple states to a 'parent' state, reducing code duplication.
The great thing about this paper is that you can glean most of its key ideas by just looking at the diagrams.
I'm not sure about Lua, but for Python it sounds like you may be interested in the "with" statement.
"Because USB keyboards don't support arbitrary numbers of keys being pressed at once."
There is actually nothing in the USB or HID specifications preventing USB keyboards from supporting n-key rollover (when using the report protocol -- keyboards using the boot protocol are limited to a 6-key rollover). The reason most don't is simply to reduce cost and complexity. A sufficiently motivated person could build a USB-compliant keyboard that supported an arbitrary number of simultaneoue keypresses, and some do (e.g. http://www.maxkeyboard.com/max-keyboard-nighthawk-x9-red-bac...).
10/Fifth: More people multiplies communication overhead exponentially, slows everything down. Company bogs down, becomes bad place to work.Warning: pedantic.
Adding people increases communication overhead quadratically, not exponentially. To see why, consider the complete graph on n vertices (people), K_n. The number of edges (lines of communication) in K_n is n(n-1)/2, i.e., proportional to n^2.
A nitpick: C has been able to achieve the same performance as Fortran since C99 introduced the "restrict" keyword.
Seconding the C++ Primer! I've been slowly working through it over the past year, and have found it to be outstanding.
Yes, you're right. Good point.
A simple, principled way of solving October's problem is to model it as a Markov chain with absorbing states (the "Finish" square, and the two invisible squares past it -- the two invisible squares are unnecessary as mentioned by jtsummers below), and compute the expected absorption time starting from the first square.
See e.g. http://en.wikipedia.org/wiki/Absorbing_Markov_chain
Two female image processing researchers recently used a picture of Fabio as a test image in a paper of theirs:
http://arxiv.org/abs/1202.6429
(Additional discussion at http://www.kitware.com/blog/home/post/246)
Personally, I'm all for the use of amusing (arousing?) test images, as long as they exhibit features that actually make for a good test image (a mix of flat and textured regions, sharp boundaries, etc.).
I was referring to the "mebi" prefix. I agree that, currently, the old SI prefixes have perhaps been made slightly more ambiguous due to the introduction of the new prefixes. It is my hope that the computing community will eventually reach the consensus that the SI prefixes refer only to powers of 10.
I agree that it looks odd. However, especially in applications like cryptography, I think that removing the ambiguity of "megabyte" (i.e. do we mean 10^6 or 2^20 bytes?) is worth the introduction of a new term.
To those giving serious replies: I'm quite sure (rather, I hope!) the parent is being sarcastic.