Hi -

OK, I'm going to take this as the consensus (unless anybody
chimes in later):

 - we'll move ###.### formats to require the %{###.###} form
 - we'll fix %{###.###} so integers print with .000 e.g.

I'm not going to change the rules for formatting complex with ##.###;
it will remain the same as with an equivalent %n specifier, which is
the current documented behavior. (each complex number has a precision
in accordance with the .#### but the padding is for the entire
complex number).

Thanks,

-michael

On 4/24/15, 12:12 AM, "Brad Chamberlain" <[email protected]> wrote:

>
>> Brad and I were discussing the ###.## style format
>> strings currently supported by writef. It might be
>> confusing that you have to escape a literal # with %#,
>> so for example if you wanted to print #13, you'd
>> write writef("%##", 13).
>>
>> The %#### syntax just looks confusing. We have
>> an alternative already - we could insist that ####.##
>> style format strings should be written like this
>> %{####.##} - which is already supported just not required.
>> That would remove any ambiguity and allow us to make
>> # print literally again.
>>
>> Any thoughts on this matter?
>
>I'm obviously biased, having proposed it, but I do think
>that the confusion of the "%## case (or alternatively,
>the behavior of a naive programmer typing writef("#%i", 13)
>and getting an error) makes it preferable to require %{}
>around such formatting strings.  This also has the benefit
>of making it more uniform that %* sequences match to the
>arguments to be written.
>
>
>
>> There are two other oddities of ###.#### type format
>> strings that I noticed:
>> 1) complex numbers can be printed in this way, but
>>    they are not padded individually but rather as
>>    a whole. For example,
>>      writef("##########.#", 1.1+2.2i)
>>    would produce
>>             "    1.1+2.2i"
>>    rather than the possibly expected:
>>             "         1.1"+        2.2i"
>
>I don't feel strongly about this case, but would tend to think it should
>either produce the second behavior or be an error.
>
>> 2) integers can be printed with ###.## but the result
>>    never has a decimal point, even if the format string
>>    included one:
>>      writef("##.##", 1);
>>    produces
>>             "    1"
>>    rather than the possibly expected:
>>             " 1.00"
>
>I was going to say that I thought this one should be an error "like I
>assume writef("%13.2dr", 1) is", but then find that it actually isn't an
>error, but very politely prints a padded 1.00 for me.  So that suggests
>it 
>should probably print 1.00 instead for consistency.
>
>Returning to the complex case, if we interpret it as "print this
>value as though it were that other type" then it either suggests
>that the complex case should be an error (since complexes don't
>coerce to reals) or that it should just print out the real part
>of the complex (which seems confusing, so I'd go back to "error").
>
>It also occurs to me that, upon requiring the curly brackets, we could
>require complex pattern formats to have two components.  I.e.:
>
>       writef("%{##.## + ##.##j}", 1.1+2.2i);
>
>would yield:
>
>        1.10 + 2.20j
>
>-Brad


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers

Reply via email to