... another secret operator (the wrapping parentheses) ...

You have stumbled upon the secret operator known as operator precedence. In this case, there's no need for the disambiguation of grouping parentheses because the  =~ binding operator is of higher precedence than  <= or any other comparator.

c:\@Work\Perl\monks>perl -wMstrict -le
"sub not_too_many_dots { return $_[0] =~ tr/.// <= 1; }
 ;;
 for my $s ('', qw(.  ..  ...  ....)) {
   printf qq{'$s' %stoo many dots \n},
          not_too_many_dots($s) ? 'NOT ' : ''
          ;
   }
"
'' NOT too many dots
'.' NOT too many dots
'..' too many dots
'...' too many dots
'....' too many dots
[download]

Update 1: I suspect the speedup you're seeing is due to operating directly upon an element of the aliased  @_ subroutine argument array rather than burning the computrons needed to create lexical variables. See perlsub. (This would be in addition to using  tr/// rather than  m// for counting individual characters.)

Update 2: If you want to know what Perl thinks about the precedence and associativity of the operators you're using, use the O and B::Deparse modules. The  -p flag produces full, explcit parenthetic grouping. (The useless assignments just produce some more grouping examples.)

c:\@Work\Perl\monks>perl -wMstrict -MO=Deparse,-p -le
"sub not_too_many_dots { return $_[0] =~ tr/.// <= 1; }
 ;;
 for my $s ('', qw(.  ..  ...  ....)) {
   my $g = my $f = not_too_many_dots($s);
   printf qq{'$s' %stoo many dots \n}, $f ? 'NOT ' : '';
   print $g;
   }
"
BEGIN { $^W = 1; }
BEGIN { $/ = "\n"; $\ = "\n"; }
sub not_too_many_dots {
    use strict 'refs';
    return((($_[0] =~ tr/.//) <= 1));
}
use strict 'refs';
foreach my($s) (('', ('.', '..', '...', '....'))) {
    (my $g = (my $f = not_too_many_dots($s)));
    printf("'${s}' %stoo many dots \n", ($f ? 'NOT ' : ''));
    print($g);
}
-e syntax OK
[download]

AnomalousMonk, re the speed up, I test using a loop, and to make it apples to apples, one version uses only regex to determine the numeric quality, and the other uses only tr/ + length.

AT 10k iterations, for a full valid number, the regex only version takes about 0.02 seconds, and the tr length version takes about 0.008 seconds. So i have to take back the 4x faster for tr y length, it's about 2.5x faster, because I had to add in a few more conditions to handle the length tests that failed for pre perl 5.012. Neither version is assigning any values to a variable. Since most things being tested are valid, this speed up is significant, albeit trivial in the larger sense.

That's for a full successful match, the times are of course less if it fails, though the order of the sequence of tests matters. I have bunch of variants of the below, but these roughly are apples to apples. Note that if I could have used only length($_[0]) instead of defined and length, that knocks a noticeable percent off the total, but as I learned, that test only became possible in Perl 5.012.

return 1 if (defined $_[0] && $_[0] =~ /^[\d\.]+$/ && $_[0] =~ /\d/ &&
+ ( () = $_[0] =~ /\./g ) <= 1);
return 1 if ( defined $_[0] && length($_[0]) == ($_[0] =~ tr/012345678
+9.//) && ( $_[0] =~ tr/0123456789//) >= 1 && ($_[0] =~ tr/.//) <= 1);
[download]

Generally the things I spend time testing and optimizing are core methods and tools that might actually knock milliseconds off execution time, which is something not super visible on new hardware, but quite noticeable on very old systems, low powered ARM devices, and so on. But I also like finding ways that are simply faster and more efficient in general, since the little things add up.

In both cases however the tests are much better than what I was using, since that allows non numeric numbers (/^[\d\.]+$/) like ..4.3. so both are improvements, but the tr version is roughly as fast as the original single but inaccurate regex, and is accurate. Thanks for the pointer to tr/ I would not have thought that ended up returning how many things it had found.

It was not so much the precedence that I discovered, but the fact that these tests actually also return a count of how many instances were replaced, for tr, or returned to fill an array that could then be counted as the total result of the statement that was something I was only faintly aware of as something that Perl does. I had used this feature without thinking much about it with things like if ($a = returns_something_or_nothing())... but I hadn't actually thought of that as a general principle that can be used for other things.

Just out of curiosity, a couple more variations. Note that Scalar::Util::looks_like_number() thinks things like  +1  -1  2e3 look like numbers that you may not want to accept.

c:\@Work\Perl\monks>perl -wMstrict -le
"use Scalar::Util qw(looks_like_number);
 ;;
 use Data::Dump qw(pp);
 ;;
 for my $n (
   undef, '', '.', '..', '.1.', '1..1',
   0, '0', '0.', '0.0', '.0', '000.000',
   1, '1', '1.', '1.0', '001.100',
   '+1', '-1', '2e3',
   ) {
   printf qq{%s %s like num \n}, pp($n),
     looks_like_number($n) ? 'looks' : 'does not look';
   }
"
undef does not look like num
"" does not look like num
"." does not look like num
".." does not look like num
".1." does not look like num
"1..1" does not look like num
0 looks like num
0 looks like num
"0." looks like num
"0.0" looks like num
".0" looks like num
"000.000" looks like num
1 looks like num
1 looks like num
"1." looks like num
"1.0" looks like num
"001.100" looks like num
"+1" looks like num
-1 looks like num
"2e3" looks like num

c:\@Work\Perl\monks>perl -wMstrict -le
"sub unsigned_real {
   return defined($_[0])
       && $_[0] =~ m{ \A (?: \d+ (?: [.] \d*)? | \d* [.] \d+) \z }xms
        ;
   }
 ;;
 use Data::Dump qw(pp);
 ;;
 for my $n (
   undef, '', '.', '..', '.1.', '1..1',
   '+1', '-1', '2e3',
   0, '0', '0.', '0.0', '.0', '000.000',
   1, '1', '1.', '1.0', '001.100',
   ) {
   printf qq{%s %s real \n}, pp($n),
     unsigned_real($n) ? 'looks' : 'does not look';
   }
"
undef does not look real
"" does not look real
"." does not look real
".." does not look real
".1." does not look real
"1..1" does not look real
"+1" does not look real
-1 does not look real
"2e3" does not look real
0 looks real
0 looks real
"0." looks real
"0.0" looks real
".0" looks real
"000.000" looks real
1 looks real
1 looks real
"1." looks real
"1.0" looks real
"001.100" looks real
[download]

If the speed of any of these is acceptable, you will, of course, develop your own Test::More test suite(s). (But you'll want to do | you've already done that in any case. :)

---

Give a man a fish:  <%-{-{-{-<

G'day h2,

"... and ended up with a 4x (!) speed improvement ..."

You might like to take a look at "perlperf - Perl Performance and Optimization Techniques" which discusses this, amongst other things, and includes benchmarks.

While y/// and s/// are not always interchangeable, when they can provide the same functionality, I've generally found y/// to be measurably faster than s///.

I was lucky and discovered NTYProf quite early, so along with loop testing, I was able to get rid of major bottlenecks during development, which was and is kind of excellent. There's some optimization tricks I was not aware of in that perlperf page so those should help too, I've been using microtimers in loops which achieve the same result but I'll check out some of the other optimization tools, thanks. As noted above, sadly, the improvements once I made both test versions fully apples to apples turned out to be roughly 'only' 2.5x faster for tr and length vs regex. But equally obviously, anything that results in that big of a difference is worth understanding better, since usually you hope for 5, 10% improvements, not 250%.

"... roughly 'only' 2.5x faster ..."

Interestingly, if you look at the benchmark timings in the perlperf page:

$ perl -E 'say 2040816.33/840336.13'
2.42857144557143
[download]

But don't read too much into that: I consider it more of a curiosity than anything else.

"... anything that results in that big of a difference is worth understanding better ..."

Someone else may have a much better answer regarding the inner workings of these. My understanding is that the SEARCH part of y///, e.g. the 'w' in

$ perl -E 'say "xwz" =~ y/w/y/r'
xyz
[download]

is handled at compile time; whereas the equivalent part of s///, e.g. the 'w' in

$ perl -E 'say "xwz" =~ s/w/y/r'
xyz
[download]

is handled at runtime. I couldn't tell you exactly what "handled" equates to; maybe another monk can chime in with a more complete answer.

— Ken