in reply to Re^5: List::Util::sum() and empty lists...
in thread List::Util::sum() and empty lists...

If you call your bank and ask them what the sum of all of your deposits this month is, and there are none, does your bank say "I can't answer that because there aren't any" or "$0.00"1 ?

You may have a difficult time understanding what the sum of zero items is. The authors of Scalar::Util may have a hard time understanding. But that doesn't prevent some of us from understanding that very clearly and knowing that, mathematically, the sum of zero items is actually well-defined and is simply 0. Similarly, the product of zero items is 1 ($x**0 is 1, and even 0**0 is 1).

It is similar to the author of Term::ReadKey not understanding that for ReadKey($delaySeconds), ReadKey(0) is not a special case and should mean "delay 0 seconds, returning immediately" and it makes no sense for them to have defined ReadKey(0) as "wait forever" and ReadKey(-1) as "wait 0 seconds". Many people have trouble seeing this, but that doesn't mean it isn't true.

1 Or using whatever currency your account is in.

- tye        

  • Comment on Re^6: List::Util::sum() and empty lists... (obvious)

Replies are listed 'Best First'.
Re^7: List::Util::sum() and empty lists... (obvious)
by Firefly258 (Beadle) on Dec 04, 2006 at 22:58 UTC
    If I call my bank and they tell me "You have no money left" ( which is a perfectly plausible reply ) I know i have £0 credit because I don't have trouble understanding the value of zero/null/undef/nothing, they're all different words representing the same thing, mathematically or otherwise.

    Most DBI::* methods return 0 (0E0) on success, doesn't mean they're returing false? Tie::Cacher::fetch() returns undef even on success, doesn't mean it is indicating a failure. Either we have a radical overhaul demanding that there is mathematical consistency all around or we just go on using these funny quirks that constitute the power and flexibility of perl, I have absolutely no problem with the latter because I think quite flexibly.

    In any case, this behaviour we see exhibited by List::Util::sum() might have been a genuine mistake or it might have been programmed in just the way it is for good reason. I just wonder what Graham Barr (the original author) has to say about it?


    perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er

      I just wonder what Graham Barr (the original author) has to say about it?

      Maybe he did it for consistency. Every function in the module returns undef when given an empty list (except shuffle, which doesn't return a scalar).

      Maybe it didn't occur to him to check for that case, since sum is simply sub sum (@) { reduce { $a + $b } @_ }. (While the XS version explicitely returns undef, it probably came after the Perl version.)

        Maybe. Maybe not. Only he can confirm if it indeed is a genuine oversight or not.

        But since this behaviour is quite clearly documented in the POD for the module, and that the module has been around for almost a decade now, I'm not convinced the behaviour is due to an oversight. But again, the POD could be wrong or script-generated.

        Only Graham or P5P can give us a definite, authoritative statement for the reasons his module behaves the way it does, until then, it's play by the rules in the POD, i suppose?



        perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er
          A reply falls below the community's threshold of quality. You may see it by logging in.
      because I don't have trouble understanding the value of zero/null/undef/nothing, they're all different words representing the same thing, mathematically or otherwise.

      "undef" means "undefined" which is quite different from "zero" or "nothing". Perl treats "undef" as zero (or the empty string) but only after emitting a warning. The warning is only required because "undefined" does not mean the same things as "zero", "nothing", nor "empty".

      In C, NULL mostly means "zero" but is often used for "missing" which might represent "undefined". In SQL, NULL means "not present" which is close to "undefined". The this built-in confusion on what "null" means could easily spread to confusion on what "undefined" means.

      If you called your bank and asked for balance and they said "I don't know; the computer system is down for maintenance and I can't look it up right now", then that would be getting a balance of "undefined" (or "unknown"). This is much different than a balance of "zero". Surely you can see that.

      So it appears that you do have a problem understanding a couple of those terms.

      - tye        

      A reply falls below the community's threshold of quality. You may see it by logging in.