TL;DR : It's more complicated and needs more discussion

(which I start below)

> Hi,

> > 1e10+5i

> [1] 1e+10+0e+00i

> > Im(1e10+5i)

> [1] 5

>

> maybe little better...

>

> --- R-3.5.1.orig/src/main/complex.c 2018-03-26 07:02:25.000000000 +0900

> +++ R-3.5.1/src/main/complex.c 2018-07-10 12:50:42.523874767 +0900

> @@ -381,6 +381,7 @@

> r->i = fround(pow10 * x->i, digits)/pow10;

> } else {

> digits = (double)(dig);

> + if(digits < 1) digits=1; /* a little better */

> r->r = fround(x->r, digits);

> r->i = fround(x->i, digits);

> }

>

>

> --

> Best Regards,

> --

> Eiji NAKAMA <nakama (a) ki.rim.or.jp>

> "\u4e2d\u9593\u6804\u6cbb" <nakama (a) ki.rim.or.jp>

Thanks a lot, Eiji!

Yes, your proposed change does "prevent the worst", in this

case, however it is more complicated.

I do think the current display {i.e., format(), as.character(),..},

of such complex numbers is far from optimal, not only in the example

you show above but also more generally, when the real and

complex parts of the complex vector(s) are of different magnitude.

If only the Mod(z) of the complex number z was of importance, one

could argue that indeed it makes sense to use the same format

for the real and imaginary parts; this is however not always the

case, and rather the Re(z) and/or Im(z) are of interest in

themselves. For such cases, the current formatting of complex

numbers is unfortunate also in my view.

I've checked other systems:

1) octave, matlab, python

2) mathematica, maple

and they all format Re() and Im() separately, and I think we

should do.

However, we have "known" about this for a long time

In R/tests/reg-tests-2.Rout.save, line 5641 ff, we have had,

from svn c39481 | 2006-09-22 ), log 'tweak printing of complex numbers' ,

> ## printing of complex numbers of very different magnitudes

> 1e100 + 1e44i

[1] 1e+100+0e+00i

> 1e100 + pi*1i*10^(c(-100,0,1,40,100))

[1] 1e+100+ 0.000000e+00i 1e+100+ 0.000000e+00i 1e+100+ 0.000000e+00i

[4] 1e+100+ 0.000000e+00i 1e+100+3.141593e+100i

> ## first was silly, second not rounded correctly in 2.2.0 - 2.3.1

> ## We don't get them lining up, but that is a printf issue

> ## that only happens for very large complex nos.

>

>

> ### end of tests added in 2.4.0 ###

and with your change the output of the above example also

changes.

I now found more history:

The fundamental changes is indeed from 2005, for R 2.2.0 :

------------------------------------------------------------------------

r35253 | ripley | 2005-08-11 18:34:24 +0200 (Thu, 11 Aug 2005) | 2 lines

Changed paths:

M NEWS

M src/main/complex.c

M src/main/format.c

M tests/arith.R

M tests/arith.Rout.save

M tests/complex.R

M tests/complex.Rout.save

M tests/print-tests.Rout.save

enhance printing of complex numbers to use pairs together.

---------------------------------------------------------------

where the NEWS entry (now in <R>/doc/NEWS.2 ) has been

o The printing of complex numbers has changed, handling numbers

as a whole rather than in two parts. So both real and

imaginary parts are shown to the same accuracy, with the

'digits' parameter referring to the accuracy of the larger

component, and both components are shown in fixed or

scientific notation (unless one is entirely zero when it is

always shown in fixed notation).

There was a bug in the implementation on which Robin Hankin

wrote about year later in a thread on R-devel :

https://stat.ethz.ch/pipermail/r-devel/2006-September/042792.htmlwhere Brian Ripley mentioned the (above, not the buggy one)

behavior as "by design", and Robin then also found and mentioned

the above entry. ... and notably the above regression test was

added after the bug fix also in Sept. 2006.

Apart from that NEWS entry (now basically only visible in the

source code), the only documentation about this behavior, is the

one sentence in the ?signif help page

"Complex numbers are rounded to retain the specified number

of digits in the larger of the components"

And where this does make (some) sense for

signif(<complex>, digits),

it seems wrong to me (and you) for format() and print() and

I think we should reconsider using it when format()ing complex

numbers.

Note that your proposed change does change the z_prec_r()

function which in fact *is* used for signif(<complex>), and so

your change also does affect signif(<complex>) which I think is

more than I'd want here.

For instance, it would change the following (regression test in

tests/complex.R )

> signif(1.678932e80+0i, 5)

[1] 1.678932e+80+0i

>

instead of really showing 5 digits for the real part as it does

now :

[1] 1.6789e+80+0i

---------------------

I'm proposing to reconsider and change such that

1) print() {and auto-print} and format() of complex numbers should

treat Re() and Im() separately, and identically to how double()

are print()ed / format()ted in such case, notably, using

'digits' to both parts "separately".

2) We can and probably should keep signif(<complex>)'s behavior

as current, as that has been documented to behave as it does

for almost 13 years.

Martin

______________________________________________

[hidden email] mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel