Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24847
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 21 Jul 2006 19:14:53 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1158220430.20060721191453@marcus-boerger.de>
To: Matt W <php_lists@realplain.com>
Cc: internals@lists.php.net, Marcus Boerger <helly@php.net>
In-Reply-To: <00e101c6ac9c$d3e3b8b0$0201a8c0@pc1>
References: <018101c6abf6$ee273810$0201a8c0@pc1> <105846538.20060720212112@marcus-boerger.de> <00e101c6ac9c$d3e3b8b0$0201a8c0@pc1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [v][sf]printf additions (#, E, g, G)
From: helly@php.net (Marcus Boerger)

Hello Matt,

  sounds good then, keep going.

best regards
marcus

Friday, July 21, 2006, 10:08:19 AM, you wrote:

> Hi Marcus,

> ----- Original Message ----- 
> From: "Marcus Boerger"
> Sent: Thursday, July 20, 2006 2:21 PM
> Subject: Re: [PHP-DEV] [v][sf]printf additions (#, E, g, G)


>> Hello Matt,
>>
>> Thursday, July 20, 2006, 2:20:46 PM, you wrote:
>>
>> > Hi,
>>
>> > I've wished there was a *printf() float specifier that wouldn't include
>> > trailing zeros/point, as simply converting to string (echo, %s, etc.)
> can
>> > result in scientific notation, which I *don't* want (%g in
>> > convert_to_string()).  The only other way that would result in what I
> want
>> > is number_format() with my "no-extra-zeros option" patch. ;-)  So I was
>> > originally looking for how to NOT pad %f to the specified precision,
> then I
>> > thought why not add more of the stuff from C?  (And I see it's marked
> "not
>> > done" in formatted_print.c.)
>>
>> > Can/should I go ahead and add support for the # flag/specifier, g/G, and
> E
>> > (the missing compliment to e)?  Make everything work like C, except #
> used
>> > with f/F, which would mean "remove trailing 0's/point" -- as C's
> behavior
>> > with # and f (add point even when precision=0?) can be done in PHP.  (I
>> > assume C's is for when precision is specified with * + parameter?)
>>
>> Having more conversion specifiers here won't hurt. If it can be done
>> in a way compatible to other languages especially like C it should be
>> done in that way. If PHP has already closed the way by choosing opposite
>> defaults the opposite should everntually also work.

> Sorry, not sure what you mean in the last sentence as far as the additions
> I'm asking about.  I agree about compatibility with C's specifiers, but
> PHP's *printf() has things that C's doesn't (%b; alternate padding
> specifier) and vice versa (PHP's doesn't support "*" width/precision -- nor
> does it need to; also no %n).  That's why I thought it would be OK to let #
> with f/F mean no trailing 0's.

> Other than that, g/G would, of course, be new.  Unless it's not needed if 1)
> my "alternate form" %f idea is added, or 2) its precision would confuse
> users since it means "number of significant digits" with g/G, rather than
> decimal places.

> # with e/E would include the decimal point even if precision=0
> # with g/G *wouldn't* strip trailing 0's
> # with o would include "0" prefix with non-zero result
> # with x/X would include "0x"/"0X" prefix with non-zero result

> All like C AFAIK, again except %#.3f, for example, wouldn't have trailing
> zeros/point.  As you can probably tell, I don't like extra 0's unless
> there's a *need* to always have the same width (same idea with
> number_format()). :-)  I'm sure other PHP users feel the same way and would
> like this alternate %f form, even if no other language has it!

>> Best regards,
>>  Marcus

> Thanks for the reply,
> Matt




Best regards,
 Marcus