Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24885
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44C280B7.5050504@php.net>
Date: Sat, 22 Jul 2006 21:47:03 +0200
Reply-To:  toggg@php.net
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
MIME-Version: 1.0
To: Matt W <php_lists@realplain.com>
CC:  internals@lists.php.net
References: <007001c6ab21$b8d560e0$0201a8c0@pc1> <00fb01c6ad81$f3b61260$0201a8c0@pc1>
In-Reply-To: <00fb01c6ad81$f3b61260$0201a8c0@pc1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] number_format enhancements
From: toggg@php.net (bertrand Gugger)

Bonsoir Matt,
Matt W wrote:
> Hi,
> 
> Haven't heard any opinions on these functionality changes...  (Though I know
> more significant things keep you busy!)
> 
> Do many other people use number_format()??  Wouldn't allowing thousands
> separator as param #2 simplify things?
> 
> Any issues with the semantics of operation?  Negative precision to specify
> trailing zero removal seems fine at least, even though that's different than
> round()'s behavior.
> 
> I've now made some tests, including changes of course, in case you were just
> waiting for them?  Hope they're enough.
> 
> http://realplain.com/php/number_format.phpt
I did not look into that .phpt link
I belong only to userland , so have less to tell here.

Give some basic userland examples about what you propose to change, 
please ...
(I guess these are a part of the .phpt)

Bravo for the way you propose things.

Kind regards,
--
toggg

> ----- Original Message -----
> From: "Matt W"
> Sent: Wednesday, July 19, 2006
> 
> 
> 
>>Hi,
>>
>>There are a couple things I don't like about how number_format() works
>>currently, so I'm hoping the functionality changes this patch provides can
>>be added. :-)
>>
>>First is that when you're working with whole numbers and/or don't want any
>>decimal places, both decimal-related parameters are needed before the
>>thousands separator.  I always thought it would be logical to pass the
>>thousands separator as param #2 in those cases.  That's what my changes
>>allow if it's a non-numeric string.
>>
>>Second is that when decimals places ARE specified, I would like to be able
>>to have trailing zeros/point removed.  (Like "(string) round(...)" but
> 
> never
> 
>>scientific notation.)  I'm sure I'm not the only one that has wanted
> 
> grouped
> 
>>thousands and/or custom decimal point *without* trailing 0's. :-)  The
> 
> patch
> 
>>allows this by specifying negative decimal places -- e.g. -2 is 2 decimals
>>without extra zeros.
>>
>>Are these enhancements all right?  If they're agreed to, I'll create more
>>number_format() tests right away if desired.  Just wanted to get any
>>thoughts on the patch first.
>>
>>Also, I changed PHP_ROUND_WITH_FUZZ to skip unnecessary steps if places==0
>>(round() is nearly 20% faster then, in my quick tests), corrected the
>>misspelling of "separator" in the proto, and simplified some of the code.
>>
>>http://realplain.com/php/number_format_enhancements.diff
>>http://realplain.com/php/number_format_enhancements_5_2.diff
>>
>>
>>Thanks,
>>Matt