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.

82.84499

[Coward, Anonymous]

Floating point numbers have problems with precision, your computer can not store 82.845 in a floating point number so the number it stores is slightly less than 82.845 which VB correctly rounds to 82.84

From MSDN...

[bje2]

"When you convert a decimal value to an integer value, VBA rounds the number to an integer value. How it rounds depends on the value of the digit immediately to the right of the decimal place--digits less than 5 are rounded down, while digits greater than 5 are rounded up. If the digit is 5, then it's rounded down if the digit immediately to the left of the decimal place is even, and up if it's odd. When the digit to be rounded is a 5, the result is always an even integer." so, Ed is correct...the round function is working to the documentation...

Re:From MSDN...

[quigonn]

BTW: this "banker's rounding" as you call it is the method you learn rounding in school in Austria. That's why VBScript's behaviour seems pretty normal to me.

Re:Not a bug

[Asprin]

That's not a bug. It's a more accurate way to round off numbers. If you always round 5 up, that means you round 5 out of 9 numbers up, and 4 out of 9 numbers down. This can cause problems if you're rounding lots of numbers.

NO!!!!!!

Please don't take this as a flame, because I'm not upset with you, just the ignoramuses that came up with this scheme. This is a stupid way define ROUND(), and I disagree entirely with the justifiction because ROUND() has to be defined in the case that the digit is a zero, right?

In other words,
digits 0,1,2,3,4 get rounded DOWN
digits 5,6,7,8,9 get rounded UP

See - it's completely even without this odd/even cockamamie bullstuff. In fact, this definition of ROUND() throws off the statistics because it inappropriately weights the UP/DOWN results (either 50/50 or 60/40) based on info that is irrelevant to the ROUND() process.

It's like the people who coded this function never studied actual math and don't understand that the trivial case (zero) counts!

I'm sorry, I don't usually go off like this but when something this simple gets this fscked up, it really frosts my wheaties.

NT Backspace Bug

[rootmonkey]

One of my all time favorites. Just print too many backspaces and cause the window's machine to croak. Always a crowd pleaser. And the funny thing is it still works today in NT/XP ... Good details here

VS 6.0 getline() bug

[wunderhorn1]

One pretty annoying bug I've run into is that the getline() function which is part of Standard C++ Library doesn't return when you press Enter.

http://support.microsoft.com/default.aspx?scid=kb; EN-US;q240015

Now, I wasted a lot of time, but eventually confirmed on the web that this is a known bug in the Microsoft C++ library which has persisted from Visual Studio 5 into version 6.

Apparently, the Standard C++ Library used in both products was produced by Dinkumware and they, with their illustrious author/founder P. J. Plauger, were embroiled in a multi-year copyright dispute which made it impossible for them to debug (let alone update) the library. Most of the commenters online seemed to believe that this problem could not be solved and we had to wait for the copyright battle to be resolved (it has).

My impression is that Microsoft has elected not to provide an update to the library (which includes the STL) until the release of .NET.

"Collapse stories" in preferences

[devphil]

Will fix that for you.

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 :)

Re:Hidden slashdot discussions

[mcc]

Oh, crud, it's still there.. Yeah. Sorry. I didn't notice, but here it is: the several active discussions page. These days it seems to mostly link to slashdot journals. Sorry, i somehow missed it when i was writing the parent post. I feel dumb.

I really, really hope this is something that the /. crew doesn't mind me bringing attention to. I just think it's cool :)

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

Re:how 'bout HTML bugs?

[Quietust]

Actually, the current HTML spec (4.01) states that </TH>, </TD>, and </TR> are all optional.

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.