Bug #16366 Updated: bit shifting error
| From: | adam at adeptsoftware dot com | Date: | Sun, 31 Mar 2002 18:38:52 +0000 |
| Subject: | Bug #16366 Updated: bit shifting error | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-3697@lists.php.net to get a copy of this message | ||
ID: 16366
Updated by: adam@adeptsoftware.com
Reported By: adam@adeptsoftware.com
-Status: Open
+Status: Closed
-Bug Type: Documentation problem
+Bug Type: Math related
Operating System: WinXP
PHP Version: 4.1.2
New Comment:
Well I have 200 groups of 64 on/off's.. I can name the 200 bigint
groups but there is no way in hell I am going to name 12,800 bools, not
to mention that they would take up 8x more space in the database.. Each
group has the same structure - somebody needs to write a DB that uses
structures as custom fields. This may be the way they work but this is
ancient design - I was surprised as hell when I started learning MySQL
and realized that they are still doing things this way. But anyway.
Now I am thinking "char binary" since it can be fixed size, but the
documentation on PHP's conversions of MySQL is sparse. If someone
would like to pursue this in private email please write.
The original bug was about bit shifting, which I don't think would
involve a conversion to float.. unless PHP is doing something weird.
It looks like someone is just not expecting a shift greater than 32.
Previous Comments:
------------------------------------------------------------------------
[2002-03-31 13:27:30] sander@php.net
Good point. Reopening as documentation problem.
------------------------------------------------------------------------
[2002-03-31 13:23:52] msopacua@idg.nl
Related to the bug only:
<?php
$int=2;
for($i=25;$i<33;$i++)
{
$check=pow($int, $i);
$check2=(int)$check;
$check2 += 1;
$check3=(int)$check;
$check3 -= 1;
echo("i is $i\n");
var_dump($check);
var_dump($check2);
var_dump($check3);
echo("\n");
}
?>
Gives some weird results:
$ ./test_float_conversion.php
i is 25
int(33554432)
int(33554433)
int(33554431)
i is 26
int(67108864)
int(67108865)
int(67108863)
i is 27
int(134217728)
int(134217729)
int(134217727)
i is 28
int(268435456)
int(268435457)
int(268435455)
i is 29
int(536870912)
int(536870913)
int(536870911)
i is 30
int(1073741824)
int(1073741825)
int(1073741823)
i is 31
float(2147483648)
int(-2147483647)
float(-2147483649)
i is 32
float(4294967296)
int(1)
int(-1)
I guess the manual should be appended, in the 'typecasting' section, to
not cast to integer, when it's larger than 2^30 and that those numbers
are automatically converted to floats.
(http://www.php.net/manual/en/language.types.type-juggling.php#language.types.typecasting)
------------------------------------------------------------------------
[2002-03-31 13:10:38] derick@php.net
Can you please stop this discussion in the bug system. Fighting about
what is best can be done in private mail just fine.
Derick
------------------------------------------------------------------------
[2002-03-31 13:09:00] daniel@php.net
I'm sorry, but this is not flipcode.com - this is web-development.
Not performance, but maintaineability and readability are crucial.
Always write your code in a way someone else could easily understand
what you are trying to do (even if you'll never release your
sourcecode).
------------------------------------------------------------------------
[2002-03-31 12:58:54] daniel@php.net
But "32 columns" are the way databases work. You can give names to
these columns and everybody will understand what they are good for.
- If you decide to just have a (int)flags in SQL, how could someone
possibly understand this without reading your documentation (if you
wrote it) or reading through your source code?
- Databases are meant to have columns - commands such as WHERE, ORDER
BY etc.. only work on columns, but not on your homebrewn data format.
- You can add or remove columns, but modifying your flags would end in
a big mess.
- Databases can optimize/cache requests on certain columns (at least I
think they can).
- Using columns is less error-prone.
Why the hell should you STILL be using your custom-made flags-thingie
instead?
But you are right and the bug still exists. PHP has problems with
floating point operations - that's why I suggested to use the "BC"
package.
I wrote a "BC wrapper" which wraps all BC functions to regular PHP
functions. It is meant for people who want to develop their code with
BC, but still want to keep compatibility to PHP installations without
BC. Tell me if you want it.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16366
--
Edit this bug report at http://bugs.php.net/?id=16366&edit=1