Pet Bugs?

benreece asks: "During my few years as a programmer/developer I've come across some strange bugs. Recently I found that Microsoft's VB/VBScript(ASP) round function has problems (for example, 'round(82.845)' returns '82.84' instead of '82.85'). It took me an annoyingly long time to realize the problem wasn't mine. I'm wondering what other obscure, weird, and especially annoying bugs in languages/compilers/etc have frustrated other developers." Memorable bugs. Every developer has one. What were yours?

Comments

That's what round SHOULD do

[A nonymous Coward]

Round to the nearest even digit if the truncated value is .5 Otherwise there's a slight upward bias.

Re:I know, it's a feature.

[novas007]

I've had that problem before, but it's not what you think (i think). Do you use zsh? Some shells, including zsh, protect their prompt. So if you print a single line w/o a \n, the prompt overwrites it, and you never see it. I think that bash by default will just print the prompt after whatever it was you printed. Try piping it to less or something, and you'll see it IS actually there :)

beat a-round the bush

[Mr Z]

There is no "proper" way to reduce the precision of a number under all circumstances. Each method of rounding or truncating 0.5 has its own pitfalls:

• Round-to-even, aka. banker's rounding. This is probably the best, since it distributes errors uniformally so as to not cause a long-term average bias. It's also very expensive to calculate as compared to the alternatives.
• Round (pseudo)randomly. Add an infintesimally small random or pseudo random bias to numbers that end in 0.5. This has the same bias properties as round-to-even, but with less predictability. If the biasing function is just a simple hash of the other bits of the number, though, then at least it's deterministic.
• Round-towards-zero. (I believe this is sometimes called "unbiased rounding".) For numbers uniformally distributed around zero, this form of rounding tends to also have no long-term average bias. The average magnitude is biased, though, towards smaller magnitudes.
• Round-towards-plus-infinity. (aka. "rounding up", or sometimes just "rounding".) This is the rounding they usually teach you in grade school -- round 0.5 up. (At least, that's what they taught me until I got to high-school.)
• Round-towards-minus-infinity. (aka. "rounding down" or "truncation".) This is what you get when you always round down. Right-shifting 2s complement numbers (with sign extend) typically gives you this form of rounding. One nice side effect is that the bias is uniform and so can be made to cancel in some cases elsewhere in your calculation. This technique has the advantage of being the cheapest -- you just throw away bits.

So, as you can see, there's no right way per se. It just depends on what you're doing.

--Joe

Try the Mersenne Twister

[Wraithlyn]

Check out the Mersenne Twister, it's beautiful. Here's a couple points from that page:

• Far longer period and far higher order of equidistribution than any other implemented generators. (It is proved that the period is 2^19937-1, and 623-dimensional equidistribution property is assured.)
  
• Fast generation. (Although it depends on the system, it is reported that MT is sometimes faster than the standard ANSI-C library in a system with pipeline and cache memory.)
  
• Efficient use of the memory. (The implemented C-code mt19937.c consumes only 624 words of working area.)
  

There are implementations in C, Java, PHP, Fortran, Excel (I assume VBA) and probably others.

I only have experience with the Java impl, and it is very good. There are two classes, MersenneTwister, which is a true descendant of java.util.Random, and there is also a MersenneTwisterFast class, which does NOT inherit from Random (same public methods, and identical algorithm though), but clocks in at about twice the speed, due to tricks like avoidance of synchronization, and method inlining and finalizing.