this assumes that neither $string_or_number nor any of the elements of @strings_or_numbers are ever undef

It also makes other (corner case) assumptions. For example things get a bit dubious when the numbers (barewords) 1.4142135623730951, 1.4142135623730952 and 1.4142135623730953 (on a perl whose NV is double) are subjected to stringwise and numeric comparisons: 
use warnings;

my $x = 1.4142135623730951;
my $y = 1.4142135623730952;
my $z = 1.4142135623730953;

print "$x $y $z\n";

$x == $y ? print "x and y are numerically equal\n"
         : print "x and y are numerically unequal\n";

"$x" eq "$y" ? print "x and y are stringwise equal\n"
             : print "x and y are stringwise unequal\n";

$z == $y ? print "z and y are numerically equal\n"
         : print "z and y are numerically unequal\n";

"$z" eq "$y" ? print "z and y are stringwise equal\n"
             : print "z and y are stringwise unequal\n";

__END__

Outputs:

1.4142135623731 1.4142135623731 1.4142135623731
x and y are numerically equal
x and y are stringwise equal
z and y are numerically unequal
z and y are stringwise equal

[download]
So it makes the assumption that this behaviour is as wanted - which, if you look closely, is rather unlikely.
Perhaps (not guaranteed) the first two results are as wanted - even though the two barewords are mathematically unequal they do convert to identical doubles and strings.

But the last 2 results are just bizarre, imo.
That perl should stringify two different NVs to the same string is rather pathetic - and it happens because perl by default stringifies doubles to only 14 decimal digits. (Update : make that 15, not 14 - the trailing zero for my example values was stripped.)
If, like in python, the default was 17 decimal digits (as some believe it should be) then the discrepancy of the last 2 results would not arise.
(We can, of course work around this stringification problem using sprintf, but that just makes it messy.)

BTW, the same problem arises with perls whose NVs are 'long double' or '__float128'.
Perl simply does not stringify floating point values to enough decimal digits.

Cheers,
Rob

In reply to Re^2: Filtering array of strings and numbers by syphilis
in thread Filtering array of strings and numbers by nysus

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.