neral'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [fw-general] Re: [PHP-DEV] ZF
> 0.8.0 Unit Tests behaving different on PHP 5.2.1 and PHP 5.2.2-dev
>
>
> Dmitry Stogov wrote:
>
> > It is bad practice to use echo $fl
PHP 5.2.1:
-1689934592
2147483647
PHP 5.2.2:
-1689934592
6
Huh, that's a strange thing. Why it happens?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Hello Sebastian,
sometimes persistence is good. I take it all back after realising that we
are speaking of the general outputformat. That should of cause stay the
same. Tony mentioned he can fix it. So let the format just stay the same
as Rasmus suggested.
best regards
marcus
Tuesday, April 17
Sebastian Nohn wrote:
> $c = $a."";
> $d = (string)$a;
Forget that.
- Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 04/17/2007 10:37 PM, Sebastian Nohn wrote:
$a = 69;
$b = "69";
$c = $a."";
$d = (string)$a;
You're converting float to string and THEN trying to output as integer.
My patch returns the old behaviour, though you're code is still wrong.
--
Wbr,
Antony Dovgal
--
PHP Intern
Antony Dovgal wrote:
> On 04/17/2007 10:16 PM, Sebastian Nohn wrote:
>> Dmitry Stogov wrote:
>>
>>> It is bad practice to use echo $float or var_dump($float)
>>> because they depends on php.ini settings.
>>> You should use printf() of number_format() for deterministic result.
>
> $a = 69;
On 04/17/2007 10:16 PM, Sebastian Nohn wrote:
Dmitry Stogov wrote:
It is bad practice to use echo $float or var_dump($float)
because they depends on php.ini settings.
You should use printf() of number_format() for deterministic result.
You're converting float to string and THEN trying to ou
Dmitry Stogov wrote:
> It is bad practice to use echo $float or var_dump($float)
> because they depends on php.ini settings.
> You should use printf() of number_format() for deterministic result.
PHP 5.2.1:
-1689934592
2147483647
PHP 5.2.2:
-1689934592
6
- Sebastian
--
PHP Internals - PHP
Antony Dovgal wrote:
> On 04/17/2007 09:57 PM, Sean Coates wrote:
>>> lemme try this again. You can in no way rely on the last digits of
>>> a float
>>> output. Those depend on your system, your CPU, your ini settings and any
>>> operation you do with floats reduces the accuracy
>>
>> It's st
On 04/17/2007 09:57 PM, Sean Coates wrote:
lemme try this again. You can in no way rely on the last digits of a float
output. Those depend on your system, your CPU, your ini settings and any
operation you do with floats reduces the accuracy
It's still a regression, and should be documente
Marcus Boerger wrote:
Hello Sebastian,
lemme try this again. You can in no way rely on the last digits of a float
output. Those depend on your system, your CPU, your ini settings and any
operation you do with floats reduces the accuracy
yes .. but given no changes to all of the above men
Marcus Boerger wrote:
> lemme try this again. You can in no way rely on the last digits of a float
> output. Those depend on your system, your CPU, your ini settings and any
> operation you do with floats reduces the accuracy
If I do the same operation with the same ini setting on exakt the
> lemme try this again. You can in no way rely on the last digits of a float
> output. Those depend on your system, your CPU, your ini settings and any
> operation you do with floats reduces the accuracy
It's still a regression, and should be documented.
S
--
PHP Internals - PHP Runtime D
Hello Sebastian,
lemme try this again. You can in no way rely on the last digits of a float
output. Those depend on your system, your CPU, your ini settings and any
operation you do with floats reduces the accuracy
best regards
marcus
Tuesday, April 17, 2007, 7:45:57 PM, you wrote:
> Marc
Marcus Boerger wrote:
> float numbers are never perfect values. So should in anyway never rely
> on a certain output format. So there is nothing to document here.
We have a changed behavior here that should be documented. Otherwise
users will run into problems. As the non-academic example that
Hello Lukas,
float numbers are never perfect values. So should in anyway never rely
on a certain output format. So there is nothing to document here.
best regards
marcus
Tuesday, April 17, 2007, 10:16:39 AM, you wrote:
> Dmitry Stogov wrote:
>> It is bad practice to use echo $float or var_dum
On Tue, April 17, 2007 9:55 am, Dmitry Stogov wrote:
> The float formatting algorithms were changed because of
> licensing issues and new ones are not 100% compatible with
> previous ones.
Could you please provide more details on that?
- Sebastian
--
PHP Internals - PHP Runtime Development Mai
Dmitry Stogov wrote:
It is bad practice to use echo $float or var_dump($float)
because they depends on php.ini settings.
You should use printf() of number_format() for deterministic result.
The float formatting algorithms were changed because of
licensing issues and new ones are not 100% compat
.php.net
> Subject: [PHP-DEV] Re: [fw-general] Re: [PHP-DEV] ZF 0.8.0
> Unit Tests behaving different on PHP 5.2.1 and PHP 5.2.2-dev
>
>
> Sebastian,
>
> it should also be mentioned that when you are refferring to a
> test within ZF
> you should always look
> again
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Thomas,
> it should also be mentioned that when you are refferring to a test
> within ZF you should always look
> against the latest version of ZF.
As already mentioned: This also happens in ZF trunk. ZF unit tests fail
on any platform since somet
PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Monday, April 16, 2007 10:32 AM
Subject: [fw-general] Re: [PHP-DEV] ZF 0.8.0 Unit Tests behaving different
on PHP 5.2.1 and PHP 5.2.2-dev
On Mon, April 16, 2007 10:10 am, Antony Dovgal wrote:
On 04/15/2007 11:05 AM, Sebastian Nohn wrote:
5.2.
On Mon, April 16, 2007 10:10 am, Antony Dovgal wrote:
> On 04/15/2007 11:05 AM, Sebastian Nohn wrote:
>> > $a = 69;
>> var_dump($a);
>> $b = "A is: ".$a;
>> var_dump($b);
>> ?>
>>
>> 5.2.1 output is:
>>
>> float(6.9E+9)
>> string(16) "A is: 69"
>>
>> 5.2.2-dev output is:
>>
>> float
On 4/16/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 04/15/2007 11:05 AM, Sebastian Nohn wrote:
> $a = 69;
> var_dump($a);
> $b = "A is: ".$a;
> var_dump($b);
> ?>
>
> 5.2.1 output is:
>
> float(6.9E+9)
> string(16) "A is: 69"
>
> 5.2.2-dev output is:
>
> float(6.9E+9)
> strin
On 04/15/2007 11:05 AM, Sebastian Nohn wrote:
5.2.1 output is:
float(6.9E+9)
string(16) "A is: 69"
5.2.2-dev output is:
float(6.9E+9)
string(12) "A is: 6.9E+9"
Nice catch, thanks.
What do you think is the most correct output for 1 000 000 000 000 000 (with
precision = 14)?
Versio
On Sat, April 14, 2007 8:29 pm, Antony Dovgal wrote:
> On 04/14/2007 08:50 PM, Sebastian Nohn wrote:
>> On PHP 5.2.1, ZendFramework 0.8.0 Unit Tests pass, while they fail on
>> PHP 5.2.2-dev (latest CVS) on the same machine:
>>
>> 1) testDate(Zend_Date_DateObjectTest)
>> Failed asserting that is i
On 04/14/2007 08:50 PM, Sebastian Nohn wrote:
On PHP 5.2.1, ZendFramework 0.8.0 Unit Tests pass, while they fail on
PHP 5.2.2-dev (latest CVS) on the same machine:
1) testDate(Zend_Date_DateObjectTest)
Failed asserting that is identical to
.../tests/Zend/Date/DateObjectTest.php:408
Would be
On PHP 5.2.1, ZendFramework 0.8.0 Unit Tests pass, while they fail on
PHP 5.2.2-dev (latest CVS) on the same machine:
1) testDate(Zend_Date_DateObjectTest)
Failed asserting that is identical to
.../tests/Zend/Date/DateObjectTest.php:408
This behaviour is also reproducable on Zend Framework trun
27 matches
Mail list logo
