Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re: Weird excel parsing problem

by Kenosis (Priest)
on Nov 05, 2012 at 18:45 UTC ( #1002374=note: print w/replies, xml ) Need Help??

in reply to Weird excel parsing problem

If you're comparing numeric values, did you mean the following (== instead of eq)?

if($ray == $worksheet->{Cells}[$row][1]->{Val} { ...

Replies are listed 'Best First'.
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.).

        Except that, as you point out, we're referring to 5.0, and that is an exact number in binary, not like, say, 5.1. All of the numbers involved in that equation are representable exactly, even in floating point. On all platforms other than AIX7, 5e1 is deciphered to be 50, exactly. And IBM has a published bug report on this (they only publish bugs they accept and either have fixed or are planning to fix or acknowledge are bugs but cannot be fixed - rejected bug reports are not published). So I'm pretty confident it's an actual bug :-)

        But what you point out is true as a generality, which is why I was pointing out that == doesn't always work, depending on what you're comparing. Works best for pure integers, not so good in general for floating point (but if you have numbers that can be represented exactly, barring bugs like the above, it should work). So ++ for pointing out the part I should have made explicit as to why == doesn't always work.

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 ..

      Well, using eq makes sense with these strings. Are you detecting any whitespaces around the strings which may be interfering with the equality test?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1002374]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (13)
As of 2017-09-26 15:25 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (296 votes). Check out past polls.