by John on October 30, 2009
Two links on naked mole rats and cancer
Three links on software development, academia, and industry
Four kinds of periodic tables
Five miscellaneous links
by John on October 30, 2009
You can express a Student-t distribution as a continuous mixture of normal distributions. Some properties of the t distribution are easier to prove in this form. Here are notes with details.
I ran across this tidbit reading Bayesian Data Analysis by Gelman et al.
Related post: Beer, Wine, and Statistics (origin of the Student-t distribution)
by John on October 30, 2009
by John on October 29, 2009
I was asking about backup software for Windows the other day and a couple people recommended Cobian Backup. It’s simple to use, but also very configurable. And it’s free.
You can have the software simply copy files or you can have it zip the output (.zip or .7z format). In either case, you don’t need the backup software in order to restore your files.
The software has all the features you’d expect. You can perform full, incremental, or differential backups. You can run backups manually or as scheduled tasks. Etc.
by John on October 27, 2009
Random number generators are challenging to test.
- The output is supposed to be unpredictable, so how do you know when the generator working correctly?
- Your tests will fail occasionally, but how do you decide whether they’re failing too often?
- What kinds of errors are most common when writing random number generation software?
These are some of the questions I address in Chapter 10 of Beautiful Testing.
The book is now in stock at Amazon. It is supposed to be in book stores by Friday. All profits from Beautiful Testing go to Nothing But Nets, a project to distribute anti-malarial bed nets.
by John on October 27, 2009
by John on October 25, 2009
The open source community has a saying: With enough eyes, all bugs are shallow. When enough people look at a piece of code, someone is going find and fix the bugs.
A related principle is that with enough users, all bugs will be reported. With enough people use the software, someone else is going to run into the problem. Someone will report it. Someone will talk about it in an online forum. Someone will blog about it and post a work-around until the bug is fixed. This principle deserves more attention; it’s not cited as often as the shallow bugs principle.
Ideally, you want to use software with lots of eyes and lots of users. Firefox is an open source product with lots eyes and lots of users. But more often you have to pick eyes or users. You have to choose between open but obscure software and closed but popular software. Open source projects may have more people looking at the source code, and so they have the “many eyes make shallow bugs” maxim working for them. But the user base for many open source projects is tiny compared to their commercial counterparts. The number of users to find and report bugs is small, and the number who document fixes and work-arounds is even smaller.
I’m not ideologically attached to open source or commercial software. I use both. I just want my software to work. And when it doesn’t work, I want to find a solution quickly.
Related posts:
Software profitability in the middle
Software that gets used
by John on October 25, 2009
How can we extend the idea of derivative so that more functions are differentiable? Why would we want to do so? How can we make sense of a delta “function” that isn’t really a function? We’ll answer these questions in this post.
[click to continue...]
by John on October 22, 2009
Here’s an interesting exercise. If you’re writing code in a language like C# or C++ that has catch statements, write a script to report all catch blocks. You might be surprised at what you find. Some questions to ask:
- Do catch blocks swallow exceptions and thus mask problems?
- Is information lost by catching an exception and throwing a new one?
- Are exceptions logged appropriately?
- Are notification messages grammatically correct and helpful?
Here’s a PowerShell script that will report all catch statements plus the five lines following the catch statement.
Related post:
Finding embarrassing and unhelpful error messages
by John on October 22, 2009
Here are some notes on upper and lower bounds on the probability P(Z > t) for a standard normal random random variable Z. I wrote up these notes to settle a issue that came up in a probability class I’m teaching. It’s surprising that there are simple functions that provide efficient bounds on the normal distribution function.
by John on October 20, 2009
I sold six technical books to a used book store on the way home today. The store paid me $5 total for four of the books. Two books they didn’t want at all. The books were not that old, but they were practically worthless.
It’s sobering to think how little a technical book is worth a few years after it is printed. It’s a good reminder to focus on things that will last.
Related posts:
Old math books
C. S. Lewis on reading old books
Mathematica turns 20
by John on October 20, 2009
I enjoyed listening to Moira Gunn’s interview with Kevin Maney, author of the new book Trade-Off: Why Some Things Catch On and Others Don’t.
The book was a little disappointing after listening to the interview. I felt I had heard most of what Maney had to say before I read the book.
In a nutshell, the message of the book is that you should either strive for fidelity (exclusivity, quality) or convenience (accessibility, affordability). You can succeed by excelling at fidelity or at convenience. But if you strive for both, you’ll lose to companies that are better at one criteria or the other. Maney gives several interesting examples of companies that have succeeded along the edges of the fidelity/convenience graph but then failed when they started pursuing the diagonal.
Related post:
I am not an operating system (how Microsoft and Apple are forced into their respective marketing positions)
by John on October 19, 2009
Parkinson’s Law says that work expands to the time allowed. I’ve seen that law play out over and over. However, I’ve also seen a sort of contraction to Parkinson’s Law. Sometimes work gets done faster when you have more time for it.
Sometimes when I’ve planned a large block of uninterrupted, say going into the office when hardly anyone else is there, I get through my to do list in the first hour of the day. Knowing that I have plenty of time, I think more clearly and end up not needing the extra time. When that happens, I sometimes think “If I’d known this would just take 30 minutes to solve, I would have done it sooner.” But it’s not that simple. Just because it took 30 minutes on a good day doesn’t mean that it could have been done during just any 30-minute time slot earlier.
In his book Symmetry and the Monster, Mark Ronan shares a story along these lines. Ronan tells how John Conway worked on a famous mathematical problem. Conway and his wife agreed that he would carve out Saturdays from noon to midnight and Wednesdays from 6 PM to midnight for working on this challenge. He started one Saturday and cracked the problem that evening. Perhaps Conway would have been able to solve his problem by working on it and hour at a time here and there. But it seems reasonable that having a large block of time, and knowing that other large blocks were scheduled, helped Conway think more clearly.
My guess is that Parkinson’s law applies best to projects involving several people and to one-person projects that are not well defined. But for well-defined projects, especially projects requiring creative problem solving, having more time might lead to not needing so much time.
Related posts:
Work expands to the time allowed
A 3,000 page proof (review of Symmetry and the Monster)
C-State and F-state
by John on October 16, 2009
