Perl stopped using atof ...
Oh ... thanks for the correction.
It all still looks pretty weird to me on linux:
$ perl -le 'print "infantile paralysis" + 0'
inf
$ perl -le 'print "nanny goat" + 0'
nan
I feel no strong desire to port that type of behaviour to non-POSIX platforms :-)
Cheers,
Rob | [reply]
[d/l] |
$ perl -wle'print "infantile paralysis" + 0'
Argument "infantile paralysis" isn't numeric in addition (+) at -e lin
+e 1.
inf
or even:
$ perl -le'use warnings "FATAL"=>"numeric"; print "infantile paralysis
+" + 0'
I guess I'd like to know more about where you are finding this problematic.
I don't quite get why you'd be taking arbitrary strings and numericizing them.
| [reply]
[d/l]
[select] |
I'd like to know more about where you are finding this problematic
I think it's laughable that the strings "nanny goat", "infantile paralysis", and "anal retentive" should all take on quite different values when used in a numeric context. That's about all there is to *that* aspect of my posts in this thread. (I was quite serious however, about not feeling the need to port that behaviour to Windows.)
The problematic aspect is just that there's a difference between nix and windows - but that can be worked around. The real *annoyance* is that, sometimes, the workaround is not so simple. And one often has to wend one's way through a series of obstructions to get there (and I still haven't got there, btw). In this particular case, I was looking at a piece of code in one of the Math::GSL tests:
'gsl_sf_gamma_e(-1,$r)' => 'nan',
The function (key) on the left hand side will return a nan, and somehow that test passes on linux. But on windows it fails. First thought is that's because the stringification of a nan on Windows isn't 'nan' - so you replace the right hand side with '1.#QNAN', since that *is* the stringification of the nan returned by gsl_sf_gamma_e(-1,$r) on Windows.
But that doesn't work either, because, although 'nan' numifies to a nan on linux, '1.#QNAN' numifies to 1 on Windows. So, you now realise that test will succeed on all platforms only if the rhs is replaced with something (eg a variable) that actually is a nan on all operating systems. It happens that the Math::GSL module has such a variable. The test passes on all platforms if it is rewritten as:
'gsl_sf_gamma_e(-1,$r)' => $GSL_NAN,
But, having submitted a patch to effect that change, you find that, on each subsequent update of the git source, the author has kept silently ignoring that particular patch. Eventually you come to the conclusion that he really *does* want to test:
'gsl_sf_gamma_e(-1,$r)' => 'nan',
and the only thing to do is to have that test skipped on windows.
But the tests are being run in an arcane testing environment (Test::More, Test::Builder, Test::Class) and, while Test::Builder::skip_all() works fine, Test::Builder::skip() apparently does not. (At least I think that's the problem ... I haven't checked thoroughly yet ... I'll get back to it when I finish this post.) All of this because someone decided it would be a great labour saving device to have atof/strtod convert any string beginning with "nan" to a nan.
Yes - I don't have to do this. But I also don't have to approve of every half-arsed decision that has ever been made.
One also wonders about the Pandora's Box that is opened by this 'orrible nan/inf handling. On linux, both "nan" and "nano" are numified to a nan. But, while gsl_isnan("nan") returns true, gsl_isnan("nano") is an error. Seems strange, looks like a bug .... doesn't affect Windows, but ;-)
Cheers,
Rob | [reply]
[d/l]
[select] |