Jupyter, SymPy, and floating blocks

I had a few New Year’s resolutions related to Python:


1. conda instead of pip
2. Python 3 instead of 2
3. Jupyter notebooks instead of IPython console

Decreasing order of likelihood.

Dr. Drang (@drdrang) Dec 31 2015 4:22 PM

I’ve kept Resolution #1. I have Anaconda running on both of my Macs, and I’m using conda to install new libraries and keep the old ones up to date.

I’m behind on Resolution #2, although I do have a Python 3 environment installed on my iMac. I just haven’t gotten around to using it for anything other than a bit of testing here and there. Still, I have half the year left.

As for Resolution #3, my adoption of Jupyter notebooks has been slow, but I have been using them more frequently—mostly as a kind of scratchpad for my own reference than as something to distribute.

Missing from my list in December was a fourth resolution: to learn SymPy and use it when I need to do symbolic instead of numerical analysis. I know SymPy isn’t as powerful as dedicated symbolic math programs, but my needs for symbolic math are fairly modest. I just want to do elementary algebra and calculus without making sign errors and copying mistakes.

To get comfortable with any software, you need to use it frequently. Projects at work that are natural for Jupyter and SymPy have been sparse, so I’ve been casting about for interesting side analyses to develop my skills. A few days ago, Nathan Grigg tweeted a link to this page by Nick Berry. It’s an analysis of how a long block of wood with a square cross-section floats.


Nick’s analysis is largely numerical, and he has a fun simulation applet embedded in his page that lets you set the density of the block, drop it in the water, and watch it bob around until it comes to a stable equilibrium position. It’s a cute problem with some non-intuitive results, and I wanted to reproduce Nick’s results but to do it analytically instead of numerically. I started writing equations on paper and soon realized both that it was going to take several pages and that I was unlikely to get through it without making some careless algebraic bookkeeping error. A good opportunity to use SymPy in a Jupyter notebook.

Jupyter notebook for floating block

I’m not going to reproduce the work here, but I have created a static HTML page where you can see the results. If you’re a Jupyter user yourself, you can download a zip file with my original notebook (.ipynb) file and the graphics that go with it.

One thing I should mention: After I’d done most of the analysis, I found this set of hydrostatics course notes by Richard Fitzpatrick of the University of Texas. He solves the same problem—albeit using a different coordinate system than I do—and also provides a much richer background on the general problem of floating bodies. I stole a variable substitution trick from him that simplified my analysis considerably.

Giving in and not giving in

The longer you use computers, the more set you become in the ways you use them and the more certain you are that your ways are the right ways. There are, of course, people who disagree with you. Normally, these disagreements result in nothing more serious than a good-natured flame war, and you can continue to use your computers the way you want. But sometimes the disagreement is with the people who make the hardware and software you use, and that’s when things get tricky.

The opinions of the people who make the products you use cannot be dismissed as easily as those of some randoid on Twitter. If they think you should doing things this way when you’ve spent years doing them that way, they can make it hard for you to stick to your guns.

If, for example, you’re an iOS user who prefers to use a third-party email client or calendar or web browser, there will be times when that preference gets is an obstacle to getting things done. You’ll take some seemingly innocent action, iOS will launch the standard app, and you’ll have to take several steps to extract yourself from it and switch over to the app you want. By which time, you may have forgotten what you were trying to do.

Is this extra friction worth the advantages you find in working with the third-party apps or should you just give in and use the Apple apps? At the moment, my answer is mixed. I’m using the standard mail, calendar, and browser apps, but I’m using Interact instead of Contacts.

Back when Apple overhauled the Mac’s user interface in OS X Lion, it changed the default way the scroll wheel worked. Lots of people hated it, and a cottage industry arose to explain how Apple didn’t know its ass from its elbow and how to go into Settings and change the scroll wheel back to the “better” way.

Mouse preferences

At first, I hated the new direction, too, and changed my Settings appropriately. But I preferred Apple’s default for scrolling on the trackpad, so for a short while I had a mouse on my iMac that worked one way and a trackpad on my MacBook Air that worked the other. That proved to be untenable, so after a week or so I bit the bullet and switched my mouse setting to what Apple wanted. It took a few days, but I adjusted. In this case, giving in was the path of least resistance.1

On the other hand, I’ve never capitulated to Apple’s desire to have me put my documents in the Documents folder. When I returned to the Mac after using Linux for several years, I brought with me a particular organization scheme for my work files: a “projects” folder in my home directory and within that a folder for each individual project. I had written a bunch of scripts for project management that relied on that structure, and I didn’t want to rewrite them.

Both Apple and third-party developers have tried to get me to use the Documents folder. It’s the default location for saving new documents when you launch an application for the first time, and some apps keep going back there even after you’ve continually saved your files to other locations. Luckily, the apps that refuse to let go of Documents are few and far between, and I was able to hold onto my preferred file and folder structure without much work.2

I don’t want to give the impression that Apple is the only software maker that tries to corral its users into certain habits. For past four years, Twitter has made it increasingly difficult for third-party Twitter clients to give their users the full Twitter experience. Twitter Cards and Twitter Polls, for example, are features available only in the official apps that I’d like to have access to, but whenever I try out the official apps the rest of the “full Twitter experience,” as it is currently defined, sends me back to Tweetbot (iOS and Mac) within a day or two. The corporate petulance that prevents me from seeing Instagram photos inline adds clicks to my day that I don’t want, and the nonlinear chronology of replies drives me batty.

So I haven’t given in to Twitter yet, but it’s pulling at me. I imagine that someday the features it offers will overwhelm the distaste I have for its design, and I’ll leave Tweetbot behind (with regrets).

I could give other examples of giving in (Apple Maps instead of Google Maps) and not giving in (switching my entire text editing workflow to BBEdit because I couldn’t handle the changes to TextMate 2), but you get the idea. If developers would just ask me what I want and do exactly that, the world would be a better place.

  1. Lion was also the release in which Apple killed the Save As… command in favor of Duplicate, a change that I thought I could adjust to but which still gives me fits. I’ve been meaning to write a post about that for months. ↩︎

  2. Recently, I put my projects folder into my Dropbox folder so I’d have access to all my work files more or less automatically. That move did force me to rewrite several scripts (which is why I didn’t do it earlier), but I did it anyway because the benefits outweighed the costs. Very different from moving files and folders into Documents. ↩︎

Worlds apart

Without any coordination, Erik Hess and Brent Simmons published posts today that spoke to the current state of blogging and its relationship to the “old days” of a decade ago. Individually, they’re both good posts, but they’re even better when you read them back-to-back.

Brent’s post was inspired by a brief conversation he had with Merlin Mann, which got him thinking about the open and decentralized web and the various tools that he and many, many other developers built for it. It was those tools that brought Merlin to the rest of us, back when talented writers—and, shortly thereafter, talented talkers—carved out their own little niches on the internet. They entertained and informed us, and they owned what they produced.

Now we’re in the world of Facebook, Twitter, YouTube, and Medium, where creators are more like sharecroppers than homesteaders. Erik’s post is about the tension between the old way of doing it yourself (using Brent-like tools, of course) in your own space, and the new way of just working on someone else’s platform. The platform raises you up so your voice travels farther, but the people listening associate what they’re hearing more with the platform than with you. Erik hopes to resolve the tension by maintaining his own domain, as he has for some time, while using Medium to amplify his words.

You could argue that platforms were important even in the old days. Lots of people didn’t have their own domains and were afraid of the hassles of configuring and maintaining their own places. So they hosted their sites on Blogger, Typepad, WordPress, and, a bit later, Tumblr. But the dream was always to have your own space on the internet, which is why these hosts emphasized things like customization and subdomains—they were trying to appeal to that desire for ownership.

I, of course, am stuck in the past, not willing to give up—or even share—the ownership of my words. Still clinging to a publishing model that may soon be as outdated as print. Erik’s hybrid system is probably the right way to accomodate the new realities while still maintaining control. But I’m not a fan of the new realities. I know the niche I’ve carved out is vanishingly small, but it’s all mine.

Final thoughts on switching from TextExpander

Back in April, I wrote a few posts on switching from TextExpander to Keyboard Maestro as my snippet expander (I was already using Keyboard Maestro for other things). Now that I have a couple of months of this new system under my belt, I thought it was worth a followup post.

I won’t recapitulate the changes in TextExpander that prompted me to make the change—you can read those old posts for that—other than to say that Smile’s later reduction in price for TextExpander didn’t persuade me to stay with it. I agree with Gabe’s sentiments, both before and after the price change.

Moving my TextExpander snippets to Keyboard Maestro was relatively painless, thanks to Ryan M’s excellent migration script. All the snippets that were either

made the transition flawlessly. The only snippets that had to be redone by hand were my date and time stamp snippets and those that used TextExpander’s fill-in feature.

The date and time snippets were easy to rewrite. Keyboard Maestro uses ICU formatting strings instead of the more familiar (to me) strftime-inspired formatting codes in TextExpander, but it wasn’t hard to translate. And I had only a handful of them, anyway.

Keyboard Maestro time and date macros

Snippets that used fill-in fields were rewritten to make use of Keyboard Maestro’s Prompt for User Input action to save a string to a variable that’s later included in the text output.

User input prompt

Prompt dialog

There are pros and cons to this approach. TextExpander’s fill-ins have the advantage of letting you see your input in the context of the rest of the snippet, but Keyboard Maestro’s prompt dialog is more compact, especially when the snippet as a whole includes a lot of boilerplate text with only a few variable parts.

I’ve found no significant difference in using Keyboard Maestro instead of TextExpander. I don’t have hundreds or thousands of snippets, only dozens, so I haven’t run into any of the problems Peter Lewis, Keyboard Maestro’s developer, has warned about. The snippet expansion is plenty speedy for me.

There’s no question, though, that TextExpander is distinctly faster at making new text-only snippets, mainly because it has special commands for doing so. Since I don’t make new snippets very often, this isn’t an important consideration for me, but it might be for you.

I did, by the way, investigate both TypeIt4Me (which I used many years ago) and Typinator as TextExpander substitutes instead of Keyboard Maestro. I didn’t find either of them compelling. TypeIt4Me allows AppleScript snippets but not shell/Python/Perl/Ruby snippets, so it was easy for me to dismiss. Typinator allows all those types of snippet, but it won’t import script snippets from TextExpander (at least I couldn’t get it to do so). Given how important my script snippets are to me, that was a black mark against it. And another reason to appreciate Ryan M’s fine work.

Overall, the switch from TextExpander to Keyboard Maestro has gone much better than I’d expected. Because of Keyboard Maestro’s superior programming features, I’ve found myself creating new snippets that are more complex and capable than I could ever make in TextExpander. I’m happy with the change and don’t expect to go back.