On Sun, 4 May 2008, Jonathan Bond-Caron wrote:
> Thanks, I made some tests after looking at
> http://lxr.php.net/source/php-src/main/spprintf.c#712
>
> At first glance, I am utterly confused,
>
> ini_set('precision', 100);
> setlocale(LC_ALL, 'fr_FR.UTF-8');
> echo 0.3;
lto:[EMAIL PROTECTED]
Sent: May 4, 2008 1:31 PM
To: Jonathan Bond-Caron
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Float comparison
> If someone could point me to the float->string code, I'd really appreciate
http://lxr.php.net/source/ZendEngine2/zend_operators.c#1075
Regards,
Stefan
If someone could point me to the float->string code, I'd really appreciate
http://lxr.php.net/source/ZendEngine2/zend_operators.c#1075
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
end_Locale_Math) is an indicator that it's an important use case for the
community...
If someone could point me to the float->string code, I'd really appreciate
j
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: May 4, 2008 7:06 AM
To: Todd Ruth
Cc: int
Marcus Boerger wrote:
> Maybe you should have a look into PHP's bcmath extension.
PHP's arbitrary precision math handlers are woefully inadequate. I mean,
you can't even take the nth root or a logarithm with bcmath! (gmp isn't
much better).
(However, this has nothing to do with the floating point
Hello Todd,
please read that article to get at least a minimum understanding of what
float values are. Speaking of comparisons and floating point values you
might want to consider using fixed point values. That is you decide how
many digits you want for your fractions. Another option is to use t
On Fri, 2008-05-02 at 23:52 -0400, Cristian Rodríguez wrote:
> Todd Ruth escribió:
>
> > Most people don't care about floating numbers beyond a certain
> > number of digits.
>
> That's the main flaw in your suggestion, "most people".. the language
> should be correct, do the real right thing.
On Sat, May 3, 2008 at 10:31 AM, Philip Olson <[EMAIL PROTECTED]> wrote:
>
> On 2 May 2008, at 18:07, Stanislav Malyshev wrote:
>
> > Hi!
> >
> >
> > > Is it not possible to overload operators?
> > > Though this would probably even more work to do.
> > >
> >
> > Well, overloading operators in theo
On Sat, May 03, 2008 at 02:04:35AM +0100, Richard Quadling wrote:
> 2008/5/3 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Is it not possible to overload operators?
>
> Though this would probably even more work to do.
Overloading of operators implies strong typing, eg overload + for type money to
be
On 2 May 2008, at 18:07, Stanislav Malyshev wrote:
Hi!
Is it not possible to overload operators?
Though this would probably even more work to do.
Well, overloading operators in theory would be less work to do,
technically, since extension points would be easier to identify.
However, I'm
Todd Ruth escribió:
Most people don't care about floating numbers beyond a certain
number of digits.
That's the main flaw in your suggestion, "most people".. the language
should be correct, do the real right thing.
--
"Progress is possible only if we train ourselves to think about progr
Hi!
Is it not possible to overload operators?
Though this would probably even more work to do.
Well, overloading operators in theory would be less work to do,
technically, since extension points would be easier to identify.
However, I'm not sure we'd want to open that can of worms :)
--
St
2008/5/3 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Hi!
>
>
>
> > Solvable in userland easily enough, but having a native money type,
> > especially when dealing with inter-currency conversions, then accuracy
> > is paramount.
> >
>
> Adding native primitive type is expensive - there's a lot of pla
Hi!
Solvable in userland easily enough, but having a native money type,
especially when dealing with inter-currency conversions, then accuracy
is paramount.
Adding native primitive type is expensive - there's a lot of places in
engine and various functions that have to deal with primitive typ
2008/5/3 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Hi!
>
>
>
> > What about introducing a "money" or "currency" numeric type which
> > guarantees say accuracy to 8DP?
> >
>
> Funny thing - I blogged about it about a year ago:
> http://php100.wordpress.com/2007/03/31/making-with-php/
> There's so
Hi!
What about introducing a "money" or "currency" numeric type which
guarantees say accuracy to 8DP?
Funny thing - I blogged about it about a year ago:
http://php100.wordpress.com/2007/03/31/making-with-php/
There's some interesting discussion in comments about how people solve it.
--
Stanisl
2008/5/3 Alain Williams <[EMAIL PROTECTED]>:
> On Fri, May 02, 2008 at 01:03:45PM -0700, Todd Ruth wrote:
> > On Fri, 2008-05-02 at 11:41 -0700, Rasmus Lerdorf wrote:
> > > Stefan Walk wrote:
> > > > And you'll quickly see that the "cast to string before comparision" is
> a
> > > > bad idea, b
On Fri, May 02, 2008 at 01:03:45PM -0700, Todd Ruth wrote:
> On Fri, 2008-05-02 at 11:41 -0700, Rasmus Lerdorf wrote:
> > Stefan Walk wrote:
> > > And you'll quickly see that the "cast to string before comparision" is a
> > > bad idea, because:
> > > $ php -dprecision=1 -r 'var_dump((string)1.4 ==
Hi Todd,
On Fri, May 2, 2008 at 10:03 PM, Todd Ruth <[EMAIL PROTECTED]> wrote:
> (BTW, Pierre, the statement "X considers the fact that S1
> to mean that S2" is a statement _agreeing_ with S1. It calls
> into question whether S1 implies S2. I agree a perfect solution
> to the problems we're
On Fri, 2008-05-02 at 11:41 -0700, Rasmus Lerdorf wrote:
> Stefan Walk wrote:
> > And you'll quickly see that the "cast to string before comparision" is a
> > bad idea, because:
> > $ php -dprecision=1 -r 'var_dump((string)1.4 == (string)1.1);'
> > bool(true)
> >
> > Having display settings affec
Stefan Walk wrote:
And you'll quickly see that the "cast to string before comparision" is a
bad idea, because:
$ php -dprecision=1 -r 'var_dump((string)1.4 == (string)1.1);'
bool(true)
Having display settings affect comparisions seems like a really bad idea
to me ;)
Yup, it would be a fatal
Todd Ruth schrieb:
I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
"==" doesn't exist to mean that the improvements that would
cover 99.9% of user issues with float == shouldn't be made.
It could be worse, however.
Hi Todd,
On Fri, May 2, 2008 at 7:36 PM, Todd Ruth <[EMAIL PROTECTED]> wrote:
> I'm afraid you'll find Pierre's response representative. The
> php devs seem to consider the fact that a theoretically perfect
> "==" doesn't exist
We are not the ones to consider that, that's a fact since the very
ierre Joye [mailto:[EMAIL PROTECTED]
Sent: May 2, 2008 1:05 PM
To: Jonathan Bond-Caron
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Float comparison
On Fri, May 2, 2008 at 6:52 PM, Jonathan Bond-Caron <[EMAIL PROTECTED]>
wrote:
> Hi,
>
>
>
> I'm new to the PHP interna
I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
"==" doesn't exist to mean that the improvements that would
cover 99.9% of user issues with float == shouldn't be made.
It could be worse, however. At least the cast to s
Hi,
Jonathan Bond-Caron wrote:
Hi,
I'm new to the PHP internals list and I'm posting an issue I'm sure has been
mentioned before -- float comparison
I'd like to know if there are reasons not to change the default behavior
when comparing floats.
i.e. This would seem logical to me:
On Fri, May 2, 2008 at 6:52 PM, Jonathan Bond-Caron <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> I'm new to the PHP internals list and I'm posting an issue I'm sure has been
> mentioned before -- float comparison
>
>
>
> I'd like to know if there are reasons not to change the default behavior
> whe
27 matches
Mail list logo
