Weird excel parsing problem

reaper9187 has asked for the wisdom of the Perl Monks concerning the following question:

hi people...
Back again to seek you wisdom and guidance on a particularly weird and frustrating problem... SO here goes...

I'm trying to compare the elements of an array with each cell of an excel sheet and print the one that matches... i know this looks pretty simple .... But i've been facing a weird problem:
when i print the array and the cell individually , i can easily make out the similar values,.. but when i compare the values,the code doesnt seem to realize it .. it jus treats it as a different element(eg it treats 1 and 1 as diff). I've been using strict , warnings and diagnostics.. but none seem to find any error...
i've tested the rest of the code.. the trouble some part is given below:

 foreach $ray(@cellr)
    {
        if($ray eq $worksheet->{Cells}[$row][1]->{Val} )
        {
        
        print "$ray :yes\n";
         }
         else
         { 
             next;
        
         }
     }
[download]

Easy enough right ..??? Now there is a another way(comparatively difficult and inefficient ) by means of pattern match but i dont want to go there.. Help please..!! i dnt think its a problem with the files coz i am able to read and print the values perfectly.. its the comparison (for some reason) thats starting to bug me nw ...Any ideas what can cause such a problems ?? THanks.!!

Comment on Weird excel parsing problem Download Code

Replies are listed 'Best First'.
Re: Weird excel parsing problem by BrowserUk (Patriarch) on Nov 05, 2012 at 18:54 UTC
Any ideas what can cause such a problems ?? You are almost certainly suffering from whitespace differences. Try printing both values like this: `print "'$ray' '$worksheet->{Cells}[$row][1]->{Val}'"; ## Pay special a +ttention to the quotes` [download] With this quoting, the issue should become obvious. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP Neil Armstrong	[reply] [d/l]
Re^2: Weird excel parsing problem by reaper9187 (Scribe) on Nov 05, 2012 at 19:04 UTC
It was a whitespace issue but only in some of the values .. Anyways its working fine now ... thnk you evryone for your prompt replies and valuable guidance .. it because of this that i love this place... :) sometimes the tiniest details matter the most .. Thanks everyone ,..!!!	[reply]
Re: Weird excel parsing problem by Kenosis (Priest) on Nov 05, 2012 at 18:45 UTC
If you're comparing numeric values, did you mean the following (`==` instead of `eq`)? `if($ray == $worksheet->{Cells}[$row][1]->{Val} { ...` [download]	[reply] [d/l] [select]
Re^2: Weird excel parsing problem by Tanktalus (Canon) on Nov 05, 2012 at 18:52 UTC
Not always. I found a bug trying to deploy JSON::XS on AIX 7 where '5e1' was deciphered by JSON::XS, and came out to 50.0000000007 or something. On other platforms, it worked fine. And this was basically because there's a bug in AIX 7's libm where rounding happens wrong or something. So anyway, when comparing with ==, they failed to match, but comparing with eq made it work (because perl stringified the number to 50, due to a lower precision). So what I'd do here is try to get more information about both $ray and each value and see if there's a mismatch at some higher precision, e.g., using `sprintf "%.15f", $ray` (and likewise for each value in the worksheet being compared against). That is for == failures. For eq failures, what I learned many many years ago was to put my debug in delimiters. I learned with `[...]`, so something like this: `print "ray = [$ray]\n"` to see if there are spaces. Even better to use Data::Dumper or something else that will not only use delimiters (often quotes) but also look for non-printables and convert them (e.g., tabs, nuls, etc.).	[reply] [d/l] [select]
Re^3: Weird excel parsing problem by afoken (Chancellor) on Nov 06, 2012 at 05:43 UTC
Not always. I found a bug trying to deploy JSON::XS on AIX 7 where '5e1' was deciphered by JSON::XS, and came out to 50.0000000007 or something. I don't think you found a bug. See http://en.wikipedia.org/wiki/Scientific_notation#E_notation for why 5e1 is just another number (that is read as 5.0E+1 or 5.0*10¹), and perlfaq4 or What Every Computer Scientist Should Know About Floating-Point Arithmetic for why you don't get just 50 as a result and why using == and != with floats just does not work. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^4: Weird excel parsing problem by Tanktalus (Canon) on Nov 06, 2012 at 13:59 UTC
Re^2: Weird excel parsing problem by reaper9187 (Scribe) on Nov 05, 2012 at 18:47 UTC
Its numbers like ABC123 , HYU785, etc.. when i use '==', it gives an error .. so i knw its not numeric for sure ..	[reply]
Re^3: Weird excel parsing problem by Kenosis (Priest) on Nov 05, 2012 at 18:52 UTC
Well, using `eq` makes sense with these strings. Are you detecting any whitespaces around the strings which may be interfering with the equality test?	[reply] [d/l]