Yet another interpretation of "boolean"



  • From an instructional comment on how to use a program that can generate full or partial reports:

    The program takes several arguments as follows:

    Arg1 - path to input file
    Arg2 - path to output file
    Boolean parameter to generate full report or not, type keyword: ‘full’ for the full report 
    
    *sigh*
     


  • Wow, when will people realize that a boolean is just an Enum with exactly two defined values of true and false or representations of true and false (i.e. 1, 0).

    Anything else is simply known as an enumerator.



  •  Incorrect. You should know the only correct definition of boolean is one of the elements of {true, false, FILE_NOT_FOUND}



  • @KattMan said:

    Wow, when will people realize that a boolean is just an Enum with exactly two defined values of true and false or representations of true and false (i.e. 1, 0).

    Anything else is simply known as an enumerator.

     

    OMFG! You missed the point:

     "A boolean representing if you want the full report. "full" to get full report"... a true should give you the full report... WTF was this guy thinking?

     

    When will people realize that 0 = true, 1 = false and 2 = file not found?



  • @dtech said:

     Incorrect. You should know the only correct definition of boolean is one of the elements of {true, false, FILE_NOT_FOUND}

    You sure of that? I recently encountered a boolean where the possible values were {"no", anything else}.



  • While on the subject of boolean, I have to admit to bastardizing boolean values myself on occasion. In particular, I have a field in our customers database table called 'active' that is a MySQL Tiny Int. Its values were originally 0 or 1, but I had to add a 2 value when the powers that be decided they needed to put customers into limbo (much like how a zombie is neither dead or alive). It isn't pretty, but the change didn't require mending other code that relied on the old 0 or 1 values because they stayed the same.

    Luckily in MySQL there is no real boolean, only Tiny Int, so I was really just bastardizing an int type with strange values. Yes, I added a field comment to document these values.



  •  So....

    {true, false, FILE_NOT_FOUND, ZOMBIE} our boolean list grows.

     

    edit: forgot my tags



  • When will people realize that 0 = true, 1 = false and sqrt(-1) = file not found?
    FTFY


  • @KattMan said:

    Wow, when will people realize that a boolean is just an Enum with exactly two defined values of true and false or representations of true and false (i.e. 1, 0).

    Anything else is simply known as an enumerator.

     

    I'm not sure when an Enum stopped being an enumerator. But are you saying (Full, NotFull) aren't representations of true and false? What about (On, Off) (Yes, No)?

     



  • @astonerbum said:

    our boolean list grows.
    Don't forget {yes, no, SILVER}.  Though strictly speaking, that's for Wall Mountable, not Boolean.  But Wall Mountable ought to be a Boolean.



  • @snoofle said:

    Boolean parameter to generate full report or not, type keyword: ‘full’ for the full report 
    

    One app I fortunately don't have to maintain went to great expense to ruin a boolean value. A checkbox usually returns "true" or "false" as a value by default, unless the value attribute is used. Whoever did this thing, set the "value" attribute. (WTF #1)

    Then, attribute is taken from the parameter list, even when the app's using JSF, which can automatically map form input fields to ManagedBean fields. Once again, a checkbox would directly translate as a Boolean. (WTF #2)

    Instead of evaluating the string, it is sent to the backend EJB as a String, but documented as a "boolean". (WTF #3)

    Finally, it is compared deep down somewhere in the business logic layer. Gah!



  • @snoofle said:

    From an instructional comment on how to use a program that can generate full or partial reports:

    The program takes several arguments as follows:

    Arg1 - path to input file
    Arg2 - path to output file
    Boolean parameter to generate full report or not, type keyword: ‘full’ for the full report 
    
    *sigh* 

    You know what he means though, right? Even though his usage is off.

    The full parameter is a binary decision - it's either full or not. Obviously the concepts of a "binary choice" and a "boolean parameter" are close enough to being the same thing to this guy.



  • @chrismcb said:

    @KattMan said:

    Wow, when will people realize that a boolean is just an Enum with exactly two defined values of true and false or representations of true and false (i.e. 1, 0).

    Anything else is simply known as an enumerator.

     

    I'm not sure when an Enum stopped being an enumerator. But are you saying (Full, NotFull) aren't representations of true and false? What about (On, Off) (Yes, No)?

    Not what I am saying at all.

    Full, NotFull could possibly be representations of a boolean, but what happens when you get to half full.  This is where the Full, Not Full breaks down.

    If the question were instead Full? with answers of yes or no, then it can represented as a boolean, half full would be no, it isn't full.  It is question like these that break your booleans, if the answer is not a yes/no answer do not use a boolean because your answers will eventually expand to include other values so therefore should be represented as an enumurator.

    It comes down to design choices.  Ask a user for a color and you naturally chose a enum, ask if it is blue and you choose a boolean.  If the question was "What kind of report?", the answer is an enum because there can be multiple values.  If the question was "Run Full Report?", the answer is a boolean (yes/no) 

    So in short, Full/NotFull is not a boolean, Yes/No is, On/Off also is.  It really depends on the question.



  •  Since half full is not full, then the {full, notfull} boolean isn't broken. If you introduced a 3rd element then the enum wouldn't be a boolean, but that's irrelevant. 



  • @NeoMojo said:

     Since half full is not full, then the {full, notfull} boolean isn't broken. If you introduced a 3rd element then the enum wouldn't be a boolean, but that's irrelevant. 

    You sir have no understanding of the planning for variables.

    If the question is "What report?" and the current answers are Full and Not Full, use an Enum becuase this answer will probably later expand to include something else and changing all your code friom a boolean to the enum would not be fun.

    If the question was "Run full report?", then you have a yes or no question and can use a boolean.  Granted this leads to another logic branch if they say no and have further choices to make but this variable won't have to change.

    Basically, If you have answers other than the literal Yes/No, use an enum even if currently you only have two possibilities.



  •  This is not a WTF.

     The default is a "short" report unless otherwise specified, the "full" parameter is much like the unix "ls -l" (full) vs "ls" (short,default) format.



  • @KattMan said:


    Not what I am saying at all.

    Full, NotFull could possibly be representations of a boolean, but what happens when you get to half full.  This is where the Full, Not Full breaks down.

    So in short, Full/NotFull is not a boolean, Yes/No is, On/Off also is.  It really depends on the question.

     

     If it is half full, then it is NotFull. I'm not sure how that breaks my boolean. The thing is either Full, or its NotFull. Full/NotFull is just as much of a boolean as Yes/No.

    If I ask you if the glass is full, and your answer is"it is half full." That is the same as me asking "Run full report" and your answer is maybe. I don't give you the choice of choosing HalfFull, the choice is Full or NotFull. Just as you don't give me the choice to say Maybe. Therefore the enum Full/NotFull is a boolean.

    A boolean is just a situation where there are two mutually exclusive answers. Call them what you want, yes/no, on/off, red/green, whatever. If the option is either one or the other, it is a boolean.

     



  • @chrismcb said:

     If it is half full, then it is NotFull. I'm not sure how that breaks my boolean. The thing is either Full, or its NotFull. Full/NotFull is just as much of a boolean as Yes/No.

    If I ask you if the glass is full, and your answer is"it is half full."

    And what if my answer is "It is half empty"?

     

    Is the file half-found, or is it half not-found? 



  • @DaveK said:

    Is the file half-found, or is it half not-found? 
     

    It's in a quantum state somewhere in between.



  • @dtech said:



    @DaveK said:
    Is the file half-found, or is it half not-found?


    It's in a quantum state somewhere in between.



    Groan.  Quantum computers are going to be a right PITA to code for:

    @Quantum Meta-Vax 9000: Runtime libraries, reference manual said:


    FUNCTION  fileExists

    PROTOTYPE
                 std::pair<std::complex<float>> fileExists (const char *path);

    ARGUMENTS
                 path - absolute or relative path to a file to test for existence.

    RETURNS

                 A pair of complex floats, both normalized in the range (-1.0 - +1.0, -1.0i - +1.0i)

                     pair.first - the fractional extent to which the file exists.

                     pair.second - the fractional extent to which the file does not exist.

                 Each complex float represents a unit eigenvector in the Heisenberg

                 phase-space of the file.

     BUGS

                 Under conditions of parity violation, lepton number may not be preserved.

                 May accidentally collapse the quantum vacuum into a lower metastable

                 state and destroy the universe.  In this case, fileExists() will throw a

                 UniverseNotFound exception.

    USAGE

                  std::pair<std::complex<float>> result;

                  result = fileExists ("/etc/passwd");

                  if ((pow (acos (imag (result.first) / real (result.first)), 2.0)

                     + pow (acos (imag (result.second) / real (result.second)), 2.0)

                  >= 0.5)
                 {

                      cout << "Wtf?" << endl;
                 }
                 else if ((pow (acos (real (result.first) / imag (result.first)), 2.0)

                     + pow (acos (real (result.second) / imag (result.second)), 2.0)
                  < -0.5)

                 {

                      cout << "File is at right angles to reality?" << endl;
                 }

                 else  [  .  .  .  ]



     



  • @DaveK said:

                     pair.first - the fractional extent to which the file exists.

                     pair.second - the fractional extent to which the file does not exist.
     

    Doesn't Heisenberg say that you can know whether the file exists, or where it is, but not both at the same time?



  • @snoofle said:

    From an instructional comment on how to use a program that can generate full or partial reports:

    The program takes several arguments as follows:

    Arg1 - path to input file
    Arg2 - path to output file
    Boolean parameter to generate full report or not, type keyword: ‘full’ for the full report 
    
    *sigh*
     
    When i first read this, I thought it was a bigger wtf than it really is.  This basically looks like the help text to some command line arguements.  Surely, nobody would complain if they saw this written out as:
    processsomething "C:\blah.txt" "C:\output.txt" -full 


  • @upsidedowncreature said:

    Doesn't Heisenberg say that you can know whether the file exists, or where it is, but not both at the same time?
    We can know neither whether the file exists nor what its path is with absolute certainty, because examining what the file's path is affects whether or not it exists, and examining whether the file exists or not moves it. Increasing resolution and certainty of one decreases resolution and certainty of the other.


Log in to reply