Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^5: The True but Zero value?

by demerphq (Chancellor)
on Mar 21, 2016 at 13:39 UTC ( [id://1158434] : note . print w/replies, xml ) Need Help??

in reply to Re^4: The True but Zero value?
in thread The True but Zero value?

BTW, there is nothing special about 0E0. It could be 0E5 for instance. The important point is that the value is in engineering notation so is true as a string, but not true when interpreted as a number. You could also use "00" for this purpose as well.

"0 but true" is special however in that perl has specific exemptions for it internally.


Replies are listed 'Best First'.
Re^6: The True but Zero value? (best)
by tye (Sage) on Mar 22, 2016 at 14:24 UTC
Re^6: The True but Zero value?
by Marshall (Canon) on Mar 22, 2016 at 12:15 UTC
    demerphq is quite correct. The only thing that is "special" about "0E0" is that it is documented in the Perl DBI. I have classic EE training so working with exponents is easy for me. However, I like the 0E0 idea and find it preferable to 0E5 or say "00" because a simple typo "0" gets us into another special case which might be hard to find in the code. This 0E0 values allows the DBI to express 2 ideas in one return value: 1) did it work or not? and 2)how many results were obtained.

    I think we've "nailed this one". Here is summary of these special things:

    1. string "0", this would normally be "true" in a string context, because all non-null strings are "true". However this is a special case where it evaluates to "false" in a string context. So the special case code allows a more intuitive behavior although technically an exception to the standard rules. Of course this is numeric zero in a numeric context as would be expected.

    2. string "0 but true", this is a special case where you can do math on this, e.g.. $val +=0; and no warning will occur even with warnings enabled. Normally there would be a warning of $val is non-numeric at line x...". This of course is "true" in a string context (all non-null are normally "true") and zero in a numeric context, just like it says. This is not seen as often as the next string ("0E0") which accomplishes the same thing.

    3. string "0E0", This could have been any string that evaluates to zero in a numeric context, e.g. "00" or "0E5", However 0E0 is the documented return value in the DB for the "0 but true" value. Since this is a valid number in a string context, no special code need execute like in case (2).

    Note: When I work with something that can return (2) or (3) and I make use of that, I add a comment to explain what is going on. Even if you know what is going on when you write the code, 3 years later, that might be "fuzzy".

      I should have mentioned in my original post that there is another set of special cases for this purpose. Perl silently ignores leading and trailing whitespace when numifying a string (which AFAIK is not widely known nor documented, although a pointer to the relevant docs are welcome). So there are an infinite set of strings which are false numerically, but true in boolean context. (And an infinite set of strings which are numerically equivalent to any integer you choose.)

      perl -wle'my $n= (" " x 1_000_000) . "0" . (" " x 1_000_000); print $n + ? "true" : "false", " as a bool, prenumification"; print 0+$n ? "tru +e" : "false", " as a bool, numified"; print $n ? "true" : "false", " +as a bool, postnumification";' true as a bool, prenumification false as a bool, numified true as a bool, postnumification

      This is not generally a problem except for people who write serializers and need to ensure that " 0 " round trips correctly.


        You are correct about "numifying" a string and ignoring white space. I made a recent post that demo's this at: Re: confusion with Chomp. I don't know where this is documented either, but I know that it is the way that it works.