Scalar::Util provides access to the underlying Perl API looks_like_number routine which Perl itself uses internally
Perl will evaluate the string (eg) '5621hello' in numeric context as 5621 ... yet looks_like_number() will tell you that the string '5621hello' does not look like a number. That has always struck me as an anomaly .... I tend to think that a a string that "does not look like a number" should evaluate to zero in numeric context, but that (obviously) doesn't always happen.
use warnings;
no warnings 'numeric';
use Scalar::Util;
$string = '12.3hello';
print Scalar::Util::looks_like_number($string), "\n";
$string *= 2;
print $string, "\n";
__END__
Outputs:
0
24.6
I don't think this is a big deal, btw - it's just that it doesn't DWIM (for me, anyway).
Cheers, Rob Update: I meant to add that this might even have some siginificance for the op - because we can't assume anything about the numeric value of a variable, based on the fact that Scalar::Util says it doesn't look like a number. | [reply] [d/l] [select] |
But you've turned off the warning telling you that it doesn't looks_like_number. If you don't have warnings on, Perl assumes you know what you're doing and tries to do what you've asked it to with the (crummy) numberish data you've given it. If you have enabled warnings, it lets you know about it's misgivings but still goes ahead and does what you've asked.
I think the expectation mismatch is because Perl uses the (POSIX) C strtod(3) which by design (or at least by the manual page description :) follows this heuristic (from the start of the char* passed parse off as many digits followed by an optional "." and more digits followed by an optional exponent notation, and stop when you hit a not-digit-not-plusminus-not-exponent-marker character) rather than using if-looks_like_number-number-else-it's-zero. This is mentioned in perldata in passing, but if you're not familiar with the C API I'll grant that it's certainly open to causing confusion.
| [reply] |
It used to use strtod, but doesn't any more. The C99 standard pulled the rug out from under everyone by changing e.g. "0x10" from being 0 (in C89) to being 16.
| [reply] |