Singular Value Consulting

Books

The book is Instant SymPy Starter by Ronan Lamy. As far as I know, this is the only book just on SymPy. It’s only about 50 pages, which is nice. It’s not a replacement for the online documentation but just a quick start guide.

The online SymPy documentation is good, but I think it would be easier to start with this book. And although I’ve been using SymPy off and on for a while, I learned a few things from the book.

The subtitle may be a little misleading. There is a fair amount of math in the book, but the ratio of history to math is pretty high. You might say the book is more about the role of mathematicians than the role of mathematics. As Roger Penrose says on the back cover, the book has “illuminating descriptions and minimal technicality.”

Someone interested in weather prediction but without a strong math background would enjoy reading the book, though someone who knows more math will recognize some familiar names and theorems and will better appreciate how they fit into the narrative.

SciPy and NumPy by Eli Bressert is the smallest book I’ve seen from O’Reilly, aside from books in their pocket guide series. The SciPy and NumPy libraries are huge, and it can be hard to know where to start. This book gives a good, brisk overview. In addition to SciPy and NumPy, the it also gives a brief introduction to SciKit, in particular scikit-learn for machine learning and scikit-image for image processing.

(Eli told me that he is working on supplementary material for the book. Everyone who bought the book electronically will automatically receive the new material when it is available.)

Python for Kids by Jason R. Briggs is an introduction to programming aimed at kids. It starts with with an introduction to Python and moves to developing a simple game. It seems to me that kids would find the book interesting. It’s about seven times longer than the SciPy and NumPy book. It moves at a slow pace, has many illustrations, and has a casual tone.

NumPy Cookbook by Ival Idris contains around 70 small recipes, about three pages each. Many of these are about NumPy itself, but the book covers much more than its title would imply. Out of 10 chapters, four are strictly about NumPy. The first chapter of the book is about IPython. Another chapter is about “connecting NumPy with the rest of the world,” i.e. interfacing with Java, R, Matlab, and cloud services. Two chapters are devoted to profiling, debugging, and optimizing performance. There is a chapter on quality assurance (static analysis, unit testing, and documentation). And the final chapter is about Scikits and Pandas.

PowerShell was written first and foremost for Windows system administrators, and the benefits to this community are clear. It’s not as clear what developers should make of PowerShell.

Administrators can learn PowerShell as a shell first, and gradually transition from interactive use to scripting. They may learn PowerShell as their first programming language and not even give too much thought to the language per se. But a developer has to ask why and when to use PowerShell rather than another language, such as C#.

Doug Finke’s new book Windows PowerShell for Developers is “for developers” in a couple ways. First, the style of the book is geared toward developers. The book is small, less than 200 pages, because the author assumes the readers are experienced Windows developers who want to focus on what PowerShell adds to what they already know. Second, the book focuses on tasks a developer might want to do. Rather than show you how to create a new Active Directory user, as many PowerShell books would, this book covers topics such as

code generation

static analysis

interfacing with C#

embedding PowerShell in your application

working with XML and JSON

interfacing with Excel

creating DSLs.

So why should software developers use PowerShell? And what tasks should they do in PowerShell? One answer to the first question, implicit in the book’s examples, is that PowerShell makes it possible to carry out common tasks with little code. Another answer explicitly given in the book is integration.

Given PowerShell’s growing integration with the rest of the Windows platform, as PowerShell grows, so does your application.”

The book is full of examples of what tasks a developer might want to do in PowerShell. The examples I found most interesting were embedding PowerShell to provide a scripting language for your application and creating DSLs in PowerShell.

One pattern in the examples is text munging, whether that text is source code or common data file formats. Another pattern is integration, especially integrating Microsoft technologies. PowerShell is designed to make it possible to solve these kinds of problems with a minimum of ceremony.

I’ll close with a couple reasons why might a developer not want to use PowerShell in my opinion. The first is frequency of use. Although PowerShell can solve many problems with significantly less code than C# would require, you have to learn PowerShell first, and you have to use it frequently enough to remember it. You have to use PowerShell enough to repay the time invested in learning and practicing it.

The second reason is size. The C# language and the Visual Studio IDE were designed for large projects, but scale down fairly well for smaller projects. PowerShell was designed for the command line, but scales fairly well for large scripts. If you use PowerShell and C#, you’ll have to decide at what size you want to switch from one language to the other.

Learn You a Haskell for Great Good is a hard book to judge by its cover. It’s about the Haskell programming language, but what is it like? The title and the art work are playful, and that gives the impression the book is light-weight. On the other hand, the table of contents lists two chapters on monads, so maybe it isn’t so light-weight after all.

Is this book funny or serious? It’s both. It reminds me of a couple of my favorite lines from G. K. Chesterton’s Heretics:

Mr. McCabe thinks that I am not serious but only funny, because Mr. McCabe thinks funny is the opposite of serious. Funny is the opposite of not funny, and of nothing else.

I’m not going to write a detailed review here because a lot of other people have reviewed it and I have only started reading it. Like I said in the title, I’m late to this party. But I’ve read enough that I think I understand why people recommend it. The book is written with a sense of humor and a casual pace, and yet it covers quite a bit. If you’ve looked at other Haskell books and found them too dry to read, as I have, you might want to try this one.

The first clue that Henri Poincaré: A Scientific Biography is not going to be a typical biography is in the table of contents. It lists one appendix on elliptic and Abelian functions and another on Maxwell’s equations. This is a biography of a mathematician that doesn’t shy away from math.

The subtitle is “a scientific biography” because the book is primarily about the work of Poincaré rather than his personal life. It has more to say about the three-body problem and algebraic topology, for example, than about Poincaré’s parents.

I haven’t seen a book like this before. I’ve seen books that are essentially collections of scholarly papers with biographical footnotes. And at the other extreme I’ve seen biographies practically devoid of scientific details. But I don’t remember seeing a biography that unapologetically includes substantial scientific content in the course of telling the story of a scientist’s life.

Paul Nahin writes books that are somewhere between popular and academic. His books are popular, but not light reading. They tell a story, but they go into more detail than most popular books. (I haven’t read everything Nahin has written, but I’ve noticed this pattern in his booksIhaveread.)

Nahin’s latest book is The Logician and the Engineer: How George Boole and Claude Shannon Created the Information Age. The title may be a little misleading. The book includes brief biographies of Boole and Shannon, but it is more about the ideas of Boole and Shannon (and others) than about the lives of these men. It discusses logic and information theory, and contains a fair amount of history, but it is not a rigorous historical account. Nahin uses Boole and Shannon a device for writing his book, something like the way Douglas Hofstadter uses Gödel, Escher, and Bach in Gödel, Escher, Bach.

The Logician and the Engineer dives into logic and probability from the perspective of an electrical engineer. The book moves seamlessly between abstract mathematics and electronic circuits. You don’t need to know much about electronics before reading the book, but you will see how logic concepts correspond directly to hardware. This is the heart of the book, and it is well done.

The last chapter of the book quickly discusses thermodynamics, and quantum computing. You could say The Logician and the Engineer is a book about basic electrical engineering, sandwiched between a historical introduction and a view of the future.

The book is very elementary. It contains no math beyond arithmetic, and it focuses almost entirely on financial data in Excel spreadsheets. But it does have useful tips. A lot of presentations would be easier to understand if the presenter had read this book. Think of it as a sort of Tufte-lite.

One of the themes in the book is a list of 18 “deadly sins” of presentation. Here are the first three.

Not right-justifying a column of numbers.

Basing column width or row height on the length of the caption.

Using visual effects for any reason other than clarifying, distinguishing, or adding meaning to information.

I like #17: “I know most of you can’t read the numbers on this slide, but …”

The other day I read a terribly bland book by an author I’ve previously enjoyed. (I’d rather not name the book or the author.) The book was remarkably unremarkable.

It reminded me that even the best strike out now and then. You have to evaluate someone by their best work, not their worst. If someone produces one masterpiece and a dozen clunkers, then they’ve produced a masterpiece. And that puts them ahead of people who crank out nothing but inoffensive mediocrities.

I also thought about how the author is likely to make a lot of money off his terrible book. That’s oddly encouraging. Even when you put out a clunker, not everyone will think it’s a clunker. It’s not necessary to do great work in order to make money, though doing great work is more satisfying.

Now that we have Google, countless blogs, and Stack Overflow, why should anyone buy technical books? And why should anybody write them? Charles Petzold’s answer is that books provide a narrative in a way that the web cannot.

Books about programming have certainly become less essential over the past 15 years or so. …

The Web has demonstrated that it’s greatest strength is the accumulation of information from many sources, and providing links between related concepts. However, where the Web falls down is in presenting long narratives, and I think this is a problem. For thousands of years, human beings have learned not by accumulating facts, but by following a narrative — a story that forges a path through the forest of information rather than merely describing all the trees.

… Books — at least those that are written well — provide narratives that the Web does not. …

As I’m writing a book, my primary intent is not to regurgitate the documentation but to impose a narrative on the material. This narrative has to begin with the basics and gradually introduce more and more material with a pace that neither overwhelms nor bores the reader. A narrative is necessarily a single path, and I spend much time and effort coming up with a good one.

I completely agree. I love the kind of books Petzold is talking about. And by the way, a book with a dozen authors isn’t a real book in my opinion. I’m disappointed whenever I’m browsing a library and think I’ve found a book on something, only to realize I’ve found a stack of articles bound together with no narrative.

This afternoon I got a review copy of X and the City: Modeling Aspects of Urban Life by John A. Adam. It’s a book about mathematical model, taking all its examples from urban life: public transportation, growth, pollution, etc. I’ve only skimmed through the book so far, but it looks like most of the applications involve differential equations. Some depend on algebra or probability.

The book looks interesting. I hope to say more about the book once I’ve had a chance to read it. The examples are all short, so it may be any easy book to read a little at a time.

I also got a review copy of The Book of Inkscape today, and I’m expecting several other books soon. It may take a while to get through these since this is a busy time for me. When it rains, it pours.

I recently received review copies of two books by Benjamin Wardhaugh. Here I will discuss How to Read Historical Mathematics. The other book is his anthology of historical popular mathematics which I intend to review later.

Here is the key passage, located near the end of How to Read Historical Mathematics, for identifying the author’s perspective.

But not all historical mathematics is significant. And perhaps there is a second kind of significance, where something can be historically significant without being mathematically significant. Some historians (I’m one of them) delight in investigating mathematical writing that contains little or no important or novel mathematics: popular textbooks, self-instruction manuals, … or old almanacs and popular magazines with mathematical news or puzzles in them. These kinds of writing … are certainly significant for a historian who wants to know about popular experiences of mathematics. But they’re not significant in the sense of containing significant mathematics.

Wardhaugh’s perspective is valuable, though it is not one that I share. My interest in historical math is more on the development of the mathematical ideas rather than their social context. I’m interested, for example, in discovering the concrete problems that motivated mathematics that has become more abstract and formal.

I was hoping for something more along the lines of a mapping from historical definitions and notations to their modern counterparts. This book contains a little of that, but it focuses more on how to read historical mathematics as a historian rather than as a mathematician. However, if you are interested in more of the social angle, the book has many good suggestions (and even exercises) for exploring the larger context of historical mathematical writing.

One of my friends mentioned his “simmer reading” yesterday. It was a typo — he meant to say “summer” — but a simmer reading list is interesting.

Simmer reading makes me think of a book that stays on your nightstand as other books come and go, like a pot left to simmer on the back burner of a stove. It’s a book you read a little at a time, maybe out of order, not something you’re trying to finish like a project.