The width of the line separating the numbers is comparable to the width of the arrow-head. This ambiguity forces far too many re-spins (that's harder to simulate with Perl :).
Oh come on! (Width of line * number of lines) / ( 2 * pi * radius of arrow ) gives you a probability that a spin will land on a line. What's so hard about that? (I believe the width of the arrow point is irrelevant, or at least ignorable.)
Additionally, this ambiguity is a function of the person spinning the dial. My son claims he must re-spin when it is close and the number does not suit his needs!
So a per-player weighting factor needs to be applied to the above-mentioned probability. I will grant that assigning a "direction" to the weighting factor, based on the relative merits of two adjacent values on the dial, makes for a more challenging decision process.
I know... there's a certain degree of general fatigue induced by parenting young children, and this tends to limit the amount of time and effort that can be expended on purely geek pursuits. Been there, done that.