# Gas station without pumps

## 2012 June 8

### Reporting bugs in books and web sites

Filed under: home school — gasstationwithoutpumps @ 08:07
Tags: , , , , ,

Yesterday, while working problems in Chapter 12 of Matter and Interactions (about entropy and temperature),my son and I each found a bug.  The one I found was in the book, the one he found was in Wolfram Alpha.  I reported both of them to the respective sources.

Here is the exchange with Bruce Sherwood, one of the authors of Matter and Interactions.  Last night I wrote

I was doing the entropy calculations for 12.P.40 and decided to see if the number of states values were consistent.  I found that they were consistent with having 170 oscillators, which made the choice of 100 atoms seem strange to me.  What arrangement of atoms gives only 170 degrees of freedom for 100 atoms?

In just over an hour, Prof. Sherwood responded

Thanks! It’s clearly an error. And I note that with 170/3 = about 57 atoms, the per-atom heat capacity is about 2.8e-23 J/K, still less than the classical 3k_B limit, as is expected for the low temperature (about 113 K).

The simplest way to “fix” this would seem to be to say in part (c) that there are 57 atoms in this nanoparticle. Would you agree? You might be the only person in the world who has gone to the trouble to check whether the “100 atoms” made sense, though I would like to think we did a reality check on this in making up the problem but made a mistake.

While I’m pleased by how quickly he responds to my comments and that I apparently worked the problem correctly (all  this quantum mechanics is new to me), I’m a little disturbed by the assumption that I’m the only one checking my physics homework problems for consistency.  (Though since no one else has previously reported the problem to Prof. Sherwood, his assumption may well be correct.)

The problem my son found was in doing 12.P.48, which gives a mechanics problem that involves forces, rotating objects, and a brake.  The problem ends with a computation of how much the iron masses heat up as a result of the energy dissipated by the brake.  We  both used the $3 k_B$ high-temperature approximation of the atomic specific heat of Fe, getting a molar specific heat of about 25 J/(K mol), which should be fairly universal for simple solids at high temperature.  He looked up the specific heat of iron on Wolfram Alpha (his go-to source for numeric and mathematical information) and found that they had the molar specific heat as 251 J/(K mol).  He came to me for help, because he couldn’t find an error in his computation.  I suggested looking at some other references on the web.  They all had values around 25 J/(K mol), so I reported the apparent data entry error to Wolfram Alpha, suggesting that they should have done consistency checks on their molar specific heats.  I’m amazed that we seem to be the first ones to have caught this error—has no one ever used this entry in Wolfram Alpha’s database? Does no one do consistency checks on the data they find on the web? (I know that consistency checks on data entry are often done, but things slip through even well-designed data screens.)

So far all we have from Wolfram Alpha is the robomessage:

We appreciate your feedback regarding Wolfram|Alpha. The issue you reported has been passed along to our development team for review. Thank you for helping us improve Wolfram|Alpha.

But we can hardly expect commercial companies to work the sorts of hours that professors do, nor to admit to errors without piles of internal bureaucracy.

Of course, Wolfram Alpha is not the first web source whose information I’ve attempted to correct.  I have frequently sent Google Maps corrections on the bicycle routing information in Santa Cruz.  They usually respond in between 2 weeks and 2 months, and usually agree that I’m correct and claim to have fixed the problem.  About half the time they have fixed the problem, but one remains persistent—they keep sending bicyclists up the downhill-only leg of the bike path on the UCSC campus, though they have twice claimed to have fixed the problem.  The bike path is on a steep hill and is divided like a freeway, with the uphill path going around the hill and the downhill path going over the top and straight down.  Because the path is fairly narrow and downhill speeds exceed  35 mph, it is extremely dangerous to be routing bikes or pedestrians up the downhill path. The path is dangerous enough for downhill riders (I lost my spleen in a solo crash coming down that path in March 2000) without oncoming traffic.

I suspect that Google Maps has a database representation problem, lacking the ability to code a route as both one-way and bikes-only, so the fix may require more development work than the QA staff is authorized to do—that’s why I always check to see if it has really been fixed as they claim.  Their repeated reporting of the problem as fixed when it clearly is not indicates a serious management problem among Google Maps QA staff, who probably are evaluated on how many problems they clear, with no check for whether the problems are really resolved properly.