This will be short not because the book isn’t good, but because I’ve got too many irons in the fire.
Computer Organization and Design by Patterson | Hennessy is the gentle introduction to hardware. The math is simple and easy to understand, the book layout is excellent, and the content is outstanding. If you want an understanding of how computers work on the most fundamental level, this is your book.
In addition to the main book, be sure to read Online Appendix C: Graphics Cards. Most software engineers already have an intuitive idea of programming on a traditional CPU, but this approachable yet thorough appendix teaches graphics card architecture and the CUDA multithreading model. I can’t recommend it enough.
Engineering a Compiler is an excellent introductory text on compilers. I particularly enjoyed the textbook’s clean layout and design and cleanly written algorithms placed very close to the paragraphs where they are relevant.
Particularly after reading Muchnick, I found the amount of text explanation with a lack of concrete examples to be disturbing. Whole sections pass without any accompanying code examples. While I didn’t think that pseudocode would have particularly enriched these topics, and I could certainly look up the relevant papers provided in the bibliography, I found the lack of a concrete representation to work with left me somehow wanting more. This may trouble other readers less than it did myself.
All in all I suggest Engineering a Compiler as an excellent candidate for easy entry into a discussion on compilers, or an undergraduate text. After reading this textbook, if you’re still hungry for more on compilers, try Appel’s Compilers in ML and Muchnick’s Advanced Compiler Design and Implementation.
“Perilous to all are the devices of an art deeper than we possess ourselves.” – Gandalf the White
I have a monthly textbook budget of $200/month. For the last year, I’ve exclusively spent that on hardcopy Computer Science and Software Engineering textbooks. Whenever anyone catches me reading these eight hundred page beasts, they always ask the same question:
I’m already employed as a Software Engineer, and I’m not reading these books to earn an additional degree, moreover, these books can’t be fun to read, so why would I spend time doing this when I could be smelling the roses or whatever normal people do with their spare time.
In the following thousand or so words, I’ll do my best to answer that question.
In the last two installments of this series, I showed how we can use Haskell to define a dynamically-sized single-threaded Neural Network and explained things along the way. So yay! We’ve got a Neural Network! Great!
But now that we’ve got it, what in the heck do we do with it? Find out after the cut.
When I set out to design a neural network for this project, I knew very little about neural networks, artificial intelligence, or anything along those lines, and so I can’t say that I chose as I did out of any deep knowledge — what I can say is that a coworker told me that a fully-connected feed forward neural network is easy to implement.
Software Engineering is a constant fight against added, unnecessary complexity so yeah, simplicity, let’s go with that!
So… what’s a fully-connected feed forward neural network and how do I build one?