Edit report at https://bugs.php.net/bug.php?id=53045&edit=1

 ID:                 53045
 Comment by:         282130106 at qq dot com
 Reported by:        remy at wh dot nl
 Summary:            broken result of intval()
 Status:             Bogus
 Type:               Bug
 Package:            *Math Functions
 Operating System:   FreeBSD
 PHP Version:        5.2.14
 Block user comment: N
 Private report:     N

 New Comment:

echo intval(pack('a*',log(8,2)));

or 

echo floor(pack('a*',log(8,2)));

It's gives 3,i don't now why.


Previous Comments:
------------------------------------------------------------------------
[2010-10-18 01:26:52] cataphr...@php.net

Closing as, most likely, this is not related to PHP.

------------------------------------------------------------------------
[2010-10-13 09:37:12] remy at wh dot nl

Ok, php 5.2.12 gives the same (broken) result...

------------------------------------------------------------------------
[2010-10-13 09:30:55] remy at wh dot nl

[remy@xxx]~> cc -o a.test a.c -lm
[remy@xxx]~> ./a.test
2.9999999999999996

I'm not entirely sure, but I did not notice this problem in 5.2.12.
I'll try to recompile 5.2.12 to see if the problem occurred too...

------------------------------------------------------------------------
[2010-10-13 09:00:14] ras...@php.net

Not sure there is a whole lot we can do about this.  It is a typical IEEE-754 
precision problem.  Try this simple C program, for example:

[a.c]
#include <stdio.h>
#include <math.h>
int main(int argc, char *argv[]) {
        printf("%.16f\n",log(8) / log(2));
}

LDFLAGS=-lm make a

./a

I get: 3.0000000000000000

I bet you get 2.9999999999999996
or something along those lines.

We might be able to do something clever with PHP's precision setting internally 
and round to that precision before doing the truncation there, but in reality 
you are dealing with floating point numbers here and whenever you deal with 
floating point numbers when programming you have to treat them as 
approximations, never as exact values.  Unless you are using arbitrary 
precision 
functions such as the gmp or bcmath function (which are orders of magnitude 
slower) you are going to have to account for these imprecisions in your code.

------------------------------------------------------------------------
[2010-10-13 08:38:16] remy at wh dot nl

php -i output:

phpinfo()
PHP Version => 5.2.14

System => FreeBSD xxx.xxx.com 7.3-STABLE FreeBSD 7.3-STABLE #7: Thu Jul 15 
20:09:49 CEST 2010     r...@xxx.xxx.com:/usr/obj/usr/src/sys/XXX i386
Build Date => Sep 22 2010 20:07:20
Configure Command =>  './configure'  '--with-libxml-dir=/usr/local/lib' 
'--with-config-file-path=/home/www/php' '--with-zlib' '--with-mysql' 
'--with-pgsql' '--enable-calendar' '--enable-mbstring' 
'--with-apxs2=/home/www/bin/apxs' '--enable-ftp' '--with-gd' '--enable-mbregex' 
'--enable-gd-native-ttf' '--with-png-dir=/usr/local/lib' 
'--with-jpeg-dir=/usr/local/lib' '--with-xpm-dir=/usr/X11R6/lib' 
'--with-freetype-dir=/usr/local/lib' '--with-iconv' '--with-curl' '--with-bz2'

------------------------------------------------------------------------


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

    https://bugs.php.net/bug.php?id=53045


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53045&edit=1

Reply via email to