[Rd] format bug and patch

[Aleksey Vorona]

On 8/16/13, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
> On 13-08-15 6:07 PM, Aleksey Vorona wrote:
>> Dear R-team,
>>
>> I've been using R for a while and decided to contribute some bug
>> fixes. The first bug I tried to solve was
>> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15411
>>
>> I have attached a patch with the fix to the bug and would love to hear
>> comments about its quality.
>>
>> Also, while testing this bug I found another related issue:
>>> format(complex(real=10, imaginary=4), digits = 1);
>> [1] "10+0i"
>>
>> I think this should've been "10+4i". I have entered this as a bug
>> #15427. But a patch for formatComplex() would be a bigger change, than
>> the patch for formatReal() I made. So, before I start, I would like to
>> gauge your opinion.
>>
>> Do you agree it is a bug?
>
> No, it is a somewhat questionable design, but not a bug.  You asked for
> 1 significant digit.  format() will give both the real and imaginary
> parts accurate to 1 significant digit.  Since the real part has two
> digits, it handles the imaginary part as 04, which is rendered as 0.
>
> The questionable part of the design is that 11+4i would be rendered as
> 11+0i, i.e. two digits accuracy are given in the real part even though
> you only asked for one.  I think it would be better to be consistent
> here.  I think it makes more sense to give 11+4i (or 10+4i in your
> example) than to give 10+0i for both, but I think that is a matter of
> taste, rather than a bug fix.
>
> I have also prepared a patch for the 15411 bug; I'll compare mine to
> yours and commit something, but not for a week or so:  I am mostly
> offline until then.
>
> Duncan Murdoch
>
>

Thank you for the reply. I sent this message to Duncan only.
Re-sending this again to the list. Sorry...

My interpretation of digits=1 was that I want both real and imaginary
parts to have 1 significant digits.

Consider this command, no digits parameter this time:

> format(complex(real=5.6e+8, imaginary=2.1e+16));
[1] "0e+00+2.1e+16i"

I do not see a reason not to output the number as it was entered.

If it is not a bug, it should be documented. I'll check if I can help with that.

-- Aleksey