I installed a plug-in that I hope makes the blog easier to read on mobile devices.
So far I’ve heard it works well on the iPhone. As far as I can tell the plug-in doesn’t interfere with any desktop browsers. If you have any feedback, please let me know.
Here’s a screen shot of the home page from the Opera Mini Simulator:
Update: Here’s a screen shot of this post on an iPhone 3G thanks to Mpdreamz:
Related post: Styling HTML for mobile devices
The expression “_____ isn’t for everyone” can sound snobbish. For example, if someone says that their favorite wine isn’t for everyone, are they really saying that not everyone has the refined taste that they do? Or if they say their favorite author isn’t for everyone, are they really saying that not everyone is smart enough to appreciate the books they enjoy?
But sometimes the expression is used humbly, as in Brian Carper’s article Emacs isn’t for everyone. There are some arrogant Emacs users out there, but Brian isn’t one of them, at least not as far as I can tell by reading his article. He simply discusses some of the pros and cons of the software and explains why some people would be better served by another tool.
I hope you’ll keep reading even if you have no interest in Emacs. This isn’t a post about Emacs per se. It’s about some of the things the article made me think of.
The majority of software development articles either advocate the author’s tool of choice or complain about a tool the author is forced to use. (See Ford-Chevy arguments in tech for a possible explanation.) Articles that frankly discuss pros and cons are rare. Here’s a sentence from the article I particularly liked.
Mastering an arcane text editor isn’t necessarily going to be on the top of the list of everyone’s goals in life, especially when there are other editors that are easier to use and give you a significant subset of what Emacs would give you.
That’s a far cry from “Maybe you’re not smart enough to use Emacs.”
I also appreciated that the article wasn’t overly pragmatic. It wasn’t just a dry cost-benefit analysis. Brian explains
I didn’t learn Emacs with the goal of being productive. I learned it for the same reason some people build cars in their garages, while most people just buy a one and drive it to and from work every day. … For me, productivity was a beneficial side-effect.
Every once in a while you’ll see someone say they use a tool for fun. For instance, I’ve heard several people say they were burned out on programming until they discovered Perl or Ruby. But it’s far more common for someone to say “This made me more productive.” than to honestly admit “I enjoy tinkering with this.” The two probably go hand in hand: you’ll probably be more productive using a tool you enjoy tinkering with even if in some objective sense it’s inferior to another tool.
When we make one part of our lives safer, we tend to take more chances somewhere else. Psychologists call this tendency risk homeostasis.
One of the studies often cited to support the theory of risk homeostasis involved German cab drivers. Drivers in the experimental group were given cabs with anti-lock brakes while drivers in the control group were given cabs with conventional brakes. There was no difference in the rate of crashes between the two groups. The drivers who had better brakes drove less carefully.
Risk homeostasis may explain why dynamic programming languages such as Python aren’t as dangerous as critics suppose.
Advocates of statically typed programming languages argue that it is safer to have static type checking than to not have it. Would you rather the computer to catch some of your errors or not? I’d rather it catch some of my errors, thank you. But this argument assumes two things:
Advocates of dynamic programming languages have mostly focused on the first assumption. They argue that static typing requires so much extra programming effort that it is not worth the cost. I’d like to focus on the second assumption. Maybe the presence or absence of static typing changes programmer behavior.
Maybe a lack of static type checking scares dynamic language programmers into writing unit tests. Or to turn things around, perhaps static type checking lulls programmers into thinking they do not need unit tests. Maybe static type checking is like anti-lock brakes.
Nearly everyone would agree that static type checking does not eliminate the need for unit testing. Someone accustomed to working in a statically typed language might say “I know the compiler isn’t going to catch all my errors, but I’m glad that it catches some of them.” Static typing might not eliminate the need for unit testing, but it may diminish the motivation for unit testing. The lack of compile-time checking in dynamic languages may inspire developers to write more unit tests.
See Bruce Eckel’s article Strong Typing vs. Strong Testing for more discussion of the static typing and unit testing.
Update: I’m not knocking statically typed languages. I spend most of my coding time in such languages and I’m not advocating that we get rid of static typing in order to scare people into unit testing.
I wanted to address the question of what programmers do, not what they should do. In that sense, this post is more about psychology than software engineering. (Though I believe a large part of software engineering is in fact psychology as I’ve argued here.) Do programmers who work in dynamic languages write more tests? If so, does risk homeostasis help explain why?
Finally, I appreciate the value of unit testing. I’ve spent most of the last couple days writing unit tests. But there is a limit to the kinds of bugs that unit tests can catch. Unit tests are good at catching errors in code that has been written, but most errors come from code that should have been written but wasn’t. See Software sins of omission.
“The university’s ‘hidden curriculum’ … has always been teaching its own importance.” — Anya Kamenetz
C# has three mathematical constants that look like constants in the C header file float.h. Two of these are not what you might expect.
The constant double.MaxValue in C# looks like the constant DBL_MAX in C, and indeed it is. Both give the maximum finite value of a double, which is on the order of 10^308. This might lead you to believe that double.MinValue in C# is the same as DBL_MIN in C or that double.Epsilon in C# is the same as DBL_EPSILON. If so, you’re in for a surprise.
The constants DBL_MAX and double.MaxValue are the same because there is no ambiguity over what “max” means: the largest finite value of a double. But DBL_MIN and double.MinValue are different because they minimize over different ranges. The constant DBL_MIN is the smallest positive value of a normalized double. The constant double.MinValue in C# is the smallest (i.e. most negative) value of a double and is the negative of double.MaxValue. The difference between DBL_MIN and double.MinValue is approximately the difference between 10^-308 and -10^308, between a very small positive number and a very large negative number.
C has a constant DBL_EPSILON for the smallest positive double precision number x such that 1 + x does not equal 1 in machine precision. Typically a double has about 15 figures of precision, and so DBL_EPSILON is on the order of 10^-16. (For a more precise description, see Anatomy of a floating point number.)
You might expect double.Epsilon in C# corresponds to DBL_EPSILON in C. I did, until a unit test failed on some numerical code I was porting from C++ to C#. But in C# double.Epsilon is the smallest positive value a (denormalized) double can take. It is similar to DBL_MIN, except that double.Epsilon is the possible smallest value of a double, not requiring normalization. The constant DBL_MIN is on the order of 10^-308 while double.Epsilon is on the order of 10^-324 because it allows denormalized values. (See Anatomy of a floating point number for details of denormalized numbers.)
Incidentally, the C constants DBL_MAX, DBL_MIN, and DBL_EPSILON equal the return values of max, min, and epsilon for the C++ class numeric_limits<double>.
To summarize,
double.MaxValue in C# equals DBL_MAX in C.double.MinValue in C# equals -DBL_MAX in C.double.Epsilon is similar to DBL_MIN in C, but orders of magnitude smaller.DBL_EPSILON from C.One could argue that the C# names are better than the C names. It makes sense for double.MinValue to be the negative of double.MaxValue. But the use of Epsilon was a mistake. The term “epsilon” in numeric computing has long been established and is not limited to C. It would have been better if Microsoft had used the name MinPositiveValue to be more explicit and not conflict with established terminology.
This post will give several examples of functions include in the standard C math library that seem unnecessary at first glance.
The function log1p computes log(1 + x). How hard could this be to implement?
log(1 + x);
Done.
But wait. What if x is very small? If x is 10-16, for example, then on a typical system 1 + x = 1 because machine precision does not contain enough significant bits to distinguish 1 + x from 1. (For details, see Anatomy of a floating point number.) That means that the code log(1 + x) would first compute 1 + x, obtain 1, then compute log(1), and return 0. But log(1 + 10-16) ≈ 10-16. This means the absolute error is about 10-16 and the relative error is 100%. For values of x larger than 10-16 but still fairly small, the code log(1 + x) may not be completely inaccurate, but the relative error may still be unacceptably large.
Fortunately, this is an easy problem to fix. For small x, log(1 + x) is approximately x. So for very small arguments, just return x. For larger arguments, compute log(1 + x) directly. See details here.
Why does this matter? The absolute error is small, even if the code returns a zero for a non-zero answer. Isn’t that OK? Well, it might be. It depends on what you do next. If you add the result to a large number, then the relative error in the answer doesn’t matter. But if you multiply the result by a large number, your large relative error becomes a large absolute error as well.
Another function that may seem unnecessary is expm1. This function computes ex – 1. Why not just write this?
exp(x) - 1.0;
That’s fine for moderately large x. For very small values of x, exp(x) is close to 1, maybe so close to 1 that it actually equals 1 to machine precision. In that case, the code exp(x) - 1 will return 0 and result in 100% relative error. As before, for slightly larger values of x the naive code will not be entirely inaccurate, but it may be less accurate than needed. The solution is to compute exp(x) – 1 directly without first computing exp(x). The Taylor series for exp(x) is 1 + x + x2/2 … So for very small x, we could just return x for exp(x) – 1. Or for slightly larger x, we could return x + x2/2. (See details here.)
The C math library contains a pair of functions erf and erfc. The “c” stands for “complement” because erfc(x) = 1 – erf(x). The function erf(x) is known as the error function and is not trivial to implement. But why have a separate routine for erfc? Isn’t it trivial to implement once you have code for erf? For some values of x, yes, this is true. But if x is large, erf(x) is near 1, and the code 1 - erf(x) may return 0 when the result should be small but positive. As in the examples above, the naive implementation results in a complete loss of precision for some values and a partial loss of precision for other values.
The standard C math library has two functions related to the gamma function: tgamma that returns Γ(x) and lgamma that return log Γ(x). Why have both? Why can’t the latter just use the log of the former? The gamma function grows extremely quickly. For moderately large arguments, its value exceeds the capacity of a computer number. Sometimes you need these astronomically large numbers as intermediate results. Maybe you need a moderate-sized number that is the ratio of two very large numbers. (See an example here.) In such cases, you need to subtract lgamma values rather than take the ratio of tgamma values. (Why is the function called “tgamma” and not just “gamma”? See the last paragraph and first comment on this post.)
The standard C math library distills a lot of experience. Some of the functions may seem unnecessary, and so they are for some arguments. But for other arguments these functions are indispensable.
Yesterday I thought about adding a style sheet for mobile devices to some static HTML pages. How hard could it be? CSS has a media type. Just set the media to handheld, specify a style sheet for mobile browsers, and you’re done.
Style sheet media types
One problem is that hand-held devices don’t always look for the handheld style sheet. According to Ben Henick, the handheld media type is “poorly supported by all but the very recently marketed devices, as of 2009.” From what I gather, most websites try to infer the browser type on the server side and generate different HTML for mobile devices using PHP etc. Apparently static HTML markup will have its limitations at this point in time.
The iPhone doesn’t consider itself a hand-held device as far as CSS is concerned. Fair enough: perhaps the handheld designation is more for tiny screens like more traditional cell phones. But it’s not a desktop either.
You can’t target the iPhone with a simple media type, but you can use the following CSS.
<link rel="stylesheet" type="text/css" href="iphone.css"
media="only screen and (max-device-width: 480px)" />
Of course a device other than an iPhone could grab this style sheet, and the iPhone will not grab the style sheet if they ever add one more pixel to the browser width. But this is the approach Apple gives in their online documentation.
Testing
It’s difficult to find emulators to test how pages appear on mobile devices. Someone said on Stack Overflow that Opera has a Small Screen view that is useful for emulating mobile devices. However, that recommendation was from November 2008. The current version of Opera either no longer supports that feature or has moved it somewhere else.
The Web Developer plug-in for Firefox lets you specify whether you want to display your page with the screen or handheld style sheet, but it does not emulate a hand-held device.
Apple makes an emulator for the iPhone, but only for Macintosh computers. MobiOne makes an emulator for the iPhone that runs on Windows. However, the emulator does not recognize the CSS statement above. I don’t have an iPhone, but I was able to borrow an iPod Touch, which runs the same browser as the iPhone. My pages worked correctly on the iPod when they did not work on the MobiOne emulator.
Suggestions?
Does anyone have any suggestions for making static HTML pages more friendly to mobile browsers? Any suggestions for testing?
James Marcus Bach recalls the following from his seventh grade orientation.
At one point the grumpy man said, “We consider you to be young adults now, and we expect you to behave as such.” … No one would say that unless the opposite was true. I had a terrible sinking feeling.
If someone told me that he considered me an adult, I’d be dumbfounded. Of course I’m an adult. Why tell me that? We only say such a thing to manipulate children. Most children, however, do not catch the irony as Bach did.
Numerical libraries usually have a function for finding the hypotenuse of a right triangle. Isn’t this trivial? If the sides of a triangle are x and y, just write this:
sqrt(x*x + y*y)
That works in theory, but in practice it may fail. If x is so large that x*x overflows, the code will produce an infinite result.
We’d like to be able to say to the computer “Now x*x and y*y might be too big, but just wait a minute. I’m going to take a square root, and so the numbers will get smaller. I just need to borrow some extra range for a minute.” You can do something like that in environments that have extended precision, but that would be inefficient and unnecessary. And of course it would fail completely if you’re already using the largest numeric type available.
Here’s how to compute sqrt(x*x + y*y) without risking overflow.
Notice that the square root argument is between 1 and 2 and so there is no danger of overflow in taking the square root. The only way the algorithm could overflow is if the result itself is too large to represent. In that case the fault lies with the problem, not the algorithm: the algorithm was asked to compute a quantity larger than the largest representable number, and so it does the correct thing by overflowing and returning an infinite value. However, the algorithm will not unnecessarily return an infinite value due to an overflow in an intermediate computation.
To see how the algorithm above may succeed when the naive implementation would fail, let M be the largest representable number. For IEEE double precision, M is on the order of 10^308. All that matters for this example is that M is greater than 4. Let x and y equal 0.5 M. The algorithm above would return 0.707 M. But the naive algorithm would compute x*x and overflow since 0.25 M2 > M. Then x*x + y*y would evaluate to infinity and the square root would evaluate to infinity.
A hypotenuse function is included in math.h on every system that I am aware of. It may be named hypot or _hypot.
Thoughts from Tom Green on preparing students for innovation.
Today, many critics lament the lack of innovation in our society and draw the conclusion that more emphasis on teaching mathematics and science will lead to innovation. That will probably fail. Innovation comes from repeated successes in innovating. Innovation means trying ideas outside the accepted patterns. It means providing the opportunity to fail as a learning experience rather than as an embarrassment. … the traditional school powerfully suppresses any tendency toward being innovative. Both teachers and students are driven to conform.
From Bright Boys: The Making of Information Technology.