So, I have a PHP script:
<?
rand(1000000000000,9999999999999);
The expected result is a number with 13 digits.
But it's returning some weird numbers, as:
987419207
1032717476
-455563764
Does anyone know what's going on?
PHP: 5.2.17
OS: Tested on Debian Squeeze and Windows 7, both 64 bits
Solution (workaround)
<?
echo rand(10000,99999).rand(10000000,99999999);
Use getrandmax() to see the max value that you can get from rand(), its clearly a overflow problem.
you could use 2 of this int and make a longer one, calling rand for a 6 digit and again for a 7 digits, just an idea.
i think 10000000000000 its not a valid integer!
output
getrandmax();
Use a bignum library like BCMath or GMP. GMP is newer and seems to have a better API but that's just my opinion
Related
I am trying convert a Python script to PHP. However I am having trouble getting the format right.
Python:
print(hashlib.sha1(struct.pack('L', 1)).hexdigest())
Output:
3da89ee273be13437e7ecf760f3fbd4dc0e8d1fe
PHP:
echo sha1(pack('L', 1));
Output:
3c585604e87f855973731fea83e21fab9392d2fc
Can someone please point me in right direction to get the same output in both languages?
The differences occurs because of different integer sizes. While L in the php version of pack() uses hardcoded 32bit integers, Python by default uses the machine integer size. If you are working on a 64bit system you'll notice the difference. (As shown in the question)
You need to use the = in python to standardize the aligment and the size:
print(hashlib.sha1(struct.pack('=L', 1)).hexdigest())
Output:
3c585604e87f855973731fea83e21fab9392d2fc
Please refer to this docs:
Python struct: https://docs.python.org/2/library/struct.html
PHP pack: http://www.php.net/manual/en/function.pack.php
This appears to be a 32 vs 64-bit issue. Are you running a 64-bit version of Python?
Note that according to the Python docs, L is an "unsigned long". Since you're not specifying a byte order, size and alignment character, Python will default to native. On Linux, that means 8 bytes on 64-bit, and 4 bytes on 32-bit.
It's always best to tell Python exactly what you mean when working with binary data:
< for little-endian, standard size, or
> for big-endian, standard size.
This will eliminate any differences, depending on what type of machine you're running on.
This example shows that you're probably using a 64-bit build of python, as L == Q (64-bit).
>>> print(hashlib.sha1(struct.pack('<I', 1)).hexdigest())
3c585604e87f855973731fea83e21fab9392d2fc
>>> print(hashlib.sha1(struct.pack('<Q', 1)).hexdigest())
3da89ee273be13437e7ecf760f3fbd4dc0e8d1fe
I'm trying to port a php algorithm to perl but I struggle with one bit operator I'm not familiar with...
so the php code looks like this:
...
$var = '348492634';
print ~$var;
...
result: -348492635
doing the exact same thing in perl:
...
$var = '348492634';
print ~$var;
...
result: 18446744073361058981
I read a lot about the integer size depending on the architecture of the cpu, but I never found a working solution. Maybe I'm just using the wrong function in perl...
It's necessary for the logic to get same result as in the php script.
Thanks in advance
Seems that on your setup, PHP ints are 32bit signed while perl ints are 64bit unsigned.
This will probably do what you need on the given system but it is not guaranteed to work the same if you use it on another installation of perl.
$var = '348492634'; #hex!
print ~($var - 2**32) - 2**32;
The following will do for both $var='348492634' (which you claim to have) and $var=348492634 (which you did have):
unpack('l', ~pack('l', $var))
The quick and dirty conversion is:
print -($var+1); # like ~$var in PHP
If your perl is using 64-bit integers, this will only fail for $var=-18446744073709551616
(0x8000000000000000), which is a value you wouldn't use in 32-bit PHP anyway.
I need to raise 8 to the power of 17 in PHP. I have checked this to be 2251799813685248 on my PC's calculator, but both the pow() and bcpowmod() functions seem to overflow; pow() goes into scientific notation, and echoing the results from bcpowmod(), even with a high third parameter gives me a blank screen. Is there any other way I could perform this calculation?
You can try with gmp_pow
gmp_pow("8", 17);
With h2ooooooo suggestion - to get result use:
gmp_strval(gmp_pow("8", 17));
Also bcpow works well for me
bcpow("8", "17")
Use pow(). The "scientific notation" you are talking about is just a notation and you can format it later.
echo number_format(pow(8,17), 0, '', '');
http://php.net/number-format
Beside this I couldn't reproduce the "scientific-notation"-behaviour for the given values
http://codepad.viper-7.com/AwM3CS (Uses bigger values to enforce the scientific notation)
I am including the same "random.inc" in foo.php and bar.php. For each, I want reproducible "random" results.
So in foo.php I always want one set of numbers and/or keywords. In bar.php another. Which shouldn't change on reload. That's what I mean by contant pseudo-random. And that's why I seeding on the url. However I still get different results for individual numbers as well as for array pickson every reload. This is the full php file:
<?
header('Content-Type: text/plain');
$seed = crc32( $_SERVER['REQUEST_URI'] );
echo "phpversion: ".phpversion()."\nseed: $seed\n";
srand( $seed ); // (seed verified to be contant as expected)
// neither single values nor array pics turn out deterministic
echo ''.rand(0,100).' '.rand(0,100).' '.rand(0,100)."\n";
$values = array( '0'=>21,'1'=>89,'2'=>96,'3'=>47,'4'=>88 );
print_r( array_rand( $values, 3 ) );
?>
In the days of PHP4.1 it was (verified) possible to achieve constant pseudo-random like this. array_rand API documentation describes as a feature that since 4.2 initialization happens automatically. Perhaps this is overriding any explicit seeding? (if so, perhaps explicit seeding should raise an internal PHP flag, preventing automatic seeding?). Btw: mt_srand() and srand() are equally not working.
I would really like to get my deterministic / constant pseudo-random back...
Update: Solution below (Windows and/or version 5.2 's fault)
Works for me (PHP/5.3.6):
<?php
$data = range(1, 100);
srand(1);
print_r(array_rand($data, 3));
... always prints:
Array
(
[0] => 21
[1] => 89
[2] => 95
)
... in my machine. Apparently, the exact numbers differ depending on the exact environment but they're reproducible.
Guys, you are all correct! (Sorry, I answer it myself now)
my web hoster runs 5.2.17 under Linux 2.6.36, and above problem exists.
under Win x64 5.3.0 everything works as expected.
So it's everyone's guess if that's an OS related bug and/or a PHP bug, fixed in 5.3.0.
Given that random constant seeding worked before, I am guessing they fixed in 5.3 the bug that came with the autoseed feature enhancement in 4.2. Anyway, Thanx again, at least there's clarity now.
The seeding functions are still available, and should still work; it's just since PHP 4.2 they are automatically seeded with the time on page load; but you can still call them to reset the random sequence to a known starting point.
[edit] I have just done a quick test program to make sure I wasn't imagining it!
mt_srand(50000);
print "rand="+mt_rand(0,10000);
Using PHP 5.2, this always results in the same value being printed (1749).
[EDIT]
As noted by #cwd and in the accepted answer to this question, there appears to be a discrepancy in PHP 5.2's behaviour with random number seeding between the Linux and Windows versions. In PHP 5.2 on Linux, the above technique does not appear to work.
Fortunately, the bug seems to have been fixed in PHP 5.3, so the solution to this problem is simply to upgrade. (PHP 5.2 is not supported any longer, so you should upgrade anyway)
Btw, if anyone else wants "constant windows-pre-5.3 pseudo-random" (of low quality, e.g. for stuff like SEO buzzwording) this is a tested workaround:
$r = abs(crc32($URL))%20; // a number between 0 and 19, based on URL
In PHP 5.2.17 and probably on all versions of PHP 5.2, (not sure about windows), we lose the capability of generating random numbers based on a seed as PHP changes the algorithm used for random numbers.
rand and mt_rand are "broken" not only because they will not give one random number, but they will also not give a same sequence of random numbers - even when using a seed!
At first the PHP developers tried to argue that this is the way that it "should" work, but we can guess they caught enough grief about the problem that they have reverted the way that it works with PHP 5.3.
See the php mt_rand page and the bug tracker to learn about this issue.
everytime I try to get the factorial of 171, I get INF. 170 works fine. Is it possible to get the factorial of 171+ in a script? How?
My function:
function factorial($n) {
if ($n == 0) return 1;
return $n * factorial($n - 1);
}
If you deal with very large numbers, you'll need to use an extension that allows you to do that.
There's BCMath ( http://www.php.net/manual/en/book.bc.php) , and GMP ( http://www.php.net/manual/en/book.gmp.php ).
You'll have to use BC Math or GNU MP extension. PHP doesn't provide any tools for high-values or high-precision operations OOTB.
echo "1241018070217667823424840524103103992616605577501693185388951803611996075221691752992751978120487585576464959501670387052809889858690710767331242032218484364310473577889968548278290754541561964852153468318044293239598173696899657235903947616152278558180061176365108428800000000000000000000000000000000000000000"
really though, your function is fine. I think PHP lacks that kind of precision. I got the value (it is correct btw) in python
You are probably getting a value that exceeds the maximum double precision float in a 32-bit machine (~10^308). 170! factorial is ~7.25741562 × 10^307 which is just under that, however, 171! is larger. Your best bet is to use one of the libraries EboMike or Crozin recommends in their answers.
For large n, you can compute n! very quickly with little error using Stirling's approximation. Take a look at this post; it has an analysis of the function and some sample code:
http://threebrothers.org/brendan/blog/stirlings-approximation-formula-clojure/
It's a bigger number than you can hold using 32-bits. If you run the same code on a 64-bit computer then it should work.