& number

Unicode isn't related to this at all (except that it, like other information, is stored in a binary format). I believe it's "out of range" simply because there are fewer than 65536 quotations in the list ;)

The trick is to get all of the 2-multiple bits set (~1 does this, as does [2^N]-2), then only allow those 2-mulitple bits in whatever random number was generated. It's clever.

The only reason I can think of using 65534 instead of ~1 would be that it might process a little faster, whereas ~1 is much easier to remember/type. But that will include the entire range up to the largest possible [2^N]-1 value, BUT only as bits which is [very] much faster than actually calculating any of that using traditional math. Intriguing.

Note that this only works for even [or odd] numbers though, because this is base 2. If it were base 3, it would work for numbers divisible by 3, etc. But computers are binary, so this is merely a shortcut for one very specific case: divisibility by 2.

Can I see a link to the code you are working with?

It's not out of range because of the reason you state. Using just raw numbers:

Code:

---

65536 & 65534

---

is 0, while:

Code:

---

65536 & ~1

---

is 65536.

A link would be pointless, all you would see is a random quote, it's PHP.

Here's a simplified version (only 2 quotes) that shows all you need to see what's what:

PHP Code:

---

<?php 

$quotations = array( 

"This is quotation one", 

"&nbsp;", 

"This is quotation two.", 

"North Carolina G.S. 90-210.25(c)(9)", 

); 


$noAuthor = "&nbsp;"; 
$bigIndex = rand(0, (count($quotations) -1)) & 65534; // or $bigIndex = rand(0, (count($quotations) -1)) & ~1; 

echo "<br /><br /><div class='quotations'> {$quotations [$bigIndex]}  <br /><br /><div align='right'>"; 

if ($quotations [$bigIndex + 1] != $noAuthor) { 
    echo "-&nbsp; {$quotations [$bigIndex + 1]}"; 
    } 

echo "</div></div>"; 

?>

---

And really, all you need to play with the concept under discussion here is:

PHP Code:

---

<?php 

$bigIndex = rand(0, 571) & 65534; // or $bigIndex = rand(0, 571) & ~1; 

echo "$bigIndex"; 

?>

---

You can play with the numbers and see what you get. You can substitute various actual numbers for rand(0, 571) to have more control over the situation and thereby perhaps get more information from the results.

I since got out the programmer's calculator and lo and behold, 65534 is:

1111111111111110

Notice the first bit is 0. All odd numbers have a 1 there, so that's a key clue.

But why it compares favorably with - say 568:

1000111000

I'm not sure. It looks like - if a bit exists in the number on the left ($a), it must also exist in the number on the right ($b):

$a & $b

If it doesn't, that bit gets knocked out of the number on the left.

If so, ~1 might be more efficient because it only checks the first bit, If it's one, it knocks it out, otherwise it leaves the number alone. With 65534, it might have to check each bit of the number on the left only to find that they're (in the case of an even number) all cool. With an odd number it might have to check them all as well to make sure other bits might not have to be knocked out.

That still doesn't explain why 0 is the only valid result of comparing with 65536.

Oh, yes it does as 65536 is:

10000000000000000

So one should (and a quick test shows that one can) be able to use:

262142, which is:

111111111111111110

In which case it has nothing to do with Unicode, that part was just a coincidence.

And for an array containing no more than 572 entries, 1022:

1111111110

would be sufficient.

And now it makes perfect sense to me when PHP.net says:

Quote:

---

Bits that are set in both $a and $b are set.

---

That's exactly what's happening. Whew!

65534 (as you discerned) forces the number to be even. In binary, it is all 1's, except for the last bit, which is 0, thus forcing the rounding down. Using 65534 maximizes the number of entries in the array for two bytes. 254 would work if the number of entries was a (binary) number that could fit into a single byte.

Using ~1 maximizes for unlimited bytes.

I'm not going to live long enough to exceed the 65534 that the script can presently accommodate ;)

A.

That's a little misleading, but probably still essentially accurate.

In any case I hope you live a long time.

My point though is that the number used to check must be much higher than the number of entries. Currently there are 572. To properly check all those requires at least 1022. Using ~1, one need not concern oneself with what number is required. And though I'm not certain, I think ~1 is more efficient.