/me too.

Why is it that you can never state your position without denigrating those who's opinion differs?

Others may allow you to get away with your unveiled ad homonym attacks and overbearing sarcasm, but whether they are aimed at me or others, I will call you on it every time.

I've explained my preference for my choice elsewhere in this thread, but nowhere have I attributed it to performance. The issue of performance is purely one of countering a bad benchmark. Nothing more.

Which makes "(but then you'd be forced to use %2 anyway because it'd be trivially faster, I bet)." nothing but another example of your overbearing sarcasm.

I'm shocked people can spend so much effort just trying to see if there is a speed difference between the two when it so clearly obvious (because it is so hard to even see a difference) that any difference that there is doesn't matter in the slightest.

Again. You attribute me with motives for which there is no basis. I didn't post the original benchmark. I simply drew attention to its flaws and cleaned it up.

even in fanciful extreme situations)

More denigration. Once again based upon nothing in this thread.

people who can't equate "even" with "divisible by two" with "has 0 remainder when divided by two" and are only comfortable with equating "even" with "has some bit unset"

Why use the word "comfortable"? It certainly isn't derived from anything I've said in this thread. Nor anything anyone else has said that I've read. Again, you attempt to make the arguments personal instead of technical. For what purpose?

Using &1 means that your code won't work when someone uses it with a perfectly valid Perl number that doesn't happen to fit in a UV.

If I use & 1 in my code, it is because I know that values I am applying it to are integers that will not exceed that range of values to which the application of bit-wise operators can be applied. That is a part of my job as a programmer.

If someone else comes along and takes that code and utilises it in a situation where that does not hold true, then it is their job as programmers to recognise that and adjust the code accordingly. (See below!)

If your argument is that I should not be aware nor care what storage format is used to represent numbers and should always code such that all operations can be applied to the full range of Perl's numeric representations, why does perl have bitwise numeric operations? There is no logical way they could ever be used in those circumstances!

You say "it always works great unless you have other problems, like using inappropriate storage for the numbers you are dealing with).", but how is using 

$n = 9_007_199_254_740_992; print 'Even' unless $n % 2;;
Even

[download]

"appropriate", but not 

++$n; print 'Even' unless $n % 2;;
Even

[download]
Are you asserting that it is a bug that 1e11 & 1 doesn't die (or fail in some other way)?

Yes.

Are you seriously suggesting that you would design a new language that silently converts 99_999_999_999 into 4294967295?

So, despite another piece of your sarcasm addressed to a straw man of your own construction "Or are you asserting that &1 should work directly on NVs?", that again appears nowhere else in the thread.

Yes, I am suggesting that perl's silent conversion of 99_999_999_999 into 4_294_967_295 is a bug. It may be a behaviour that will never change due to backward compatibility, but I cannot believe it was a deliberate design decision, and that makes it a bug.

The greater range that one method continues to work over (before again silently failing), is pretty irrelevant on two counts.

  1. For the great majority of applications that use oddness tests, the range of an IV or UV is more than sufficient. Think carefully about that statement, from the perspective of real code, rather than the hypothetical.

    If attempting to "future proof" applications by using NVs where we know IVs or UVs were more than sufficient was a good idea.

    • Why do we bother with IVs and UVs at all?
    • Why don't we use bignum in every script we write?
  2. Most importantly, if I have chosen to use & on a particular variable for this purpose--because I know it is sufficient for this purpose--then it's quite possible, even likely that I will have
    • used other boolean operations on that same variable for other purposes. 
      my( $loWord, $hiWord ) = ( $n & 0xffff, $n >> 16 );

      [download]
    • Or use pack or unpack on that variable. 
      print unpack 'N', pack 'N', 99_999_999_999;;
4294967295

      [download]
    • Or used (s)printf on that variable; 
      printf "%d\n", 99_999_999_999;;
-1

      [download]
    • Or used my knowledge of the size of that variable in some math somewhere. 
      my $indexSize = 4 * $noLines;

      [download]
    • Or any number of other operations that require that variable to be a 32-bit integer of one form or other.

    If I code a 'oddness' test on that variable using % 2 somewhere in the code, then I am asking for the next guy that comes along and sees that to assume that extending the range of use for that variable is safe. When I know it is not.

    This is the exact counter argument to your

    Using &1 means that your code won't work when someone uses it with a perfectly valid Perl number that doesn't happen to fit in a UV. That is a real, practical disadvantage.

    By using & 1 for oddness testing, I am clearly flagging the intended design range for the variable. Using % 2 would be to conceal that information.

The bottom line with this, as with so many "future proofing" arguments, is that you cannot predict the future, and trying is futile as it creates as many potential problems as it potentially solves. You cannot protect the future programmer against the effects of the changes they might make.

It is, and must be incumbent on the future/maintenance programmer to understand the code he is modifying before he makes his modifications. And all the arguments that suggest that you can prevent future problems by allowing the programmer to leap in and make changes without fully understanding their implications, are bogus.

In reply to Re^5: &1 is no faster than %2 when checking for oddness. Oh well. ("bug"?) by BrowserUk
in thread &1 is no faster than %2 when checking for oddness. Oh well. by diotalevi

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.