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...

[Harik]

Yea, as does every financial system in the world.

Even PHP round() uses odd/even to deal with halves. It's just the Right Way.

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:From MSDN...

[Anonymous Coward]

"If you're trying to find the difference of a series of numbers", THEN WHY ARE YOU ROUNDING THEM FIRST?

microft DLL unloading

[mojorisin67_71]

This was on NT.

While exiting the program, Microsft
was unloading the socket DLL before DLL's we had
created. This caused our program to always crash
on exit.

It was obvious due to some internal DLL dependencies,
NT was choosing a random order
to unload DLLs.

We spent months trying to fight with Microsoft,
but could not get a solution. In the end
we decided not to support NT as a platform ;-).

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:OpenGL Matrix Stack

[Dasein]

Actually, your OpenGL implementation is supposed to give you and error back. You have to call glGetError() to get it. In this case it should return GL_STACK_OVERFLOW.

I know first hand that this works under WindowsXP with the nVidia drivers. Not that the drivers should have anything to do with it.

As an aside, you should call glGetError() in a loop. There may be multiple errors waiting.

So either you had a broken OpenGL implementation or just forgot to call glGetError(). Anyway, just thought I'd point out that this isn't a generic OpenGL problem.

Re:1 != 1 (precision)

[bmwm3nut]

this is a very common issue when working with floating points. you should never check to see if two floating points are equal, unless you mean equal to all precicion. a much quicker way than using sprintf is this:

#define EPSILON 1e-6 //or what ever tolerance you want

float x,y
//do stuff with x and y

if (fabs(x-y)<EPSILON)
{
//x and y are equal
}
else
{
//x and y are unequal
}

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:spelling of functions

[tomhudson]

I remember how Computer Associates had both color and colour in their clipper include files, so you could use either one.

I thought it was pretty neat.

On the other hand, in c you could have just done the following:

#define colour color

another useful shortcut is to do this:

#define str chr* #define strs chr**

int main(int argc, strs argv, str env)

helps remove a few bugs from code you write.

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.

Re:When comments are more than comments...

[jeffy124]

this is a guess...

the back-slash \ at the end of the line indicates to the compiler that the following line is to be considered part of the current line, meaning the compiler (iirc, lexical analyzer) will translate the above to the following:

#include

// tom 7 was here - 1998 \typedef unsigned char uchar;
int something(uchar c);

or more precisely--

--preprocessed contents of stdio.h--
int something(uchar c);

so the "bug" (actually a compile-time error) is an undefined token 'uchar,' unless of course, uchar has a definition in stdio.

My Favortie Bug

[Type11]

Was having some really bizzare problems with our String class being used in a stl vector and ended up having to trace it into the RougeWave HP stl. It was in vector<_TypeT,_Allocator>::operator= (const vector<_TypeT,_Allocator>& __x)
below is the change for anyone who might have hit this or runs this setup. Hope it can help someone avoid it and all the time it wasted. Just love problems in the STL! *** are the two lines changed.

*** _C_end_of_storage = _C_finish = _C_start + __x.size();
}
else { // size() < _x.size() < capacity()
// advance this->end () first
*** _C_end_of_storage = _C_finish = _C_start + __x.size ();

Changed To:

*** _C_finish = _C_start + __x.size();
}
else { // size() < _x.size() < capacity()
// advance this->end () first

copy (__x.begin (), __x.begin () + size (), begin ());

// write past original value of this->end ()
uninitialized_copy (__x.begin () + size (), __x.end (),
begin () + size (),
_RWSTD_VALUE_ALLOC_CAST (*this));
}

*** _C_end_of_storage = _C_finish = _C_start + __x.size ();

This of course was becuase _C_end_of_storage should not have been set before the calling of size() as it would be incorrect.