This question already has answers here:
Working with large numbers in PHP
(8 answers)
What's the maximum value for an int in PHP?
(8 answers)
Closed 1 year ago.
I have some legacy code on a Windows machine running PHP 5.6 that we will be dismissing but I need to do some migrations from.
I have trivial bit of code that is quite mistifying to me.
I've simplified it for this question, but the behavior is the same.
$a = "3109584483";
$b = (int) $a;
var_dump($a);
var_dump($b);
And this is the output:
string(10) "3109584483"
int(2147483647)
I have looked at all the similar questions about this, but they all mention
Casting a float (not my case)
Getting the result in a non-10 base (I tried converting 2147483647 from and to common bases like HEX, OCT and BIN, but I can't seem to find a match that would justify the result)
What is the reason of this wrong casting?
Thanks in advance for your help!
Related
This question already has answers here:
Working with large numbers in PHP
(8 answers)
Closed 2 years ago.
That is my code below to get "100 power of 2 in PHP",
echo pow(2,100);
I would get the result as 1.2676506002282E+30, However, I wish to get a whole integer of the result.
How should I do it with PHP？
if by accurate, you want to have the exact value of 2 to the power of 100 that is equal to 1,267,650,600,228,229,401,496,703,205,376,
you can simply use
echo number_format(pow(2,100));
Update: like #Olivier said in comments, number_format does not return the exact results in some cases, so be careful in using that.
I guess by "accurate" you mean you want to get an exact integer. You will have to use additional library for working with big integers. GMP for example will work for what you need. It's is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating-point numbers.
Here is an example for the specific question:
<?php
$pow = gmp_pow("2", 100);
echo gmp_strval($pow);
?>
It will not work directly. You will have to first open php.ini and uncomment the "extension=gmp" line.
And that's not the only solution. There are more libraries available as variants for doing that.
This question already has answers here:
Working with large numbers in PHP
(8 answers)
Closed 3 years ago.
I searched and I found that I can use number_format function in php. But it can't even store 1 million digits . I am getting output as inf.
Can someone help me please. If it's not possible in php then can it be done in C++ or Java ?
Update: I am using GMP but when I run script browser sent me response as "this site can't be reached, connection was reset". I disabled max execution time but it gives me same error.
What should I do? Do I need to do any other changes in configuration?
There is bigint choice in phpmyadmin
Laravel has that too, and you can do it in terminal
bigint is great but rarely used
Updated
you can use float and set value limit
In this picture I used float and defined the value limit to 20
Hope that helps
This question already has answers here:
Accessing dates in PHP beyond 2038
(5 answers)
Closed 4 years ago.
The below code returns 1970 if the year is 2038 and correct year (2037) if it is altered as 2037. why?
$date = '28/05/2038';
$date = strtr($date, '/', '-');
$year = date('Y', strtotime($date));
echo $year;
I did some research and understood that the strtotime conversion returns 0, when the passed value is unsupported and hence this happens. But I dont understand how will it become unsupported if I change the date from '28/05/2038' to '28/05/2037'.
It seems the problem is easily repeated for PHP versions below 5.2.16 even with even with PHP_INT_SIZE = 8. For that version and above the code executes correctly. Upgrading PHP to 5.2.16 should solve it. Only tested for PHP_INT_SIZE = 8 (64 bit)
Here you can check for yourself.
If you happen to be on PHP 5.2.0 or higher (but below 5.2.16) you can go for DateTime class as others suggested in the question's comments.
Note: Upgrading a service on a populated server may not be possible, not on work and not even on university courses. But if it happens to be possible, then you should test the proper version of PHP before upgrading. If it works, you should investigate why it has been fixed and at which point the functionality was added, googling PHP's bugtracker. Then suggest the change.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Floating point inaccuracy examples
PHP rounding issue - Is this a bug?
Found what may be a bug in PHP, but I wanted to check to see if it's just some weird calculation or something that someone already knows about.
An example:
$available = 64.02;
$spent = 64.01;
$available -= $spent;
print $available."<br />";
I'd expect the result to be 0.01, right? However, I get 0.00999999999999.
If you do this for any integer less than 64 (ex: 45.02 - 45.01) I get the correct 0.01 result. Anything greater than or equal to 64, however, gives me 0.00999999999999.
I've tested in PHP 5.2.17 and PHP 5.2.12. Tried to google it, but couldn't find anything. Can any one shed any light on this issue?
This is typical of floating point arithmetic. These numbers are stored in binary and there is not always an exact representation of every number in binary. The same problem can be observed in base ten when you try to represent 1/3 and you end up with an endless decimal sequence whereas the the same number represented in a base that is a multiple of three would have a finite sequence.
This shouldn't be a big problem, anyways, 0.00999999999999 is only 0.00000000000001 different than 0.01.
This question already has answers here:
Warning: Massive error in json_encode()
(3 answers)
Closed 8 years ago.
I have a weird (and rather frightening) problem with Ajax.
I'm returning 3 large integers from PHP back to Javascript (jQuery):
9849933840800076
9717106838244944
9261288452893495
But recieve:
9849933840800076
9717106838244944
9261288452893496
Notice the last digit in the third integer - WTF ?!?
- I'm logging everything, and am certain it's not my code doing it!
And returning them as strings instead does solve the problem, but still...
It would be nice to get an explanation - and some sleep : )
My fault, sorry. (and thank you, Pekka)
JS "looses precision" on integers larger than 2^53 (+/- 9007199254740992)
- Back to the wriggleroom..
in these kind of cases you can always return the numbers as strings and convert them in the js