Re: Re: Counting keys with defined or undefined elements in a hash

[shemp]

I must agree that many people dont understand (that there exist) limitations of algorithmic efficiency. For Perl programmers, this could be particularly predominant because Perl has so many cool built-ins. Often we forget that something powerful like grep or map still is O(n) when iterating thru an array. There are many other subtle (to the uninitiated) things Perl does that are oft overlooked, such as that foreach creates an anonymous array of what is being iterated over. But, this particular one is mentioned over and over in most Perl literate.
Update: My old school perl is showing, foreach does not create a copy of the list. (thanks to jsprat for pointing this out to me)

In any case, i think that most people learn the portions of a language that are necessary to the task at hand, and later on (maybe) pick up the bits and pieces in between. We're all probably there to some extent, in fact i have been for a while now trying to figure out how to best find and fill some of the holes in my perl knowledge. (I've been programming Perl since 1994.)

Anyway, I think this would be a good discussion that may want to be moved to meditations.

Also, to again plug my tied hash solution to the problem, the tie should be only a few lines of code (50ish ?), and once programmed, the run time penalty for hash modifications should only add a few percent (like 5%) to the overall time of hash operations. I have not benchmarked this tie, as i havent written it, the estimate is from my experience from other simple ties that ended up with small performance penalties. shemp