No need to as Not a Number has done it for me ;-)>

Also significant is some application is that the run-times of map_to_hash and a binary search are constant over the solution set where as any of the iterators will be significantly faster/slower depending on $value. I was thinking all this as I was coding, and that is part of the fun of this whole programming business, but I was just trying to get something to run with some kind of relevance to the OP's question.

I find myself using grep or map more and more and almost never use the C style for() loop. I like the programming flexibility that mapping the indexes into a hash gives me even though that is the slowest as far as the run-times.

As an example, the run-times of my current project are almost totally dominated by the time required to seek to the files. I am just about finished rolling all the file accesses into their own loops using predominately greps and maps. Something like this only using a HOH

@file_handles = map  { some_code_to_open_files } @huge_filelist;
@wanted_files = grep { some_file_access } @file_handles;
@wanted_data  = grep { some_more_file_access } @wanted_files;
@return_codes = map  { close $_ } @file_handles;
[download]

This has the effect of eliminating a lot of nested parenthesis and makes the code look 'flat'. It also forces the procedural code outside of the loops and the data access code inside the loops. This drives the code naturally toward an OO style and will allow me to re-factor what was a <st>very</st> procedural script into OO code. What's more I've tested the results and the run-times are identical.

I don't claim credit for this approach. Most of this was not my own idea. I got the inspiration from reading "Intermediate Perl".