• (cs) in reply to Mike
    Anonymous:

    Anonymous:
    Ok I think we all kinda agree on the BOOL definition as  aWTF.

    No, the bool definition is perfectly valid.  Usually when you see a 3rd value, it indicates that the boolean value should not be considered.

    For example, Lets say you were polling a set of objects:

    obj1.Vote = true;
    obj2.Vote = false;
    obj3.Vote = false;
    obj4.Vote = true;
    obj5.Vote = false;

    In this case, the majority voted false.   Now consider this:

    obj1.Vote = true;
    obj2.Vote = NoValue;
    obj3.Vote = NoValue;
    obj4.Vote = true;
    obj5.Vote = false;

    Here, obj2 and obj3 don't have a vote.  They don't care either way, so in this case their votes are not counted and the group votes true.

     

    I'm sure that no one will see this but,

    you aren't comparing apples to apples.  The obj1.vote says to me if the person chose to vote not how they votes.  Get it right!  A vote would be yes or no or abstain.  NOT A BOOLEAN!!!!!!!

  • (cs) in reply to osp70
    osp70:
    Anonymous:

    Anonymous:
    Ok I think we all kinda agree on the BOOL definition as  aWTF.

    No, the bool definition is perfectly valid.  Usually when you see a 3rd value, it indicates that the boolean value should not be considered.

    For example, Lets say you were polling a set of objects:

    obj1.Vote = true;
    obj2.Vote = false;
    obj3.Vote = false;
    obj4.Vote = true;
    obj5.Vote = false;

    In this case, the majority voted false.   Now consider this:

    obj1.Vote = true;
    obj2.Vote = NoValue;
    obj3.Vote = NoValue;
    obj4.Vote = true;
    obj5.Vote = false;

    Here, obj2 and obj3 don't have a vote.  They don't care either way, so in this case their votes are not counted and the group votes true.

     

    I'm sure that no one will see this but,

    you aren't comparing apples to apples.  The obj1.vote says to me if the person chose to vote not how they votes.  Get it right!  A vote would be yes or no or abstain.  NOT A BOOLEAN!!!!!!!

    Makes perfect snese to me, Vote is not a boolean. It has three possible values. For, Agasint, Abstaine.

    It's like the earlier example where somone was trying to apply values which apply to boolean values to Gender.

  • Horhe (unregistered) in reply to Colin

    Anonymous:
    Tri-bool: true, false, null.

    What's the problem with that?

    If you were to mark the gender of someone named "Rene" or "Chris", what would you mark it as?  Perfect instance of a boolean situation (male or female, obviously) and a third: unkown/not-sure.

    Hardly a WTF on that count.

     

    I agree - this is not a WTF at all.

  • (cs) in reply to Horhe
    Anonymous:

    Anonymous:
    Tri-bool: true, false, null.

    What's the problem with that?

    If you were to mark the gender of someone named "Rene" or "Chris", what would you mark it as?  Perfect instance of a boolean situation (male or female, obviously) and a third: unkown/not-sure.

    Hardly a WTF on that count.

     

    I agree - this is not a WTF at all.


    Haven't you been paying attention? This is a major WTF.

    Think about it: A bool is the putative assertion that a given statement is true. The statement "Person X is female" is either true or false. This is not semantically equivalent to "What is Person X's gender?": The answer to that is either "Male" or "Female", neither of which are boolean values.

    What's the name of the attribute in the Person entity? If it's "IsFemale", then it can be a bool. I doubt that's the case; typically it's "Gender", which is not a bool, and should be an FK from a Gender entity, or simply strings (e.g. "M" or "F")

  • The Rev (unregistered) in reply to Spudley
    Anonymous:
    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.



    Amen.   Church is now out.

  • Clayton Moore (unregistered) in reply to John Smallberries
    John Smallberries:
    The Lone Ranger:

    Hi, Ho, Tonto, Away. . .

    Isn't your horse's name "Silver"?
    Or are you actually riding on Tonto's back now?


    Sorry.   It was a really, really long day. . .

    all those bullets to polish. . .
  • Steve (unregistered)
  • (cs) in reply to Steve
    Anonymous:

    So? Are you holding up VB as a shining example of syntactical & semantic clarity?

    In any case, your post is a WTF since the TriState is a different type with a different purpose than a bool. It can't simply be used in place of a bool (or whatever VB calls it), and it doesn't have the same semantics as the enum defined in this WTF.
  • (cs)
    Alex Papadimoulis:

    As we've seen here plenty of times here, one can learn a lot about a system from just peeking at a few lines of code. But many times it's the enumerations defined in the system that will tell you more than you'll ever want to know. I'll leave it as an exercise to the reader to imagine the innards of this C#-based warehousing system that P.G. had the pleasure of working with ...

    public enum OrderStatus
    {
    Opened = 1,
    PendingApproval = 2,
    Approved = 4,
    PendingAuthorization = 8,
    Authorized = 16,
    PaidFor = 32,
    Reject = 64,
    Rejected = 128,
    Deleted = 256,
    Removed = 512,
    UnRejected = 1024
    }


    While some of these values are mutually exclusive for an order, any combination of theses statuses can apply to a given set of orders. In warehousing, sometimes the program has to handle sets of orders. Trust me. Therefore, this design might be reasonable.


    ...

    public enum BOOL
    {
    TRUE,
    FALSE,
    NOT_TRUE_OR_FALSE
    }


    BOOL obviously is a acronym for Brillant Obstruction Of Logic
  • 42 (unregistered) in reply to AndyW

    Probably a default value for the database, if they don't know if it should be true or false.   

    But it should be named troolean or something :)

  • garrrbbaaaggee (unregistered) in reply to ParkinT

    true

  • (cs) in reply to ParkinT

    »Is this BRILLANT or not?«

    Brillant or not? This is a yes/no question that can be answered with a boolean. I'de say BOOL.NEITHER_TRUE_OR_FALSE;

  • (cs) in reply to Colin
    Anonymous:
    Tri-bool: true, false, null.

    What's the problem with that?

    If you were to mark the gender of someone named "Rene" or "Chris", what would you mark it as?  Perfect instance of a boolean situation (male or female, obviously) and a third: unkown/not-sure.

    Hardly a WTF on that count.



    According to SNL, that would be best implemented as:
    public enum GENDER_BOOL
    {
    MALE,
    FEMALE,
    PAT
    }
  • (cs) in reply to pmagill
    Anonymous:
    Anonymous:

    <font color="#000000">pmagill:</font>

     Hmm, tri state booleans.

    I see them as more of a schrodinger's cat kind of problem.  Let's say you have a web site that stores visitors in a database.  This database also marks them as registered if they do so.  Now you could see this registered field as a boolean, either TRUE or FALSE, they are registered or they are not, but since this is a database and you may be doing as few updates as possible, and registration was added after initial release, it allows NULL.  This then becomes tri-state.

    Now on to the cat.  We know what TRUE and FALSE represent in the registered field, but we have a third value of NULL.  As with the theoretical cat, we don't know if the visitor registered or not until we check it.  Once we check we notice that it's state is not yet defined so we safely (and rightly so) assume FALSE.  As schrodinger's cat suddenly dies we know that this visitor has not registered because, if he had, this value would explicitly state TRUE.

    So are tri state booleans really tri state?  In most cases I think not, but there could be a time when the cat is undead if you bury it in the local Pet Semetary.

    That doesn't work at all. In the schrodinger's cat problem you don't assume one or the other or neither. You assume both because you can't observe it it. So he can observe the database (with respect to the program)... s/he's just to lazy to create better checking.

    meaning it exists partly as each simultaneously


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


    What happens when the state doesn't change then? The only way to assure that the cat is dead is when you put it in for an infinite amount of time... Plus, what is with the maybe thing on the end? Now you're just contradicting yourself. If we just assume for a minute that everything is false when it isn't observed then we can just assume that everytime we blink the universe decays. Anyways, someone once told me don't assume or you'll make an ASS out of yoU and ME. I'm sure this is some form of rule breaking... So I can probably say bye bye post...
  • (cs) in reply to nobody

    "Brillant or not? A yes/no question, I'd say NEITHER_TRUE_OR_FALSE"?

    Wait, so that means...

    The question is "Is it brillant or not?"
    If I say "yes", that means that either it is brillant, or it is not brillant, or both (assuming the OR is inclusive).
    If I say "no", that means that it is both not brillant, and not not brillant.
    But it's neither yes nor no.

    So therefore it isn't (either brillant or not or both), and it isn't (both not and not not brillant), so what is it? 42? Javascript? XML? Perhaps it's file-not-foundedly brillant with juice.

  • Claus Diff (unregistered) in reply to Colin

    For what it's worth, gender is a tri-state. Everyone has a gender, and it is conventionally given as male, female or indeterminate in humans.

    What was someone saying about null?

  • mathwiz (unregistered) in reply to B&#246;&#246;l

    Shouldn't it be

    NOT_TRUE_OR_NOT_FALSE


    Get your boolean operations straight, it should obviously be NOT_TRUE_AND_NOT_FALSE
  • pmagill (unregistered) in reply to Truls
    Truls:
    Anonymous:
    Anonymous:

    <font color="#000000">pmagill:</font>

     Hmm, tri state booleans.

    I see them as more of a schrodinger's cat kind of problem.  Let's say you have a web site that stores visitors in a database.  This database also marks them as registered if they do so.  Now you could see this registered field as a boolean, either TRUE or FALSE, they are registered or they are not, but since this is a database and you may be doing as few updates as possible, and registration was added after initial release, it allows NULL.  This then becomes tri-state.

    Now on to the cat.  We know what TRUE and FALSE represent in the registered field, but we have a third value of NULL.  As with the theoretical cat, we don't know if the visitor registered or not until we check it.  Once we check we notice that it's state is not yet defined so we safely (and rightly so) assume FALSE.  As schrodinger's cat suddenly dies we know that this visitor has not registered because, if he had, this value would explicitly state TRUE.

    So are tri state booleans really tri state?  In most cases I think not, but there could be a time when the cat is undead if you bury it in the local Pet Semetary.

    That doesn't work at all. In the schrodinger's cat problem you don't assume one or the other or neither. You assume both because you can't observe it it. So he can observe the database (with respect to the program)... s/he's just to lazy to create better checking.

    meaning it exists partly as each simultaneously


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


    What happens when the state doesn't change then? The only way to assure that the cat is dead is when you put it in for an infinite amount of time... Plus, what is with the maybe thing on the end? Now you're just contradicting yourself. If we just assume for a minute that everything is false when it isn't observed then we can just assume that everytime we blink the universe decays. Anyways, someone once told me don't assume or you'll make an ASS out of yoU and ME. I'm sure this is some form of rule breaking... So I can probably say bye bye post...


    Ok, how do we know the universe doesn't decay every time we blink?
    Seriously though (might be difficult because this is not a totally serious thread) My example shows that most of the time you can default (or assume) the value of an unknown as in my example above, but there is an exception to every rule, as much as this can be called a rule, as your example shows.  In truth, my example shows a boolean representation with a third unknown value that is easily interpreted as one of the TWO boolean states.  You example, in contrast, shows not a boolean but rather an enumurated value.  Once you take a presumably 2 state value and recognize a third state as having a different meaning from the previous two, you are no longer talking boolean but rather a more extensive enumeration.

    Following this logic, a boolean is an enumeration, but an enumeration is not a boolean, just as a square is a rectangle but a rectangle is not a square.  A boolean is just a bi-state enumeration, anything greater is an enumerator of greater proportions.
  • (cs) in reply to pmagill
    Anonymous:
    Ok, how do we know the universe doesn't decay every time we blink

    I...will...never...blink...again...blink DOH!

  • Tim. (unregistered) in reply to Colin

    No, that piece of code would look like this:

    enum GENDER
    {
    MALE,
    FEMALE,
    PAT
    };

  • (cs) in reply to s01
    Anonymous:
    Assigning constants, I do the same thing sometimes out of habbit.  I work a lot w/ flags that work with combinatorics.  I.e. READ, WRITE, EX_LOCK and so on.  I'm hoping, in good faith, that the number assignments were just habbit, and not for silliness like (REJECTED|NOT_REJECTED) type crap.

    I think it's a bit of both. :D
  • B (unregistered) in reply to AndyW

    Ah, yes, but this enterprising coder has (re)discovered fuzzy logic.

  • tdog (unregistered)

    No WTF here. 

    The first enumeration is obviously using some bit mask ie. 00000001

    And there is such a thing as not true or false, its called a maybe.

     

    -- tdog

  • Old C Programmer (unregistered) in reply to tdog

    The true/false is not a WTF because in real-time systems for example it's common to have a boolean state "not yet determined" were you'd be incorrect defaulting to either true or false. Maybe form A goes up if the field is true, form B goes up if false, but if not yet determined you don't put up either.  He could have maybe renamed it to that, but if everybody in the shop is used to that I think it's clear enough.

    The bit fields isn't a WTF either but there may be easier ways today. It's from embedded or C days back when you had to count every byte. With space not so much an issue it's probably better to use booleans so you get more readable code like if (Order.Status.bIsOpen && Order.Status.bIsRejected) instead of if (Order.Status & (Open | Rejected)) but the latter is certainly understandable and used in certain shops.

  • Merlin (unregistered) in reply to Old C Programmer
    Anonymous:
    The true/false is not a WTF because in real-time systems for example it's common to have a boolean state "not yet determined" were you'd be incorrect defaulting to either true or false.


    Even if that was what it was about, the choice of  'NOT_TRUE_OR_FALSE' as an identifier is extremely stupid. It doesn't  make any sense as far as boolean logic is involved. So the identifier in that case should be called something that makes sense, such as 'STATE_NOT_DETERMINED'.

    For ultimately, this is also what a "WTF" is all about: even in a case of a clear design, you manage to screw it up - especially maintenance-wise - by using arbitratily inept identifiers and constructs.

  • tdog (unregistered) in reply to Merlin

    Anonymous:
    Anonymous:
    The true/false is not a WTF because in real-time systems for example it's common to have a boolean state "not yet determined" were you'd be incorrect defaulting to either true or false.


    Even if that was what it was about, the choice of  'NOT_TRUE_OR_FALSE' as an identifier is extremely stupid. It doesn't  make any sense as far as boolean logic is involved. So the identifier in that case should be called something that makes sense, such as 'STATE_NOT_DETERMINED'.

    For ultimately, this is also what a "WTF" is all about: even in a case of a clear design, you manage to screw it up - especially maintenance-wise - by using arbitratily inept identifiers and constructs.

     

    bosh

  • (cs) in reply to tdog

    Thank goodness C# 2.0 at last has the bool? datatype...

    bool? b = cat.IsAlive();

  • Ali Pang (unregistered) in reply to Gene Wirchenko

    a boolean algebra must have a zero-element and a one-element. it is however not necessary that these are the only elements in the set...

  • Anon (unregistered) in reply to devdas
    devdas:
    mrprogguy:
    The WTF for me is 128 for Rejected, and 1024 for UnRejected. How is "UnRejected" different than having the bit for "Rejected" be off?

    Decision states. I would interpret UnRejected as someone reversing a decision to Reject This is not the same as a rejection never having occured.

    Which is a another WTF. This mixes the current state of the order with its history.

  • Ryan (unregistered) in reply to Smaerd

    When you read a qubit, it has a discrete state at that instant.

    That being said, I do like qubits.

Leave a comment on “Enumerating The Difficulties”

Log In or post as a guest

Replying to comment #:

« Return to Article