in reply to when do i know that the iterator for a hash was reseted

Why use an iterator when you can go straight to the horse's mouth? Try exists on the string and if you miss, try exists on a lower-case version of the string?

use strict;

sub find_inB {
    my ($data_hr, $string) = @_;
    my $no_result = 'no result';
    return (
        exists $$data_hr{ $string }
            ? $$data_hr{ $string }
            : exists $$data_hr{ lc $string }
                ? $$data_hr{ lc $string }
                : $no_result
    );
}

sub look_for_dataB {
    my %hash = map { ($_, 'xxx'); } qw( A B C D );
    print "D: " . find_inB(\%hash , 'D') . "\n";
    print "A: " . find_inB(\%hash , 'A') . "\n";
    print "B: " . find_inB(\%hash , 'B') . "\n";
    print "B: " . find_inB(\%hash , 'B') . "\n";
}

print "# look_for_dataB:\n";
look_for_dataB();

__END__
# look_for_dataB:
D: xxx
A: xxx
B: xxx
B: xxx

[download]

Replies are listed 'Best First'.
Re^2: when do i know that the iterator for a hash was reseted
by rminner (Chaplain) on Apr 21, 2006 at 09:36 UTC
    well - for example this doesn't help if i don't know the case of the key-string, as i won't be trying all possible permutation of a String sTring stRing strIng STrING with an exists statement ...

    Also it doesn't help me, when my hashkey is of type "What_I_am_looking_for Irrelevant_String", then exists also won't help me, as i don't necessarily know what the string Irrelevant_String is.

    My Problem isn't that i am not finding the data in the hash, i was primarily confused by the behaviour of each which was caused by my lack of knowledge of the way it behaves.

    (Posted it in part, in case sbd else has the same problem, so he can find the answer on the net).
[reply]
      True, though I was keying off your line which merely required

      if (lc($name) eq lc($string)) {

      [download]
      I'd say the thrust is still valid, though, assuming you are the one constructing the hash in the first place. That is, why not, at the point you create the hash key, normalize it to lowercase with:

      my %hash;
my $next_key = 'What_I_am_looking_for Irrelevant_String';
my $data_for_next_key = 'xxx';

$hash{ lc $next_key } = [ ($next_key, $data_for_next_key) ];

print
    "Value associated with '$next_key' is '",
    $hash{ lc $next_key }->[1],  # or $hash{ lc $next_key }[1]
    "'\n";

      [download]
      and now a test for exists would only even have to test for a lower-case version of the string_in_question. If your hash is at all sizeable, I'd think that using a little extra RAM to store the original key would be beneficial: you could avoid iterating through the keys every time you need to do this check.

      This assumes that you don't have duplicate entries because of case, i.e. it will have to be okay that $hash{ aBc } clobbers $hash{ ABC }.

[reply]
[d/l]
[select]
        We are experiencing communication problems :)

        Thanks for all the time you took to show me some alternatives. The thing is: the reason why i posted isn't how to find a hash element, but that i had a problem with the use of &each, which i wanted to share with the rest, in case there are more out there who don't understand its correct use.

        I already use those lowercased keys in diffrent parts of my programm, but in this case i refrained from using it, as this hash is generated by a general purpose parser, which i don't want to modify as it also is used in other sections of the programm. I also don't want to create an additional hash with the data reorderd in a diffrent way, as i already have about 10hashes in this subroutine alone, with data from diffrent files/subroutines which i have to compare inside this routine. Also, this function is called only for rare exceptions, and the amount of keys on the first hirarchy level of my nested hash has never more than 10 elements ... (i am comparing the keys of that first level) .

        Plus the Problem what i tried to explain to you before, that i don't know the values which Irrelevant_String might asume - its not fixed, and not under my control. It might be banana , gwbush, horse or Xzadd##fasdafa33. Like that i can't use exist. Of course i might create a new hash which has What_I_am_looking_for lowercased and Irrelevant_String trimmed from it as the new key and the original key stored in the array-ref as you showed in your above example. But that would be another hash, and in my case not worth the overhead (called seldomly).

        As you probably aren't a telecommunication-telepath you couldn't know that. I just wanted to clarify, that this "finding the hash key" wasn't the central part of this node, but the reseting and not_reseting of the hash iterator, when one leaves a while-each loop through use of last or return, as this behaviour wasn't clear for me.
[reply]

In Section Seekers of Perl Wisdom