SymPy book

There’s a new book on SymPy, a Python library for symbolic math.

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.

History of weather prediction

I’ve just started reading Invisible in the Storm: The Role of Mathematics in Understanding Weather, ISBN 0691152721.

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.

Related posts

Three new Python books

This post reviews three Python books that have come out recently:

SciPy and NumPy (ISBN 1449305466) 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 (ISBN 1593274076) by Jason R. Briggs is an introduction to programming aimed at kids. It starts 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 for Developers

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 (ISBN 1449322700) 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.

Related posts

Late to the party

Learn You a Haskell for Great Good (ISBN 1593272839) 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 (ISBN 1613822707):

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.

Related posts

Henri Poincaré: A Scientific Biography

The first clue that Henri Poincaré: A Scientific Biography (ISBN 0691152713) 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.

George Boole, Claude Shannon, and information

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 books I have read.)

Nahin’s latest book is The Logician and the Engineer: How George Boole and Claude Shannon Created the Information Age (ISBN 0691151008). 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.

Other posts about Nahin’s books

Painting with Numbers

Painting with Numbers (ISBN 1118172574) is a new book of advice on making numerical presentations.

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.

  1. Not right-justifying a column of numbers.
  2. Basing column width or row height on the length of the caption.
  3. 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 …”