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?

Re:That's what round SHOULD do

[Ed Avis]

I guess it depends on the documented behaviour of VB's round function. Anyone brave enough to wade through MSDN for it?

Re:From MSDN...

[pclminion]

They haven't changed anything. I was taught to round this way in the first science class I ever took. Scientists have rounded this way for at least a hundred years.

And it's for good reason: 2.5 is NOT closer to 3 than to 2. Neither 2 or 3 should be preferred, but we have to choose SOMETHING. Therefore the compromise is to round down when the rounding point is an even digit, and round up when it is odd. In the long run this cancels out the upwardly-drifting rounding error. You still introduce error (you're ROUNDING), but that error is equally distributed high and low, so the AVERAGE error is zero. The easy way to remember this is, when rounding off a 5, the result will always be even.

Also, the rint(), rintl(), and rintf() functions in glibc also round in this way.

Wrong, wrong, wrong, wrong, wrong.

[Erris]

Let me draw you a picture to agree with what you remember from grade school:

01234|56789

Suppose you wanted to round a fraction between zero and one. You can see that there are 5 digits on each side of the line and therefore equal divisions on each side. If you round 5 down you will get the wrong results.

Re:Wrong, wrong, wrong, wrong, wrong.

[cheezedawg]

Your argument would be right if you rounded 0.5 up to 0.9, but you don't. So it looks like this:

01234|5|67890

.5 is just as close to 1.0 as it is to 0.0

Two days to deadline, lets add some security…

[Saggi]

Based on a true story!

A few years ago I was working as the lead programmer on a cd-rom game. Two days before deadline, the manager of the project decided that we should implement a copy protection.

Now you can see where it is going... right?

Well the manager had talked to the company who was going to print the cd-roms. They had this piece of software that would protect the system. All we had to do was to write a component that needed to be called in order to start the game. If this component weren't called at first the game wouldn't start. We thought about it for some time. As we only had two days, we decided to let the component write down an encoded string, based on the current date to the harddisk, and then inside the game, well hidden read the string and match the date. As I have coded the game I made the part inside the game, while an other developer made the start-up component. I designed the specification of the coded string. It contained a lot of crap, and well hidden, the two digits indicating the day.

Now I coded my part in such a way that it would work 4 days after the date. (Allowing me to more easily bypass midnight at the end of the month - especially February). This would hopefully also put off hackers, as the game would appear to be hacked, as the coded string would work for a few days.

We tested the system, especially the end of months, going from the 28-31st to the 1st. It was end of November, close to Christmas - therefore the hurry. Then the cd-roms went into print.

4 of December I received one of the first copies, just as the packages was prepared to be send out to the shops. I put it into the computer, and it failed... I tried again... and again. The way the program terminated looked subspecialty like the protection, so I started to look closely into what was happening. It was the date. 4 of December were a single digit. The protection component wrote 40 while the game looked for 04... My fellow developer had misunderstood the specifications. Of cause testing for 31 would work... it was two digits.

We trashed all the cd-roms and made a new version without protection. Our manager will probably not ask us to do such a change with such short notice an other time.

A thought thou; The cd-roms would have worked on Christmas eve... its two digits, but a new year... he he he.

Re:From MSDN...

[Gaijinator]

I've heard this before (in Physics class) and I was dumbfounded for a minute. The reason, apparently, is so that it's not "biased", but rounding down when the digit is 5 and the preceding is even or up when it's odd is what biases the rounding. Let me explain mathematically: There are 10 digits [0-9], and [0-4] rounds down, while [5-9] rounds up. That means there are 5 digits that will round down and five that will round up, so there is statistically speaking a 50% chance of rounding either way, so in the long run, the numbers balance without the need for useless bias correction.

Re:That's what round SHOULD do

[yakovlev]

For purposes of this note real means in the mathematical sense and real-world means in the general sense.

From a statistical point of view, for real numbers, this is silly. (Integers or pseudo-integers are a different story.)

The set of all real numbers n where 2.5 is less than or equal to n is less than 3.5 is the exact same size as the set of all real numbers m where 2.5 is less than n is less than 3.5. It simply doesn't matter.

i.e., for any non-skewed real data set, x.5000... essentially never happens. If it happens more than once, this is a GROSS statistical aberration.

Of course, this isn't the way things work in the real-world, so I can see how this hack (and mathematically, it is a hack) helps for observed data sets where x.5000.... is quite common.

Stupid humans producing data sets skewed to already round numbers. :)

For integers and pseudo-integers this scheme for x.5000... numbers works great for preserving averages so long as the data set isn't skewed towards values that truncate to either odd or even numbers.

The problem with this version of rounding is that it is skewed towards producing too many even results (again on real-world or integer data sets only). This may or may not be significant depending on how it is used.

In all seriousness, random libs *suck*

[edremy]

random() only returns 666 if you use a demon seed!

My favorite "bugs" are the truly horrible random number functions in almost every single language library on earth. They're usually linear congruential generators: fast, but utterly useless for any work that requires serious "randomness" such as Monte Carlo simulations. They have very short recurrence times, strong sequential correlation, etc.

Back in grad school, I had to substitute the Knuth ran3 routine for the supplied C library functions in both gcc and xlc since they were just awful.

Fast forward 8 years. I made the stupid assumption that since Java was a new language and that horrible problems with random number generators were well known that Sun would actually provide a decent RNG. Nope: just as badly flawed as the C one.

I suspect this is simply something to give up tilting at windmills about: random() is good enough for simple games and anyone doing real work knows to stay the hell away.

Re:Not a bug

[avalys]

Zero is rounded down? I suppose that's true, in the same sense that ten is rounded up.

Re:Not a bug

[Anonymous Coward]

Your reasoning is correct for numbers drawn from a continuous distribution, but in life, we usually have some end to our decimal representation. This is where the rounding bias is introduced. The fewer places of accuracy before rounding, the bigger the bias.

Consider the case in which you only have one digit of precision to the right of the decimal. Consider the set {0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9}. If you sum these numbers, you get 4.5. If you round using your method and then sum, you get 5. If you round using the "round down when the whole number part is even" method, you get 4. Each method has the same amount of error.

Now consider the set {0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.6, 1.8, 1.9}. If you sum *these* numbers, you get 19. If you round using the "5 always goes up" method and sum, you get 20. If you round using the "round down when the whole number part is even" method and sum, you get 19. One of these methods is not biased...

Re:True story

[demastri]

Actually, the true VB bug is turning incompetent weenies into programmers...

Re:That's what round SHOULD do

[Anonymous Coward]

Balancing the number of times you "round up" with the number of times you "round down" isn't the point. In fact, the number of round-ups vs. round-downs is totally irrelevant.

What does matter in some applications is the average *distance* (not merely direction) that a number is rounded. "Banker's rounding" keeps that number close to zero; rounding .5 up causes it to drift forever upward. That's the bias in question.

As in all things, the "right tool" depends on the job to be done. Sometimes rounding .5 up is perfectly acceptable, such as when you're just rounding for presentation. When rounding for calculation, it's often important to use banker's rounding.

The point being, the round() function is documented to use banker's rounding, which is a valid and accepted standard method of rounding. So it is not a bug. They could have documented it to always round .5 up, in which case that behavior would not be a bug; but they didn't.

Oh, and we're all stunned by your amazing credentials. But I got over it and noticed that you're still wrong.