4

Recently I asked this question. As commented in the answer by someone who sounds like a numPy developer, this behavior is clearly not desired. The issue posted was closed stating that this is expected behavior but not a bug. Additionally there are plans to fix it.

What is the difference between a bug and behavior which is expected but not desired? Do those terms have precise and consistent definitions?

As a silly extreme, if a program always returns 3 when asked to compute 1+1, returning 3 is certainly expected behavior by the program since it has always worked that way, but it certainly isn't desired behavior, so is it a bug or not?

Recently I've been studying philosophy and this question has struck my interest.

migrated from stackoverflow.com Jan 27 '16 at 14:04

This question came from our site for professional and enthusiast programmers.

  • 3
    Expected but not desired behavior is a classy, erudite way of saying there's a software bug. – Gilbert Le Blanc Jan 27 '16 at 13:58
  • 3
    @gnat I don't see how that's relevant at all. – Thomas Owens Jan 27 '16 at 14:19
  • @ThomasOwens that's what I read in this question: "The issue posted was closed stating that this is expected behavior but not a bug. Additionally there are plans to fix it." – gnat Jan 27 '16 at 14:28
  • 1
    @GilbertLeBlanc: Expected but not desired could also be interpreted as "you did what I asked but what I asked wasn't actually what I wanted." – Blrfl Jan 27 '16 at 14:35
5

It is known as a wart.

From a comment on the original post on Stack Overflow,

To be clear, this is not desired behavior, although there are good (historical) reasons for it. We (numpy devs) have preliminary plans to deprecate it in a future release, and provide easier to understand functionality that works as you might expect. See http://github.com/numpy/numpy/pull/6256 for more details. -- Stephan

Every design decision is a trade off somewhere. Make something simpler somewhere, and somewhere else something may become more complicated.

Consider this bit of JavaScript:

>>> '5' + 3 - 3
50
>>> '5' - 3 + 3
5

Is that a bug? No. Is it desired behavior... eh... I don't want to say people want it to work that way, but that's what you get with the 'this is how it was decided + works.'

Or in ruby that x?2:3 is a syntax error (it needs to be x ?2:3 - notice the space). Why? Because it was decided functions may end in a ? and so x?2:3 is ambiguous - a space between the variable and the ? part of the ternary expression resolves that.

Or in PhP the decision to mimic Perl's auto-increment feature on Strings but lacking the restriction on the pattern leads to:

$foo = "3d8";
echo "$foo\n";
$foo++;
echo "$foo\n";
$foo++;
echo "$foo\n";
$foo++;
echo "$foo\n";

(ideone)
printing out:

3d8
3d9
3e0
4

And without too much difficulty one could probably find examples of design warts in libraries and languages across the entire spectrum of software that were made that had unintended that had unintended and possibly undesired but nonetheless expected behavior.

There were indeed (debatably) good historical reasons the design decisions to make it work a certain way. And the code works that way - its not a bug, it is working exactly as intended. With the benefit of hindsight, maybe those decisions weren't good and lead to undesired behavior, but the code is working as intended - there isn't a bug there, its a wart.

While I have listed a few warts that I can quickly show and tickle, there are countless ones out there. I really don't need more examples. I would frankly be surprised if one were to find a language or library that doesn't contain a wart.

  • That PHP example is a riot. – TMN Feb 2 '16 at 17:19
1

A "bug" is an informal term for a defect in software. It usually refers to something wrong in the code. If you want to use formal terms, you would want to use words like "error" (a human action or inaction that led to an incorrect result), "fault" or "defect" (an incorrect step, process, or definition), and "failure" (an incorrect result). An error will lead to a fault or defect that can manifest itself as a failure. This answer by dukeofgaming (along with other answers in that question) are a good explanation of the difference between defects, failures, and bugs.

These terms can be applied to more than just source code. For example, an error made in your requirements can manifest as a defect in your design. If a user sees this behavior, they may interpret it as a failure, even if your testing doesn't. Your software code could be a reflection of your understanding of your requirements, but that understanding is incorrect. This sounds very much like what happened in your situation - the software is behaving exactly as the developers intended it to, but their intentions and the expectations of the users did not align.

1

The difference is that "bug" implies the software is doing something wrong, and that it should be able to do that thing better than it currently is.

Most undesirable behaviors that I would not consider bugs would fall into one of these categories:

  • A flaw that's inherent in the nature of the application, and simply cannot be avoided. Your mobile phone's browser may take a long time to load a web page when you have a very weak cell signal. It may also display vulgar, offensive, or just plain irritating content that you did not want to see. In general, these are not problems the browser can ever completely solve.
  • A tradeoff with another design goal. Many programming languages allow floating point numbers to have rounding error, because doing all their math with arbitrary-precision arithmetic would be too performance intensive. There have been many arguments about which rounding errors do and do not qualify as bugs.
  • A simple mistake in the design that, for whatever reason, is no longer feasible to change.
  • A flaw, tradeoff or design error in the specification that a program needs to conform to. Most C++ compilers will allow you to compile code that is very obviously broken, because otherwise they wouldn't be conformant to the C++ Standard.

I don't fully understand the numpy array indexing issue you've linked to, but it sounds like it's in the third category.

0

A bug would be behaviour that appears because someone, somewhere made a mistake. It might be the UI designer who told the developers to implement wrong behaviour, it might be a developer making a mistake, or the compiler.

On the other hand, if it was decided that the action for some button will not be implemented because it's too much cost and effort for the gain, that's certainly undesired behaviour, but it is intentional, not a bug.

0

A bug is when the user-observable behavior differs from the documented behavior. An undesired behavior is when the user-observable behavior correctly corresponds to the documented behavior, but you would rather like to have a different behavior.

  • "Bug": the system doesn't do what it promises
  • "Undesired behavior": the system makes stupid promises
  • The documentation for the .Net Membership.GeneratePassword() method said that one of the integers passed was the maximum number of special characters to be contained in the generated password, which makes sense when you think about it. However the observed behaviour was that the integer was the minimum number of special characters. In other words, somebody probably used the wrong angle bracket in an if statement. Microsoft's fix? Change the documentation. – user1666620 Jan 27 '16 at 17:42
  • Yeah, well, if you look closely at the definition, there are indeed two ways to get the observable behavior and the documented behavior to agree. Microsoft is very big on backwards-compatibility (that's the price you pay for being enterprisey), so they'd rather not break existing code. There are other examples, like the buggy pseudo-random number generator, which can't be fixed without changing the numbers it generates (after all, it is those numbers which are the problem), and thus is left as-is despite having horrible randomness properties. – Jörg W Mittag Jan 27 '16 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy