Re: [PHP] Re: PHP Hex Numbers
You might consider using BCMath Arbitrary Precision Mathematics Functions cid:[EMAIL PROTECTED] Jason Teagle wrote: - Original Message - From: Jonathan Rosenberg [EMAIL PROTECTED] To: Jason Teagle [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 03, 2002 3:18 PM Subject: RE: [PHP] Re: PHP Hex Numbers When doing arithmetic in code, you should always be prepared to handle signed and unsigned. Thanks for the reply. I figured something like this was going on. But, how does one become prepared to handle signed unsigned integers? Is PHP consistent regarding signed/unsigned when it does arithmetic on integers? I don't know the answer to that question (yet). What I meant was, we should always be thinking about numbers possibly being negative when treated as signed (which I believe is the default when using numbers for arithmetic), and if necessary account for it. For example, testing if $result 0 would alert us to the fact that it is probably too large for a signed 32-bit integer, and needs special handling. I don't know if PHP supports a larger integer type (64 bits, for example) - if it does, that helps since you can cast to that type to ensure it is added correctly. _ _ o oJason Teagle [EMAIL PROTECTED] v
[PHP] Re: PHP Hex Numbers
Jonathan Rosenberg [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
would produce the same output. Is this correct?
Theoretically...
Either I'm missing something, or PHP gets very confused when
dealing with some numbers. For example, the following program
?
$result = 0x9E3779B9;
echo $result
printf('%d', $result);
?
produces
2654435769
-1640531527
I get the same kind of unexpected results when doing arithmetic
on such numbers.
Is this tickling some kind of known bug in PHP? or am I
misunderstanding something?
It's not a bug, just an 'inconsistency'. Both are correct... if you have a
calculator that supports hex, type both those results in and convert to hex.
Both should say 9E3779B9. The first result treats 9E3779B9 as an unsigned
32-bit value, the second result treats it as a _signed_ 32-bit value. If you
use
printf('%u', $result);
(assuming PHP supports the full range of C printf() format specifiers), it
should print out 2654435769 as does the straight echo.
It seems echo treats numbers as unsigned...
When doing arithmetic in code, you should always be prepared to handle
signed and unsigned.
--
_ _
o oJason Teagle
[EMAIL PROTECTED]
v
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP Hex Numbers
-Original Message- From: Jason Teagle [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 9:27 AM To: [EMAIL PROTECTED] Subject: [PHP] Re: PHP Hex Numbers When doing arithmetic in code, you should always be prepared to handle signed and unsigned. Thanks for the reply. I figured something like this was going on. But, how does one become prepared to handle signed unsigned integers? Is PHP consistent regarding signed/unsigned when it does arithmetic on integers? -- _ _ o oJason Teagle [EMAIL PROTECTED] v -- JR -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Hex Numbers
- Original Message - From: Jonathan Rosenberg [EMAIL PROTECTED] To: Jason Teagle [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 03, 2002 3:18 PM Subject: RE: [PHP] Re: PHP Hex Numbers When doing arithmetic in code, you should always be prepared to handle signed and unsigned. Thanks for the reply. I figured something like this was going on. But, how does one become prepared to handle signed unsigned integers? Is PHP consistent regarding signed/unsigned when it does arithmetic on integers? I don't know the answer to that question (yet). What I meant was, we should always be thinking about numbers possibly being negative when treated as signed (which I believe is the default when using numbers for arithmetic), and if necessary account for it. For example, testing if $result 0 would alert us to the fact that it is probably too large for a signed 32-bit integer, and needs special handling. I don't know if PHP supports a larger integer type (64 bits, for example) - if it does, that helps since you can cast to that type to ensure it is added correctly. _ _ o oJason Teagle [EMAIL PROTECTED] v -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
