- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
From the Wikipedia page you supplied:
"... and <font size="5">two</font> elements 0 (logical FALSE) and 1 (logical TRUE), such that..."
From the dictionary:
"Of or relating to a data type or variable in a programming language that can have <font size="5">one of two </font>values, true or false."
Wow, wrong again.
In ANSI-C, the truth test of the constructs if, while & for all require an implicit boolean type - this is specifically the reason it was promoted to an explicit type in C++. Booleans in C are either zero (false) or non-zero (true).
Admin
Admin
I take it you never studied mathematics. There are many mathematical statements that can neither be proven to be true nor proven to be false (in fact there are an uncountable infinite number of them).
Admin
God, this is the worst WTF ever.
He probably just left off the FlagsAttribute. As another poster mentioned, maybe it's passed in to a reporting component to specify criteria - who knows? We don't.
And yeah he implemented his tristate concept poorly. Wow.
This is not a WTF, it's just shit code. And before people say 'Oh, but you haven't seen the rest of the system', if this is the best that Alex thought fit to post why do you assume the rest is worse?
You guys should get out more - I see more developers coding at this standard than I see doing a reasonable job. It's what creates high paying work for the rest of us[:D]
Admin
It's a heisenbool!
Admin
You're so smrt.
Admin
You have to imagine looking at them (the anatomical couterparts) head on (ahem...)
As for the bit mask business, maybe that was his original intention and it just didn't work out, or maybe he likes powers of 2. Maybe (as other posters have suggested) it is possible to have seemingly disparate order statuses. Does it really matter what the enum values are? What comments would we get if they were primary numbers?
Sincerely,
Mr. Mo
Admin
Nice... it's just a little bit-shifting left during order-processing to get the order to transition states! :-)
Admin
As opposed to the countable infinite number of something(s?). Particularly nice translated to Dutch (infinite~="uncountable").
Somewhat Sincerely,
Mr. Mo (now heading to refill his drink again)
(what old code of mine can I drag out to submit? Anyone got the source to Timex/Sinclair basic?)
Admin
Imagine this was actually quoted in the post above. Assuming there is something to be seen here, that is.
Admin
That doesn't mean the relational model is dumb. Codd defined the relational model, not SQL. It's not his fault that the language came out like this.
Admin
Yes, there is a difference between countable and uncountable infinite numbers.
Countable infinates is a set like 0, 1, 2, 3, ... all the way to infinity.
Uncountable infinites is a set like all of the floating point numbers between 0 and 1.
Admin
The name of the third value (NOT_TRUE_OR_FALSE ) should be TRULSE (TRUefaLSE) - it means that value can be TRUE or FALSE or both :)
Admin
There really is no WTF at all for that first enumeration. People who say "he should've used a 'flag' naming convention' are just crackpots. There is no flag naming convention, look at the Windows SDK or the Linux sources and flags are often just given standalone names within an enum.
Flags do NOT have to be mutually exclusive. Clearly this person has never worked on real software that uses bitvectors.It would be highly inconvenient if every mutually exclusive condition had to be placed into a new type and have it's own variable.
A simple example would be wanting to mask a bit that is applied to several other mutually exclusive flags, in whcih case you have a whole enumeration of exclusive bits with a single shared flag that can be toggled for any of them.
Look at the Linux headers, there are piles of enumerated flags that are mutually exclusive to each other.
Admin
Yes, as opposed to countably infinite sets such as the sets of all natural numbers or all integers.
Admin
OK, please count all positive integers (I just cut your workload in half- or did I?) and get back to me with the result. Simply saying "infinity" doesn't count!
Still think it's countable? Just because you can list a bunch of them in sequence doesn't mean you can actually count all of them.
Yes, I do understand the concept of varying degrees of infinity (as much as it can be humanly understood anyway) but I wouldn't use "countable" as an attribute for any of them.
Admin
Ok, so I missed the #define countable sequenceable at the beginning of the math course.
Here's the original quote:
There are many mathematical statements that can neither be proven to be true nor proven to be false (in fact there are an uncountable infinite number of them).
Please prove that there are an uncountable infinite number of them- or is this one of the uncountable ones?
Admin
I think the thing he was getting at is that there's a very simple formula for counting all positive integers. The sequence is very simple and very well defined. On the other hand, there is no such simple formula for counting all real numbers between 0 and 1.
If you want to get into what's countable and what's uncountable, have a blast:
http://en.wikipedia.org/wiki/Countable
Admin
By definition, a set is countable iff it has the same cardinality as the set of natural numbers. The mapping f(x)=2x+1 if x >= 0, -2x if x < 0, is a bijection from the integers to the natural numbers, thus they have the same cardinality, and the integers are countable. QED
Actually that is the very definition of the mathematical concept of 'countable'.
Unfortunately for you, you cannot just define your own language and expect everyone else to follow it. 'Countable' is a well defined and accepted mathematical term. If you don't like it, dispute it with the academic journals, but please do not claim others are misusing the terminology.
Admin
I believe Kurt Godel already did so, but if you want an abridged version...
There is a countable set of mathematical proofs. There is an uncountable set of truths in mathematics. Therefore there is going to be an uncountable set of truths that do not have a corresponding proof.
Admin
Or take Haskell, where there is a value "bottom" that is a value in every type. So there are three values for Bool: True, False, and bottom.
Think of it this way: Suppose you have a function bool f(void); When you call f(), one of three things can happen. It could return true, it could return false, or it could not return. Bottom is the value of this third possibility.
Admin
This is the stupidest WTF I have ever seen here, but of course, people still find it necessary to jump on the complain bandwagon, because, yeah, that's what people do here; despite the fact that most of you are high school students who haven't created a bigger project than that home page back in junior high.
As for OrderStatus, it's painfully obvious that the numbers as such are chosen to be able to work as bit indices. I'm sure there's an integer called status for every order. A perhaps minor WTF is doing pointless space-savings instead of just using additional columns in the presumed database backend. Some of the available status options might seem a little off, such as UnRejected (which I assume means that an order was rejected, but then accepted again) and some might even be partially redundant, but since they were probably added iteratively during the project's development, no big suprise here.
As for the BOOL, getting stuck on the name of the enum or arguing that mathematically boolean algebra only has two states is really stretching it. It's quite obvious that this is the code presentation of different states given by the underlaying storage mechanism. My first guess would be the availability of a boolean datatype in the used database where one can store three values: false, true and null.
Admin
I stand humbled before the collective mathematical/google genius of the forum. Please accept my apologies for interpreting "countable" to mean "able to be counted". I guess I did miss out on a few things in those engineering versions of my mathematics courses.
But, the number of truths that do not have proofs is not the same thing as the number of mathematical statements that cannot be proven to be true or false. I can personally make many mathematical statements that can be proven to be false.
Admin
did you read the article before posting the url?
"A Boolean algebra ... two elements 0 (logical FALSE) and 1 (logical TRUE) ..."
or did i miss the irony in your posting?
Admin
that simply means that a mathematical statement can't be described by a boolean value but not that a boolean must have three states.
Admin
That is completely besides the point as you compare:
BOOL value = BOOL.True
if(value == BOOL.True)
and most certainly not:
BOOL value = BOOL.True
if(value == 1)
Now that would be a WTF by itself.
Admin
nope... not (true or false) is only true if the value isn't true, but isn't false either.
not(true) or not(false) is false in that case, and is true in case the value is false (making part 1 true) or true (making part 2 true).
Admin
Gender is not boolean, mm'k? Even for those whose gender identity is strongly fixed, there are gray areas. Like most things in psychology, it's a continuous range, not a discrete one.
As for the argument over bi-state, tri-state, n-state etc. logics, well, mathematically speaking, it's pointless. In aggregate, a collection of binary digits can represent any arbitrarily large number of discrete states (isn't this exactly what an enum is, in C, after all?). Using multiple state in the primary representation is pointless. The real division is between discrete and continuous, not bi-state and n-state.
Admin
<!--StartFragment -->
I didn't say the Relational Model was 'dumb', I think it's a great peice of work, and I can't remember ever blaming Codd for SQL either. I did say SQL was wrong.
Admin
hey what if the guy who wrote the code used the bool enum for another purpose too.
like to see if the enum had never been changed or touched.
if it was false, and somewhere in the code it became true, then again false.
then you wont know about the transition from false->true->false..
so probably he added that enum value..
he can catch the transitions in other ways too, but he just did it like this.. who know?
or ya he was really dumb..
Admin
WTF???
Admin
funny thing is that
Admin
Having a logic with more than two values is not as uncommon as you might think. Expert systems almost alway worked with three value logic. Ofcause doing this and still calling it bool algebra is not correct.
A system I worked with had a 4-value logic: true, false, unknown and not-known. The difference between unknown and not-known was that unknown was the value of an unassigned proposition (null) and not-known was and actual assigned value (not enough informatie to detemine value).
If a system needs to produre correct logical result having the default bool leads to errors.
Admin
Very eloquently stated!!
Admin
Well, in the particular case we're discussing (null values in boolean columns), most SQL databases do as Codd said.
Admin
"The Trouble with Tri-Bools" is your geeky reference of the day. :)
I don't see the problem with the first one - that is how flags are defined in C# (you have to prepend the enumeration with the "[Flags]" attribute, but it's possible this was omitted?).
Admin
The funny thing about there being only 2 values for a bool is that Visual Studios 2005 now has a third value built in: null. I guess this takes care of people who don't instantiat the variable or if the DB has bad information.
Admin
I don't see any big problem with todays WTF.
Okay, sure the tri-state boolean is a bit weird, but if you want to cope with a nullable SQL field, it's hardly the worst way you could find to do it.
The bigger enum is also fine - as has been said, it's common enough to combine values like this with OR. The reject/rejected/unrejected options that some people are laughing at also look fine -- I'd interpret them as: reject -- marks that someone has asked for the item to be rejected. rejected -- marks that it has actually been rejected. unrejected -- marks that the rejection has been reversed. All perfectly legitimate things to want to keep track of in a status field. Possibly some slightly poor choices for their names, but nothing that deserves posting here.
Admin
<font size="2">He used powers of 2 so that the enum values can be logically OR'd together. For example, using this scheme in C# allows you to do this:
OrderStatus S = OrderStatus.Opened || OrderStatus.Rejected;
Of course the real WTF is that an order really shouldnt have more than one status at a time, and even if he did want to use the enum this way he is supposed to apply the [Flags()] attribute...
</font>
Admin
enum BOOL {
HEADS
TAILS
EDGE of Coin
}
Admin
The real WTF here is that the state flags from the first enum can't hold all the values for bool in the second enum.
Admin
I know several individuals who are still stuck in the C mindset that it's so much more efficient to place compound attributes in a bitmask.
I can only tell you with what JOY I have when the same shitheads store the mask value directly in the database and you have to JOIN or WHERE against this.
Simple example:
DBA: What? MedFlags isn't a FK?
Admin
This my friend is where the axiom of schrodinger's undead cat comes into play.
Admin
Apparently you forget the reason for the cat. Yes until you observe you have to assume both, because it can equally be one or the other, just like a value in a database, before you observe you have to assume both, or more logically neither, because it could be either one or the other equally. It is only upon observation, checking the cat or reading the field, that the true state is determined. The study was in essence the idea, that by simply observing something you affect it's state. The boolean here displays that in a very succient manner. By observing the field and seeing a still inknown value we affect it's state to be false.
Of course, I did add the MAYBE at the end, hence the undead cat or true unknown.
captcha = doom (for the cat or the boolean?)
Admin
wow 200 posts on one of the lamest WTFs ever... must be a slow week.
Admin
Isn't your horse's name "Silver"?
Or are you actually riding on Tonto's back now?
Admin
Huruh, someone who understands...
Admin
Just to digress for a second: there's a really simple proof that demonstrates that there are some infinities bigger than other infinities. Check Cantor's Theorem. So easy that you can demonstrate an application of it on a napkin:
1. Imagine a grid that starts at the upper left of your napkin and proceeds in the direction of the bottom and right corners (and extends infinitely). For the purposes of this discussion, we'll only consider the bit that falls on your napkin.
2. Along the left side, starting from the top, write the numbers "1, 2, 3, 4..." until you get to the bottom of the napkin.
3. Draw a vertical line to separate those numbers from the rest of the napkin. Then fill the spaces of the grid to the right of the napkin with numbers. Doesn't matter what they are, so long as they're counting numbers (non-negative integers). When you're done, you should have a column of numbers starting at 1 along the left side of the napkin, and a grid with semi-random numbers filling the rest of the napkin.
4. Imagine someone has asked you to enumerate, in no particular order, every last real number between zero and one. The numbers in that grid are your attempts: just imagine that there's a "0." on the beginning of each one. Since your imaginary grid continues infinitely far to the right, you know that they are infinitely precise, and since it continues infinitely far down, you know there are an infinite number of entries.
5. The good part: like you were doing a word search, draw an ellipse around the first digit of the first line, the second of the second line, the third of the third, etc, and imagine it continues on infinitely. For each digit you've circled, add one to that digit and write it down on the back of your napkin (if it's a nine, make it zero).
Congratulations. You've now constructed a number that doesn't appear anywhere on your list, and you can prove it because it will differ from the first number at the first decmial place, from the second at the second decimal place, from the third at the third, ad infinitum.
And that is the difference between a set which is infinite but enumerable. And, in fact, this distinction was described by good old Georg Cantor as being countably infinite or uncountable: if a set can be put into a one-to-one relationship with the positive integers, it's countably infinite. Otherwise, it's uncountably infinite.
http://en.wikipedia.org/wiki/Infinity
Admin
Why is everyone overcomplicating this? The Boolean datatype is two values: true and false. Many times you need something else. But your need doesn't change the definition of Boolean in a computer science context. Nullability is an issue with all value datatypes, not just Boolean. So that's really a silly point to argue.
Admin
WTF, that should be: enum BOOL { NOT_TRUE_OR_FALSE = 0; TRUE = 1; FALSE = 2; BOTH_TRUE_AND_FALSE = 3; }; // Perhaps with the flags attribute should be set?
See how much better it is now?