|
Re^2: Weird behavior of int()
by hossman (Prior) on May 20, 2024 at 21:58 UTC
|
I echo this confusion ... in particular, what confuses me the most is: what is the point of the +0 ?
In what situation do you (intentionally) want/get a different result from int($str+0) vs int($str) ???
As an aside, your regular expressions would be better written as ...
I don't believe the OP is saying they intend to replace the int(...) with a regex, I believe they are assuming int(...) is implemented via a regex?
The key reason why int("information") returns Inf is because of the intended usage of the function, per the docs...
int EXPR
int Returns the integer portion of EXPR. If EXPR is omitted, u
+ses $_.
...
...the key word being "portion". The If you give it a scalar, it's going to consume as much of that scalar as it can to produce an integer:
$ perl -le 'print int("32hike")'
32
| [reply]
[d/l]
[select] |
|
|
| [reply] |
Re^2: Weird behavior of int()
by NERDVANA (Priest) on May 21, 2024 at 02:30 UTC
|
I fully accept the part about "info"+0 = Inf, but the part I'm not liking with these examples is that the output of int is still a floating point value, without a warning.
use warnings;
say int(1e400); # "Inf\n"
It seems like the contract of int() should always return an integer, or maybe undef. Inf and NaN ought to give warnings at least.
| [reply]
[d/l]
[select] |
|
|
Unfortunately that just isn't the way perl defines things. Perl has no distinction between float/int - not even when int() function is used. Perl scalars essentially have 3 basic flavours: number/string/reference.
Inf and NaN are valid numbers in perl, and int() returns a number. Hence why they don't see anything wrong with int() returning Inf/Nan.
The perl doc for int() not even mentioning inf/nan is another example of how un-user friendly perl is, and IMO is one of the reasons why perl is dieing out.
| [reply] |
|
|
| [reply]
[d/l] |
|
|
Hence why they don't see anything wrong with int() returning Inf/Nan.
Are you thinking that int($x) should always return an IV ?
It will only ever return an IV if $x, having had its fractional part removed, then fits into an IV.
The int() function does not alter the values of Infs or Nans, and the values of int(NaN) and int(Inf) are not within that IV range - as too, is the case with (eg) int($x) for all $x > 2 ** 64.
In all of those cases, int() returns an NV.
Cheers,
Rob
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
|
|
Unfortunately that just isn't the way perl defines things. Perl has no distinction between float/int - not even when int() function is used. Perl scalars essentially have 3 basic flavours: number/string/reference.
Inf and NaN are valid numbers in perl, and int() returns a number. Hence why they don't see anything wrong with int() returning Inf/Nan.
That's not correct. Perl internals *do* distinguish between signed/unsigned ints, floats, and strings. Aside from internals, there *isn't* a distinction between numbers and strings, but every perl operator gets to decide how it will coerce its input, and the operators do generally fall into categories of "number operators" and "string operators", but nothing forces that convention.
Against that backdrop, and the existence of the "use integer" pragma, I would expect a function named "int" to always cast its argument to an integer, or maybe 'undef' for failures.
perl -E 'my $x= "NaN"; say $x+0; say int($x); { use integer; say $x+0
+}'
NaN
NaN
0
I sincerely doubt this has anything to do with perl's decline. JavaScript and PHP have ten times as many shoddy API edge cases. | [reply]
[d/l] |
Re^2: Weird behavior of int()
by cLive ;-) (Prior) on May 26, 2024 at 20:15 UTC
|
There's no practical issue in normal code, but it behaves in a way that feels unintuitive. I have never used NaN or Inf in code, and never would. I would be using Math::BigFloat for anything that odd.
I guess the part that I don't like is that NaN and Inf are valid return values, more than anything. Neither are integers - though I also realize we can't change how int works, it feels very unintuitive.
The +0 was a quick hack I would use to coerce a string into a number - in lieu of $num =~ /^\d+$/ or $num=0 for untainting - I didn't know Inf and Nan were valid integers in Perl until last week (one of those things I thought I knew but had just never encountered - this is up there with when I first head about using _ in code :D
I can live with NaN+0=NaN<code> and <code>Inf+0=Inf, but I really do think int('information') should be zero rather than Inf!
| [reply]
[d/l]
[select] |
|
|
I can live with NaN+0=NaN and Inf+0=Inf..
It's just a matter of understanding the process.
If you can accept that '42.31' + 0 is 42.31 and '42.31ormation' + 0 is 42.31 and 'inf' + 0 is Inf, then it makes perfect sense that 'information' + 0 is Inf.
Then, once you understand that the int() function merely chops off the fractional part of its argument, there's not much left to puzzle over, AFAICS.
This process that perl is using to numify strings is the same as that used by the strtod() function in the C programming language.
I think it's a fairly standard process across many programming languages.
It's not about to change any time soon.
Cheers,
Rob
| [reply]
[d/l]
[select] |
|
|
Look at the official documentation:
"Returns the integer portion of EXPR"
That's incorrect and vague
- NaN and Inf are not integers
- What does 'integer portion' actually mean? It's not defined, so one could read that to mean that the integer portion of eee5 is 5
At the very least, this documentation needs fixing - even if the underlying code is not getting touched.
| [reply]
[d/l] |
|
|