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> ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel |
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.html where 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 |
Free forum by Nabble | Edit this page |