Re^2: Comparing hash data

This is wrong. Very wrong. Testing each value against every other value in the other hash? So, for hashes with n keys, you're going to have at least (n-1)^2 cases where $v1 ne $v2 - and that's if they match. NAME may not match EMP_NAME, but it definitely won't match EMP_PHONE, EMP_AGE etc, so why test it?

Only n matches need to be made - assuming you can map the keys across the hashes correctly (my guess is below on this one).

I think you misunderstood the question.

cLive ;-)

Comment on Re^2: Comparing hash data

Replies are listed 'Best First'.
Re^3: Comparing hash data by The_Rabbit (Acolyte) on Oct 01, 2004 at 20:21 UTC
You are totally right I am not sure what I was thinking when I wrote that. When I saw your post I smashed my head against the keyboard. I've had a long day...	[reply]
Re^3: Comparing hash data by Grygonos (Chaplain) on Oct 01, 2004 at 20:56 UTC
correct.. but without making assumptions about the "beginning" of a key we can't truly know how to properly map key to key. I agree it's inefficient.. however it was the only way I saw (well agreed with actually) to do it without making assumptions. Grygonos	[reply]
Re^4: Comparing hash data by cLive ;-) (Prior) on Oct 01, 2004 at 21:27 UTC
Even if you don't know the beginning of the key, this way is completely useless at trying to map values to values even. It's testing every value against every value, with no references to keys, so how on earth are you going to be able to tell which keys are csv/sql pairs from this? My quick hack solution assumes you know the keys. Even if you don't, it would be trivial use a regular expression to map them across. However you do it though, the point is to check the corresponding values of key pairs, not compare one value against all possible values in the other hash. cLive ;-)	[reply]
Re^5: Comparing hash data by Grygonos (Chaplain) on Oct 02, 2004 at 02:42 UTC
You're right.. you won't.. you'll just know that a problem exists. Sorry I would (personally) hate to make an assumption based on the OP's comments and lead them wrong. Your solution does work..assuming everything starts with "EMP"..but my assumption (see!? hehe) was that EMP stood for employer (in my line of work that's a common abbrev... I don't know if that's standard or not)..so I believed that all the fields would not in fact begin with that. It really doesn't matter .. your solution works under that assumption and it is a good solution...however I just want to make sure the OP gives us good info so we can help it understand what we reccomend.. /ramble off Grygonos	[reply]