https://wiki.php.net/rfc/php_ini_bcmath_default
This is the only other RFC I've been rummaging around in my head but
hadn't brought up.
I initially like the concept (arbitrary precision operations).
But please don't add another ini setting. Especially one where
logic can change depending on the setting. I don't want a case
where pow(2, 65)-1 will return different answers depending on the ini.
That's just asking for problems.
Instead, perhaps a pythonic approach may be useful (storing as
int/float for small values, but auto-converting to arbitrary precision
if the int/float can't exactly represent what was
requested/computed)... Just a thought to make it useful without the
ini complexity or performance hits.
Although this will present a significant BC break (internally, zend
engine wise), so it would probably be limited to a major release
anyway...
Just a thought...
Anthony
https://wiki.php.net/rfc/php_ini_bcmath_default
This is the only other RFC I've been rummaging around in my head but
hadn't brought up.
I initially like the concept (arbitrary precision operations).
But please don't add another ini setting. Especially one where
logic can change depending on the setting. I don't want a case
where pow(2, 65)-1 will return different answers depending on the ini.
That's just asking for problems.
I edited the RFC while you were sending this for clarification. This
setting would only affect the math operators (+,/,*,-) mapping them to
their bcmath equivalents. Math functions like pow would not be
affected.
Instead, perhaps a pythonic approach may be useful (storing as
int/float for small values, but auto-converting to arbitrary precision
if the int/float can't exactly represent what was
requested/computed)... Just a thought to make it useful without the
ini complexity or performance hits.Although this will present a significant BC break (internally, zend
engine wise), so it would probably be limited to a major release
anyway...
With a setting there would be no BC break since, if you turn it on,
presumably you want it on. Also, for scripts where the author wasn't
aware of the peril of floating point math the setting could actually
fix their existing code.
But please don't add another ini setting. Especially one where
logic can change depending on the setting. I don't want a case
where pow(2, 65)-1 will return different answers depending on the ini.
That's just asking for problems.I edited the RFC while you were sending this for clarification. This
setting would only affect the math operators (+,/,*,-) mapping them to
their bcmath equivalents. Math functions like pow would not be
affected.
Actually, I see that as even worse. Why would 2 * 4 be possible to be
different from pow(2, 3)? That doesn't really make sense (to me). I
think if it was added, all of the math related extensions would need
to be (should be) updated as suits. Otherwise it's just another
random inconsistency...
Instead, perhaps a pythonic approach may be useful (storing as
int/float for small values, but auto-converting to arbitrary precision
if the int/float can't exactly represent what was
requested/computed)... Just a thought to make it useful without the
ini complexity or performance hits.Although this will present a significant BC break (internally, zend
engine wise), so it would probably be limited to a major release
anyway...With a setting there would be no BC break since, if you turn it on,
presumably you want it on. Also, for scripts where the author wasn't
aware of the peril of floating point math the setting could actually
fix their existing code.
When I said BC break, I'm talking about at the engine level. So all
3pd code that hooks into the engine (PECL extensions mainly) would be
broken, as the structure of the ZVal would need to change to
accommodate the bignum representation...
Actually, I see that as even worse. Why would 2 * 4 be possible to be
different from pow(2, 3)? That doesn't really make sense (to me). I
think if it was added, all of the math related extensions would need
to be (should be) updated as suits. Otherwise it's just another
random inconsistency...
The problem is that not all the math functions have BCmath
equivalents. Bit of scope creep here if that is to be done.
When I said BC break, I'm talking about at the engine level. So all
3pd code that hooks into the engine (PECL extensions mainly) would be
broken, as the structure of the ZVal would need to change to
accommodate the bignum representation...
BCMath returns the value as a string. I don't know what the
ramification of that inside the engine is, but numbers end up being
held as strings when this is active.
I'm not trying to make light of these problems - they are significant.
But PHP's current behavior is, to a non-cs major, not intuitive.
I've progressed in my career to where I personally aren't bothered by
this problem, but there are a lot of beginning scripters that can be
caught with this.
Michael, I'm with Anthony, in that you shouldn't change behaviour of
this nature with an ini setting.
I would bring more pain than what it takes away.
This is one of those gotchas that everyone comes across, like you noted.
The main issue is that floating point arithmetic != real number
arithmetic; and bc functions do solve the issue, but make for some
ugly code in complex operations...
Since Anthony mentioned Python, maybe the discussion should be if PHP
should/could support decimal like Python does
http://docs.python.org/library/decimal
Now that would be something interesting to see discussed!!
2012.03.06 23:03 Michael Morris rašė:
https://wiki.php.net/rfc/php_ini_bcmath_default
This is the only other RFC I've been rummaging around in my head but
hadn't brought up.
PHP has something similar with mbstring function overloading. If people
use both string and mbstring functions, they can no longer trust string
functions. mbstring function overloading makes string functions
unreliable. Functions, that are not charset aware by default, can start
operating in different charset with a single flip in interpreter config.
First you start cursing, then you have to implement workarounds to deal
with features designed for people, who want to use different functions
without changing a single line in their code. You are asking to do same
thing in math functions.
If you want to use bcmath, use bcmath in your code.
--
Tomas
On Tue, Mar 6, 2012 at 4:47 PM, Tomas Kuliavas
tokul@users.sourceforge.net wrote:
2012.03.06 23:03 Michael Morris rašė:
https://wiki.php.net/rfc/php_ini_bcmath_default
This is the only other RFC I've been rummaging around in my head but
hadn't brought up.PHP has something similar with mbstring function overloading. If people
use both string and mbstring functions, they can no longer trust string
functions. mbstring function overloading makes string functions
unreliable. Functions, that are not charset aware by default, can start
operating in different charset with a single flip in interpreter config.
First you start cursing, then you have to implement workarounds to deal
with features designed for people, who want to use different functions
without changing a single line in their code. You are asking to do same
thing in math functions.
No, I am not. This RFC involves the operators, not the functions.
Addition, division, multiplication, subtraction. The PHP math
functions will behave as they always have.
If you want to use bcmath, use bcmath in your code.
I do use it. It's a pain in the ass to read because you have to LISP
nest all the operations. You can't tell me this is easy or intuitive
to read...
bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul(
$bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 )
Compared to
$bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty *
$monthsAhead;
You can do it, but it's eye bleeding.
I do use it. It's a pain in the ass to read because you have to LISP
nest all the operations. You can't tell me this is easy or intuitive
to read...bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul(
$bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 )Compared to
$bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty *
$monthsAhead;You can do it, but it's eye bleeding.
I agree with you, how about having the bcmath extension support a more
general (and even better, non-BC-breaking) function supporting the
order of math operations (and maybe even math functions)... Something
like a bc(string $operations [, int $scale = 2])
Supporting passing: bc("(29.99 + $a) * $b - pow(10, $c) / 2");
Came across something like that in the manual: http://php.net/ref.bc#107014
How's that for a quick 'n dirty idea to solve this issue?
~ Daniel Macedo
Excellent idea. bcmath is already not the highest performance thing in
the world, so adding a function that parses a more reasonable looking
expression would not be an unacceptable compromise for most.
It also doesn't give you the false impression that since operators do
the right thing functions are going to do the right thing too. That's
very muddy and confusing.
I do use it. It's a pain in the ass to read because you have to LISP
nest all the operations. You can't tell me this is easy or intuitive
to read...bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul(
$bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 )Compared to
$bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty *
$monthsAhead;You can do it, but it's eye bleeding.
I agree with you, how about having the bcmath extension support a more
general (and even better, non-BC-breaking) function supporting the
order of math operations (and maybe even math functions)... Something
like a bc(string $operations [, int $scale = 2])Supporting passing: bc("(29.99 + $a) * $b - pow(10, $c) / 2");
Came across something like that in the manual: http://php.net/ref.bc#107014
How's that for a quick 'n dirty idea to solve this issue?~ Daniel Macedo
--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
hi Michael,
Nice idea but technically impossible to implement without massive
performance loss.
There was an idea to actually replace the math ops with MPIR
implementation, but tightly integrated. That's something that could be
very good to have. However it is a huge task.
Cheers,
https://wiki.php.net/rfc/php_ini_bcmath_default
This is the only other RFC I've been rummaging around in my head but
hadn't brought up.--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
https://wiki.php.net/rfc/php_ini_bcmath_default
This is the only other RFC I've been rummaging around in my head but
hadn't brought up.
I know Scott has/had a patch for a special big num type that uses
bcmath. But don't know what's the status. Scott?
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Do we have any solid data on the performance difference between arithmetic
operations with bcmath and without? To me, that would be immensely helpful
in framing this. I like the idea, but the potential performance drag
concerns me. Knowing exactly how big a drag we're looking at would make it
easier to put this into some sort of context IMHO.
--Kris
he was using mpir. The idea was based on a plan I discussed with him
to add large integers support transparently to php. Not sure either
what's the status :)
https://wiki.php.net/rfc/php_ini_bcmath_default
This is the only other RFC I've been rummaging around in my head but
hadn't brought up.I know Scott has/had a patch for a special big num type that uses
bcmath. But don't know what's the status. Scott?cheers,
Derick--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
<snip>The mailinglist guidelines also are for you, so let me repeat what I
wrote yesterday:
Please read
"http://ch2.php.net/reST/php-src/trunk_README.MAILINGLIST_RULES"; which
states:"3. Do not top post. Place your answer underneath anyone you wish to
quote and remove any previous comment that is not relevant to your
post."For more information on how to quote properly on mailinglists:
cheers,
Derick
The mailinglist guidelines also are for you, so let me repeat what I
wrote yesterday:
To write a one line reply to another one line reply is just fine.
Make us all a favour, don't waste even more bandwidth and use a mail
client that can deal with that, thanks :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi Pierre,
The length of the reply being replied
to is irrelevant. The length of the reply is also
The mailinglist guidelines also are for you, so let me repeat what I
wrote yesterday:
irrelevant. Derick's point (unless I'm mistaken) was to remind everyone of
the accepted etiquette.
To write a one line reply to another one line reply is just fine.
Make us all a favour, don't waste even more bandwidth and use a mail
client that can deal with that, thanks :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Top posting puts the reply out of context. Which greatly distracts from
the readability of a thread, particularly when several sub-conversations
happen within the larger thread.
P.S. Just to be safe, I have top, middle and bottom posted this reply and
included the entire contents of all of the earlier posts in the thread.
The only fact that this reminder ended in such a discussion pretty
much makes my point.
Most of the times I do clean out before replying, but I really do not
need mailing list police and certainly not willing to argue even more
about this topic, read: I have other things to do that to deal with
such discussions :)
Cheers,
Pierre Joye wrote:
The mailinglist guidelines also are for you, so let me repeat what I
wrote yesterday:
To write a one line reply to another one line reply is just fine.
So why include all the rest of the crap as well ... THAT is the waste of
bandwidth, and a pain to deal with what ever client one is using. The bulk of
your previous quoting was totally unnecessary and on some threads several pages
of 'sigs and adverts' is what we are moaning about, so please set an example to
others.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Am 07.03.2012 11:12, schrieb Pierre Joye:
The mailinglist guidelines also are for you, so let me repeat what I
wrote yesterday:To write a one line reply to another one line reply is just fine.
Make us all a favour, don't waste even more bandwidth and use a mail
client that can deal with that, thanks :)
why do you not understand the simple fact that
NO CLIENT can fix this, not now and not in the future
- answer 4
- answer 2
- initial post
- answer 1
- answer 3
should i draw you a picture for help?
should i draw you a picture for help?
Yes, but please make sure that it is on 24# cream paper. And draw in charcoal, because professionals don't use pencils.
Am 07.03.2012 11:05, schrieb Derick Rethans:
"3. Do not top post. Place your answer underneath anyone you wish to
quote and remove any previous comment that is not relevant to your
post."
Couldn't agree more, such quoting is really annoying. While we are at
the topic of etiquette: please use your realname when posting to this
list. Thanks!
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
On Wed, Mar 7, 2012 at 10:31 AM, Sebastian Bergmann sebastian@php.netwrote:
Am 07.03.2012 11:05, schrieb Derick Rethans:
"3. Do not top post. Place your answer underneath anyone you wish to
quote and remove any previous comment that is not relevant to your
post."Couldn't agree more, such quoting is really annoying. While we are at
the topic of etiquette: please use your realname when posting to this
list. Thanks!--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/--
You guys make a valid point, but I think Pierre does as well. Creating a
stink over a quick one-liner reply seems a bit excessive IMHO. If this is
really such a problem, we need to try and think of a solution other than
just "policing," which obviously hasn't worked.
Just my five cents (damn inflation!).
--Kris
On Wed, Mar 7, 2012 at 10:31 AM, Sebastian Bergmann sebastian@php.netwrote:
Am 07.03.2012 11:05, schrieb Derick Rethans:
"3. Do not top post. Place your answer underneath anyone you wish to
quote and remove any previous comment that is not relevant to your
post."Couldn't agree more, such quoting is really annoying. While we are at
the topic of etiquette: please use your realname when posting to this
list. Thanks!--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/--
This bit is not needed, so trim it!
You guys make a valid point, but I think Pierre does as well. Creating a
stink over a quick one-liner reply seems a bit excessive IMHO. If this is
really such a problem, we need to try and think of a solution other than
just "policing," which obviously hasn't worked.
Part of quoting correctly, is to trim out things you're not replying
too. And remove signatures as well (any proper client does that!). Which
means, everything after the "-- " + return should be removed.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Derick Rethans wrote:
Part of quoting correctly, is to trim out things you're not replying
too. And remove signatures as well (any proper client does that!). Which
means, everything after the "-- " + return should be removed.
Exactly ... One line answers are not a problem ... they don't need any more than
that :)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php