ID: 16366
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Math related
Operating System: WinXP
PHP Version: 4.1.2
New Comment:
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).
Previous Comments:
------------------------------------------------------------------------
[2002-03-31 12:58:54] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2002-03-31 12:50:00] [EMAIL PROTECTED]
Daniel: 32 columns or 1 integer, I'd take the integer anytime.
The problem is, that large integers are converted to floats:
<?php
$number=11;
$bigint=$number * 10000000000000000000000000000000;
$bigint_nocalc=1100000000000000000000000000000000;
echo("Using values: $number - $bigint - $bigint_nocalc\n");
var_dump($number);
var_dump($bigint);
var_dump($bigint_nocalc);
echo ("\nNumber shift 34\n");
echo ($number>>34);
echo ("\nNumber shift 2\n");
echo ($number>>2);
echo("\nBigint shift 29\n");
echo($bigint>>29);
echo("\nBigint shift 30\n");
echo($bigint>>30);
echo("\nBigint shift 31\n");
echo($bigint>>31);
echo("\nBigint shift 32\n");
echo($bigint>>32);
echo("\nBigint shift 33\n");
echo($bigint>>33);
echo("\nBigint shift 1\n");
echo($bigint>>1);
?>
Output:
$ ./test_bit.php
Using values: 11 - 1.1E+32 - 1.1E+33
int(11)
float(1.1E+32)
float(1.1E+33)
Number shift 34
2
Number shift 2
2
Bigint shift 29
0
Bigint shift 30
0
Bigint shift 31
0
Bigint shift 32
0
Bigint shift 33
0
Bigint shift 1
0
------------------------------------------------------------------------
[2002-03-31 12:49:34] [EMAIL PROTECTED]
> I think I will switch to blobs or something.
the problem is PHP-related. Switching to BLOBs won't solve it.
Why don't you use the ENUM('0','1') data field instead? It is more
humand-friendly (better readable) and somewhat more what the inventor
of databases wanted to do.
You can forget all database-related optimizations because the database
does not understand what you want to do.
------------------------------------------------------------------------
[2002-03-31 12:43:26] [EMAIL PROTECTED]
why store boolean values in a bigint if someone invented "columns" in
SQL? it's a useful thing, you know.
but to get your script working, why don't you just binary "&" ?
if($data & 2)
would check if register two was set.
------------------------------------------------------------------------
[2002-03-31 12:27:36] [EMAIL PROTECTED]
Hmm well the bug of (11>>34) still exists.. anything >>32 or more
should be zero.
I'm not really doing math, I am just storing boolean values in all the
bits of a bigint, and trying to access the high bits has become a
problem. I could always divide by 2 34 times but that kinda sucks.
I think I will switch to blobs or something.
------------------------------------------------------------------------
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
