[ I'll ignore most of your extensive, off-topic complaints where you try to attribute me with motives based on your personal baggage. I'll note a couple of them, however, in the course of trying to finish the technical argument, and I will address one directly, at least as an example (since it was less off-topic). ]
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?
I don't believe I suggested any such thing. But thanks for trying to insult me based on ideas you've made up and attributed to me. (See how easy it is to claim that? No, I don't find this claim to be a stretch, but I prefer to avoid such interpretations. Also, I don't find it difficult to intepret your question simply as a technical question; just in case you were actually trying to be insulting.)
But, no, I don't have a big problem with converting a value that is too large to fit into a UV into the maximal value that does fit (and caching that value and only using it when one forces Perl to perform a UV-only operation on the scalar). Looking at similar situations in Perl, issuing a warning seems appropriate, but adding such wouldn't be an unmixed blessing.
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.
FYI, there was no sarcasm in that sentence. I was simply trying to figure out an argument that you might have been trying to make that actually countered the point of my node (that %2 works in more cases than &1). I was giving you the benefit of the doubt that you understood my point and disagreed with it and I just didn't understand your point.
I stated, in effect, "&1 doesn't work on many valid NV values" and you replied "That's just a bug." The most straight-forward interpretation of your sentence, when given in response to what I wrote, is that you think that "&1 would work on as many NV values as %2, if it weren't for a bug in Perl." So I entertained that most straight-forward interpretation. I don't find such an idea (& working directly on NVs) to be ridiculous.
It is, and must be incumbent on the future/maintenance programmer to understand the code he is modifying before he makes his modifications.
I wasn't speaking of future programmers nor of modifying code. I was speaking of writing code that simply works on a much wider range of values and without a single technical drawback. That makes it a trivial decision for me to label such a practice as a "best practice" and to adopt it.
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. [emphasis added]
I didn't see you present any future potential problems of using %2. You have one point that boils down to style; you state that using %2 "conceal"s the fact that elsewhere one may have limited the potential range of a value. I disagree both with that claim ("conceal") and with the implied idea that it is best to repeat "this is a UV" at every single operation one performs on a value that one has elsewhere decided will only ever be a UV. And I don't consider that a potential future problem. Especially since I was not talking about modifying code.
To make it extremely simple, consider the code:
my $num= shift @ARGV; print "Your number ($num) is odd.\n" if $num & 1;
It takes absolutely no modification of the code for it go from only being used on small integers to being used on values that don't fit into a UV. So replacing that with:
my $num= shift @ARGV; print "Your number ($num) is odd.\n" if $num % 2;
very much future-proofs the code against such a change, even though I wrote the code fully intending that I'd only use it on small integers. By your claim, I must have introduced as many problems by doing that as I have solved. I actually can't come up with any. Perhaps you will, but I do believe that I can do a decent job of "predicting the future" when it comes to what the above code would receive in @ARGV if the code is not modified. And my improved code does in fact deal with a large number of potential and reasonable inputs that the original code did not, while also not failing to deal with any potential and reasonable inputs that the prior code dealt with correctly.
You wrote a lot about bit-twiddling (and similar) code and using &1. Well, if I'm twiddling bits, then if I happen to want to extract the lowest bit of an int, then I won't be trying to "check for oddness" and so it'd be quite silly to use %2, especially in the same expression with a bunch of bit-twiddling operations.
If I'm doing some work on a scalar and one step is "check for oddness" and there are other steps that I do in a way that would fail if used on a value that wouldn't fit into a UV, then I'd still use %2, because there is no penalty in doing so. If I later realize that my initial assumption (about the handling of non-UV values not being required) is no longer valid, then I have one less change required of my code in order to fix it. Gee, I will have predicted the future and saved myself work in the long run without incurring any extra work in the short term. I may have even saved myself work in the short term because, having already adopted %2 as a "best practice", I didn't waste any time debating about whether I should use it or &1 when "checking for oddness".
One can claim that such predictions are futile and almost never come true, but my experience shows otherwise. And even if it didn't come true, I've not lost anything as %2 works just as well as &1 for testing the oddness of all of the values that &1 works for that on.
It is, and must be incumbent on the future/maintenance programmer to understand the code he is modifying before he makes his modifications. [original emphasis]
That doesn't mean that making the code easier to update is a bad thing. I like to make code easier to update, and my predictions of the future have come true often enough that I've repeatedly been glad that I've attempted that.
- tye
[ I'm sorry that you still can't deal. I'll try to remember to go back to replying to you anonymously for a while. Perhaps you'll read your sig enough times that eventually you'll be able to follow it. (Hmm, you omitted it from that last post. I won't try to guess at your motive, though, as that would be rude.) ]
In reply to Re^6: &1 is no faster than %2 when checking for oddness. Oh well. (best)
by tye
in thread &1 is no faster than %2 when checking for oddness. Oh well.
by diotalevi
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |