in reply to A discriminating sort (and some damned lies)

I consider the differences between 'use_eq' and 'use_return' to be inconsequential. The hash version can be explained by the hash lookups required. This version also lets you use an arbitrary number of 'last' items, though. I would also use exists over defined.
  • Comment on RE: A discriminating sort (and some damned lies)

Replies are listed 'Best First'.
RE: RE: A discriminating sort (and some damned lies)
by arturo (Vicar) on Nov 03, 2000 at 20:12 UTC

    Yeah, obviously the difference isn't huge by any measure. The return s perhaps offer that minimal speed gain by potentially decreasing the number of operations in the sorting sub.

    Re: exists vs. defined. Clearly these test for different things (for onlookers, whether a key exists in a hash, and whether the value in the hash corresponding to the key has been defined), and there are obviously contexts in which it would be an error to confuse them. But if you keep a tight rein on your hash (as was done in the code above), there's no functional difference here : $last{"not other"} fed to either function is going to return a false value. I suppose that forcing you to keep a tight rein on your hash could be your worry, but if your code (not Fastolfe in particular, of course!) is creating hash keys that you're not aware of, you're probably in trouble anyway =)

    Or am I missing something? (does, e.g. calling defined $hash{$key} create an entry for $key in $hash)?

    Philosophy can be made out of anything. Or less -- Jerry A. Fodor

      Calling defined for a hash key doesn't create anything.

      There is a subtle difference internally between exists and defined. With exists, all Perl has to do is see if there's an entry in the hash table for that item. With defined, that value has to be inspected:

      Benchmark: timing 1000000 iterations of defined, exists... defined: 21 wallclock secs (21.36 usr + 0.00 sys = 21.36 CPU) exists: 19 wallclock secs (18.45 usr + 0.00 sys = 18.45 CPU)
      Using code like this:
      # %hash is a hash with values for one/two/tre/for sub t_exists { 1 if exists $hash{one}; 1 if exists $hash{two}; 1 if exists $hash{tre}; 1 if exists $hash{for}; 1 if exists $hash{xxx}; 1 if exists $hash{xxy}; 1 if exists $hash{xxz}; 1 if exists $hash{xyx}; } ...
      Granted, that's a million iterations, and the difference is only a couple of seconds. Hardly worth arguing over, but it's just a difference in the way of thinking about hashes.. In my head, what I'm looking for is the presence of a certain key in the hash (exists), not whether or not the value for that key in the hash is defined. You're right that functionally they're equivalent in this case.