Closed p5pRT closed 8 years ago
p5pRT
commented
14 years ago Perlsyn states:
Num numish[4] numeric equality $a == $b
Thus the smartmatch.t tests:
! 2 "2bananas" ! 2_3 "2_3"
Should not expect failure since 2 == "2bananas" and 2 == "2_3" yet for some reason (2 ~~ "2bananas") != 1
If "2bananas" is numish enough for every other operator in perl\, but not smart match\, that seems rather unsmart.
p5pRT
commented
14 years ago Additional evidence of inconsistency\, the following test:
[qw(1foo 2bar)] 2
i.e; (qw(1foo 2bar)] ~~ 2) == 1 but (2 ~~ "2bananas") != 1 ?!
-- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Prickle-Prickle\, the 62nd of The Aftermath\, in the YOLD 3175: Alternative smock. --JP
p5pRT
commented
14 years ago On Sat\, Dec 19\, 2009 at 9:37 PM\, Jerrad Pierce \belg4mit@​pthbb\.org wrote:
Additional evidence of inconsistency\, the following test:
\[qw\(1foo 2bar\)\] 2i.e; (qw(1foo 2bar)] ~~ 2) == 1 but (2 ~~ "2bananas") != 1 ?!
No it doesn't.
perl -lE"say( ( [qw(1foo 2bar)] ~~ 2 ) ?1:0 ) 0
Are you sure you're using 5.10.1?
p5pRT
commented
14 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
14 years ago On Sat\, Dec 19\, 2009 at 6:19 PM\, belg4mit@pthbb.org (via RT) \< perlbug-followup@perl.org> wrote:
If "2bananas" is numish enough for every other operator in perl\,
Really? Every operator I tried told me it wasn't numeric.
perl -wE"my $x = 3 * '2bananas'" Argument "2bananas" isn't numeric in multiplication (*) at -e line 1.
perl -wE"my $x = 3 + '2bananas'" Argument "2bananas" isn't numeric in addition (+) at -e line 1.
perl -wE"my $x = 3 | '2bananas'" Argument "2bananas" isn't numeric in bitwise or (|) at -e line 1.
So argument is because the value becomes two when treated as a number\, it's numish? Given that every value can be converted to a number\, that would mean that all values are numish.
perl -wE"say 3 + '2bananas'" Argument "2bananas" isn't numeric in addition (+) at -e line 1. 5 # Treated as 2
perl -wE"say 3 + 'bananas'" Argument "bananas" isn't numeric in addition (+) at -e line 1. 3 # Treated as 0
perl -wE"say 3 + ['abc']" 2329375 # Treated as 2329372
Perl uses the same test it uses everywhere\, looks_like_number:
perl -MScalar::Util=looks_like_number -E"say looks_like_number('2bananas')||0" 0
p5pRT
commented
14 years ago Are you sure you're using 5.10.1? No\, 5.10.0
Okay\, so that inconsistency is gone\, but ~~ behavior still clashes with documentation Re: numify -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Prickle-Prickle\, the 62nd of The Aftermath\, in the YOLD 3175: Alternative smock. --JP
p5pRT
commented
14 years ago * belg4mit@pthbb.org (via RT) \perlbug\-followup@​perl\.org [2009-12-20 04:05]:
Perlsyn states:
Num numish[4] numeric equality $a == $b
Thus the smartmatch.t tests:
! 2 "2bananas" ! 2_3 "2_3"
Should not expect failure since 2 == "2bananas" and 2 == "2_3" yet for some reason (2 ~~ "2bananas") != 1
If "2bananas" is numish enough for every other operator in perl\, but not smart match\, that seems rather unsmart.
This is not a bug. The documentation says “numish”\, not “can be converted to a number”.
Every scalar can be converted to a number so that would be a meaningless thing to say anyway.
And if the operator worked that way\, then `0 ~~ 'pink monkeys'` would also have to succeed. That would be far less smart.
You can get what you want by using `2 ~~ (0 + '2bananas')` instead.
Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>
p5pRT
commented
14 years ago Sorry\, I never received this message\, but just found it when revisiting the conversation in RT.
On Sat Dec 19 23:23:44 2009\, ikegami@adaelis.com wrote:
On Sat\, Dec 19\, 2009 at 6:19 PM\, belg4mit@pthbb.org (via RT) \< perlbug-followup@perl.org> wrote:
If "2bananas" is numish enough for every other operator in perl\,
Really? Every operator I tried told me it wasn't numeric. It *warned* that it wasn't\, but it still did the operation. I'd perfectly happy if C\<2 ~~ "2bananas"> emitted a non-numeric warning\, but still returned true.
Else\, the documentation needs to be updated.
I still think the current behavior is less smart than it could be\, but it could go either way and breaking from established is not to be entered into lightly.
p5pRT
commented
14 years ago Interjecting this previously sent message in case it gets lost in the ether\, as perl.org's mail server/RT seems to be having some issues... Eric's previous message Re: warnings\, as well as Aristotle's never got to me\, and my reply to an off-list response at Sun\, 20 Dec 2009 04:49:57 -0500 about the consistency remaining in 5.10.1 below\, hasn't been logged...
On Sun\, 20 Dec 2009 14:41:12 -0500 Eric Brine wrote:
Numish\, not numifable. Everything is numifiable That is a distinction which is not made in the documentation\, and that I contend is counter-intuitive since it violates the "Matching code" of C\<$a == $b> with the foot note:
4 - either a real number\, or a string that looks like a number
That's not the same thing as:
A string containing only a number that would be returned from the string if eval'd* e.g; "2.0" and not strings that are treated as numbers by other perl operators e.g; "2bananas"
so it would be useless. No\, it would just be different.
C\<2 ~~ "2bananas"> would be true but C\<2 ~~ "0 but true"> would still be false
* Addendum: A rough pass at clearly documenting the behavior\, but we clearly wouldn't want "return 2" or "5 -3" to smart match to 2.
p5pRT
commented
14 years ago A few other notes for completeness...
Quoth Aristotle:
And if the operator worked that way\, then `0 ~~ 'pink monkeys'` would also have to succeed. That would be far less smart. An interesting point.
Quoth I:
I still think the current behavior is less smart than it could be\, but it could go either way and breaking from established is not to be entered into lightly. Although apparently ~~ has changed from 5.10.0 to 5.10.1 \<http://search.cpan.org/~dapm/perl-5.10.1/pod/perl5101delta.pod#Smart_match_changes> and 5.10.1 does not pass its predecessor's tests:
not ok 1 - \&foo ~~ \&foo: #documented change? not ok 2 - \&foo ~~ \&foo: #documented change? not ok 5 - \&foo ~~ \&bar: 2 #documented change not ok 8 - sub{shift} ~~ 1: #documented change not ok 12 - sub{scalar @_} ~~ 1: #documented change not ok 14 - \&bar ~~ []: #documented change not ok 16 - \&bar ~~ {}: #documented change not ok 63 - +{foo => 1\, bar => 2} ~~ "foo": #commutativity failure not ok 74 - [qr/o/\, qr/a/] ~~ ["foo"\, "bar"]: #commutativity failure not ok 87 - [qw(1foo 2bar)] ~~ 2: not ok 88 - 2 ~~ [qw(1foo 2bar)]: not ok 100 - "2bananas" ~~ 2: 1 #commutativity failure! not ok 103 - qr/x/ ~~ "x": #commutativity failure not ok 108 - qr/3/ ~~ 12345: #commutativity failure not ok 109 - @nums ~~ 7: #commutativity failure not ok 119 - %hash ~~ "foo": #commutativity failure
p5pRT
commented
14 years ago On Sun\, 20 Dec 2009 14:41:12 -0500 Eric Brine wrote:
Numish\, not numifable. Everything is numifiable That is a distinction which is not made in the documentation\, and that I contend is counter-intuitive since it violates the "Matching code" of C\<$a == $b> with the foot note:
4 - either a real number\, or a string that looks like a number
That's not the same thing as:
A string containing only a number that would be returned from the string if eval'd e.g; "2.0" and not strings that are treated as numbers by other perl operators e.g; "2bananas"
so it would be useless. No\, it would just be different.
C\<2 ~~ "2bananas"> would be true but C\<2 ~~ "0 but true"> would still be false -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Prickle-Prickle\, the 62nd of The Aftermath\, in the YOLD 3175: Alternative smock. --JP
p5pRT
commented
14 years ago On Sun\, Dec 20\, 2009 at 3:01 PM\, Jerrad Pierce \belg4mit@​pthbb\.org wrote:
On Sun\, 20 Dec 2009 14:41:12 -0500 Eric Brine wrote:
Numish\, not numifable. Everything is numifiable That is a distinction which is not made in the documentation\, and that I contend is counter-intuitive since it violates the "Matching code" of C\<$a == $b> with the foot note:
4 - either a real number\, or a string that looks like a number
I seem to have forgotten the lesson on number 2bananas.
so it would be useless. No\, it would just be different.
I stand corrected. It wouldn't be useless. It would make
NUMBER NUMISH
into the undesirable
NUMBER ANY
C\<2 ~~ "2bananas"> would be true but C\<2 ~~ "0 but true"> would still be
false
I don't know how you can consider "2bananas" equivalent to 2 and "apple" equivalent to zero.
- ELB
p5pRT
commented
14 years ago As i see it there are two matters at hand:
1) Is whether ~~ should handle numish differently/better\, and if so how. I contend that it should/could. 2) If not 1\, that perlsyn should more clearly describe it's current behavior as something other than simply ==\, and I gave a (verbose) example.
I don't know how you can consider "2bananas" equivalent to 2 By the dox it should be\, since the pod says it's defined as == But like everything else it should heed C\<warnings 'numeric'> if changed to truly employ an == test so that C\<"2bananas" ~~ 2> is true.
and "apple" equivalent to zero. That was Aristotle's argument\, and I acknowledged it was valid that C\<qw/apple 4/ ~~ 0> should be false. However\, if non-numifiable strings were undef rather than zero (to ~~ when comparing to a number) then the previous statement would still be false\, but C\<qw/0apples 4/ ~~ 0> would be true. That shouldn't change anything else since ~~ reportedly uses defined on C\<"zebra" ~~ undef>.
p5pRT
commented
8 years ago While reviewing this older ticket\, I'm having some trouble deciding what other behavior is desired. Perlop defines "nummy" as "Either an actual number\, or a string that looks like one."\, changing that to perform numeric comparison on number ~~ string\, even for strings that are clearly not numbers\, seems problematic.
The code matches the documentation\, so I'm marking this as wishlist. However\, I also propose to mark this rejected.
-- Respectfully\, Dan Collins
p5pRT
commented
8 years ago On Fri Jul 22 09:13:01 2016\, dcollinsn@gmail.com wrote:
While reviewing this older ticket\, I'm having some trouble deciding what other behavior is desired. Perlop defines "nummy" as "Either an actual number\, or a string that looks like one."\, changing that to perform numeric comparison on number ~~ string\, even for strings that are clearly not numbers\, seems problematic.
The code matches the documentation\, so I'm marking this as wishlist. However\, I also propose to mark this rejected.
The behavior desired is for the operator to be implemented as described. When submitted\, the operator was not matching strings that look like one i.e; == and ~~ should give the same result for strings beginning with numbers. Perhaps things have changed in the interim\, but in the latest perl I'm using (5.22)\, this does not appear to be the case.
p5pRT
commented
8 years ago On Fri Jul 22 10:01:33 2016\, jpierce wrote:
The behavior desired is for the operator to be implemented as described. When submitted\, the operator was not matching strings that look like one i.e; == and ~~ should give the same result for strings beginning with numbers. Perhaps things have changed in the interim\, but in the latest perl I'm using (5.22)\, this does not appear to be the case.
This ticket arises from the distinction between "string that looks like a number" (which is used by smartmatch) and "string that can be coerced to a number" (which is the set of all perl strings). Per the perldoc perlop section on smartmatch\, Num ~~ nummy is defined as numeric equality\, where "nummy" is defined as "either an actual number\, or a string that looks like one".
This is consistent with the only other use of "looks like" a number in perlop:
Unary "-" performs arithmetic negation if the operand is numeric\, including any string that looks like a number...If\, however\, the string begins with a non-alphabetic character (excluding "+" or "-" )\, Perl will attempt to convert the string to a numeric\, and the arithmetic negation is performed. If the string cannot be cleanly converted to a numeric\, Perl will give the warning Argument "the string" isn't numeric in negation (-) at ....
perl -wle 'print -"2banana"' Argument "2banana" isn't numeric in negation (-) at -e line 1. -2
In other words\, 2 doesn't "look like" a number\, so it gets the warning\, but perl is still able to convert the string to a numeric. On the other hand\, the smartmatch operator makes no promise about handling strings that don't look like a number but that can be converted to one - they would be covered under the "Any ~~ Any" case\, which is defined as string equality.
-- Respectfully\, Dan Collins
p5pRT
commented
8 years ago @dcollinsn - Status changed from 'open' to 'rejected'
Migrated from rt.perl.org#71452 (status was 'rejected')
Searchable as RT71452$