Suharto Anggono Suharto Anggono
2017-Aug-18 15:44 UTC
[Rd] Issues of R_pretty in src/appl/pretty.c
Examples similar to pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) with smaller 'n': pretty(c(-1,1)*1e304, n = 1e5, min.n = 1) pretty(c(-1,1)*1e306, n = 1e3, min.n = 1) A report on 'pretty' when working with integers, similar to what led to change of 'seq' fuzz, is https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15137 -------------------------------------------- On Tue, 15/8/17, Martin Maechler <maechler at stat.math.ethz.ch> wrote: Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c To: "Martin Maechler" <maechler at stat.math.ethz.ch> @r-project.org Date: Tuesday, 15 August, 2017, 3:55 PM>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>>? ?? on Mon, 14 Aug 2017 11:46:07 +0200 writes:>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>>? ?? on Fri, 11 Aug 2017 17:11:06 +0000 writes: >>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>>? ?? on Fri, 11 Aug 2017 17:11:06 +0000 writes:? ? >> See https://stat.ethz.ch/pipermail/r-devel/2017-August/074746.html for the origin of the example here. ? ? >> That ? ? >> pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) gave 20 intervals, far from 1e9, but ? ? >> pretty(c(-1,1)*1e300, n = 1e6, min.n = 1) gave 1000000 intervals ? ? >> (on a machine), made me trace through the code to function 'R_pretty' in https://svn.r-project.org/R/trunk/src/appl/pretty.c . ? ? > thank you. ? ? >> *lo is -1e300, *up is 1e300. ? ? >> cell = fmax2(fabs(*lo),fabs(*up)); ? ? >> 'cell' is 1e300. ? ? >> i_small = dx < cell * U * imax2(1,*ndiv) * DBL_EPSILON *3; ? ? >> When *ndiv is (int) 1e9, apparently cell * U * imax2(1,*ndiv) overflows to infinity and 'i_small' is 1 (true). It doesn't happen when *ndiv is (int) 1e6. [[elided Yahoo spam]] ? ? >> Putting parentheses may avoid the floating point overflow. For example, ? ? >> i_small = dx < cell * (U * imax2(1,*ndiv) * DBL_EPSILON) *3; ? ? > yes... but only if the compiler optimization steps? "keep the parentheses". ? ? > AFAIK, there is no guarantee for that. ? ? > To make sure, I'd replace the above by ? ? > U *= imax2(1,*ndiv) * DBL_EPSILON; ? ? > i_small = dx < cell * U * 3; ? ? >> The part ? ? >> U = (1 + (h5 >= 1.5*h+.5)) ? 1/(1+h) : 1.5/(1+h5); ? ? >> is strange. Because (h5 >= 1.5*h+.5) is 1 or 0, (1 + (h5 >= 1.5*h+.5)) is never zero and 1/(1+h) will always be chosen. [[elided Yahoo spam]] ? ? > here was as a change (not by me!) adding wrong parentheses ? ? > there (or maybe adding what the previously "missing" parens ? ? > implied, but not what they intended!). ? ? > The original code had been ? ?? ? ? > U = 1 + (h5 >= 1.5*h+.5) ? 1/(1+h) : 1.5/(1+h5); ? ? > and "of course" was intended to mean ? ? > U = 1 + ((h5 >= 1.5*h+.5) ? 1/(1+h) : 1.5/(1+h5)); ? ? > and this what I'll change it to, now. ? ? >> The comment for 'rounding_eps' says "1e-7 is consistent with seq.default()". Currently, seq.default() uses 1e-10 as fuzz. ? ? > Hmm, yes, thank you; this was correct when written, ? ? > but seq.default had been changed in the mean time, ? ? > namely in? svn r51095 | 2010-02-03 ? ? > Usually we are cautious / reluctant to change such things w/o ? ? > any bug that we see to fix. ? ? > OTOH, we did have? bug cases we'd wanted to amend for seq() / ? ? > seq.int(); ? ? > and I'll look into updating the "pretty - epsilon" also to ? ? > 1e-10. [[elided Yahoo spam]] I've committed now what I think has been suggested above ... to R-devel only : ------------------------------------------------------------------------ r73094 | maechler | 2017-08-15 09:10:27 +0200 (Tue, 15. Aug 2017) | 1 Zeile Ge?nderte Pfade: ?? M doc/NEWS.Rd ?? M src/appl/pretty.c ?? M src/main/engine.c ?? M tests/reg-large.R ?? M tests/reg-tests-2.Rout.save pretty(x, n) fix overflow for large n suggested by Suhartu Aggano, R-devel, 2017-08-11
>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>> on Fri, 18 Aug 2017 15:44:06 +0000 writes:> Examples similar to > pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) > with smaller 'n': > pretty(c(-1,1)*1e304, n = 1e5, min.n = 1) > pretty(c(-1,1)*1e306, n = 1e3, min.n = 1) Thank you. "But" all these work now (in R-devel, rev >= 73094) as they should, at least for me, right? Are you mentioning the "small n" examples so we could use them as regression tests (instead of the regression test I had added to tests/reg-large.R which needs enough GB and is slowish ) -- or are you seeing a platform where the above cases still don't work in (new enough) R-devel ? > A report on 'pretty' when working with integers, similar to what led to change of 'seq' fuzz, is https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15137 > -------------------------------------------- > On Tue, 15/8/17, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c > To: "Martin Maechler" <maechler at stat.math.ethz.ch> > @r-project.org > Date: Tuesday, 15 August, 2017, 3:55 PM>>>>> Martin Maechler <maechler at stat.math.ethz.ch>>>>>>> ? ?? on Mon, 14 Aug 2017 11:46:07 +0200 writes:>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org>>>>>>> ? ?? on Fri, 11 Aug 2017 17:11:06 +0000 writes:>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org>>>>>>> ? ?? on Fri, 11 Aug 2017 17:11:06 +0000 writes: > ? ? >> See https://stat.ethz.ch/pipermail/r-devel/2017-August/074746.html for the origin of the example here. > ? ? >> That > ? ? >> pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) gave 20 intervals, far from 1e9, but > ? ? >> pretty(c(-1,1)*1e300, n = 1e6, min.n = 1) gave 1000000 intervals > ? ? >> (on a machine), made me trace through the code to function 'R_pretty' in https://svn.r-project.org/R/trunk/src/appl/pretty.c . > ? ? > thank you. > ? ? >> *lo is -1e300, *up is 1e300. > ? ? >> cell = fmax2(fabs(*lo),fabs(*up)); > ? ? >> 'cell' is 1e300. > ? ? >> i_small = dx < cell * U * imax2(1,*ndiv) * DBL_EPSILON *3; > ? ? >> When *ndiv is (int) 1e9, apparently cell * U * imax2(1,*ndiv) overflows to infinity and 'i_small' is 1 (true). It doesn't happen when *ndiv is (int) 1e6. > [[elided Yahoo spam]] > ? ? >> Putting parentheses may avoid the floating point overflow. For example, > ? ? >> i_small = dx < cell * (U * imax2(1,*ndiv) * DBL_EPSILON) *3; > ? ? > yes... but only if the compiler optimization steps? "keep the parentheses". > ? ? > AFAIK, there is no guarantee for that. > ? ? > To make sure, I'd replace the above by > ? ? > U *= imax2(1,*ndiv) * DBL_EPSILON; > ? ? > i_small = dx < cell * U * 3; > ? ? >> The part > ? ? >> U = (1 + (h5 >= 1.5*h+.5)) ? 1/(1+h) : 1.5/(1+h5); > ? ? >> is strange. Because (h5 >= 1.5*h+.5) is 1 or 0, (1 + (h5 >= 1.5*h+.5)) is never zero and 1/(1+h) will always be chosen. > [[elided Yahoo spam]] > ? ? > here was as a change (not by me!) adding wrong parentheses > ? ? > there (or maybe adding what the previously "missing" parens > ? ? > implied, but not what they intended!). > ? ? > The original code had been > ? ?? > ? ? > U = 1 + (h5 >= 1.5*h+.5) ? 1/(1+h) : 1.5/(1+h5); > ? ? > and "of course" was intended to mean > ? ? > U = 1 + ((h5 >= 1.5*h+.5) ? 1/(1+h) : 1.5/(1+h5)); > ? ? > and this what I'll change it to, now. > ? ? >> The comment for 'rounding_eps' says "1e-7 is consistent with seq.default()". Currently, seq.default() uses 1e-10 as fuzz. > ? ? > Hmm, yes, thank you; this was correct when written, > ? ? > but seq.default had been changed in the mean time, > ? ? > namely in? svn r51095 | 2010-02-03 > ? ? > Usually we are cautious / reluctant to change such things w/o > ? ? > any bug that we see to fix. > ? ? > OTOH, we did have? bug cases we'd wanted to amend for seq() / > ? ? > seq.int(); > ? ? > and I'll look into updating the "pretty - epsilon" also to > ? ? > 1e-10. > [[elided Yahoo spam]] > I've committed now what I think has been suggested > above ... to R-devel only : > ------------------------------------------------------------------------ > r73094 | maechler | 2017-08-15 09:10:27 +0200 (Tue, 15. Aug 2017) | 1 Zeile > Ge?nderte Pfade: > ?? M doc/NEWS.Rd > ?? M src/appl/pretty.c > ?? M src/main/engine.c > ?? M tests/reg-large.R > ?? M tests/reg-tests-2.Rout.save > pretty(x, n) fix overflow for large n suggested by Suhartu Aggano, R-devel, 2017-08-11 > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -------------------------------------------- > On Tue, 15/8/17, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c > To: "Martin Maechler" <maechler at stat.math.ethz.ch> > @r-project.org > Date: Tuesday, 15 August, 2017, 3:55 PM>>>>> Martin Maechler <maechler at stat.math.ethz.ch>>>>>>> ? ?? on Mon, 14 Aug 2017 11:46:07 +0200 writes:>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org>>>>>>> ? ?? on Fri, 11 Aug 2017 17:11:06 +0000 writes:>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org>>>>>>> ? ?? on Fri, 11 Aug 2017 17:11:06 +0000 writes: > ? ? >> See https://stat.ethz.ch/pipermail/r-devel/2017-August/074746.html for the origin of the example here. > ? ? >> That > ? ? >> pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) gave 20 intervals, far from 1e9, but > ? ? >> pretty(c(-1,1)*1e300, n = 1e6, min.n = 1) gave 1000000 intervals > ? ? >> (on a machine), made me trace through the code to function 'R_pretty' in https://svn.r-project.org/R/trunk/src/appl/pretty.c . > ? ? > thank you. > ? ? >> *lo is -1e300, *up is 1e300. > ? ? >> cell = fmax2(fabs(*lo),fabs(*up)); > ? ? >> 'cell' is 1e300. > ? ? >> i_small = dx < cell * U * imax2(1,*ndiv) * DBL_EPSILON *3; > ? ? >> When *ndiv is (int) 1e9, apparently cell * U * imax2(1,*ndiv) overflows to infinity and 'i_small' is 1 (true). It doesn't happen when *ndiv is (int) 1e6. > [[elided Yahoo spam]] > ? ? >> Putting parentheses may avoid the floating point overflow. For example, > ? ? >> i_small = dx < cell * (U * imax2(1,*ndiv) * DBL_EPSILON) *3; > ? ? > yes... but only if the compiler optimization steps? "keep the parentheses". > ? ? > AFAIK, there is no guarantee for that. > ? ? > To make sure, I'd replace the above by > ? ? > U *= imax2(1,*ndiv) * DBL_EPSILON; > ? ? > i_small = dx < cell * U * 3; > ? ? >> The part > ? ? >> U = (1 + (h5 >= 1.5*h+.5)) ? 1/(1+h) : 1.5/(1+h5); > ? ? >> is strange. Because (h5 >= 1.5*h+.5) is 1 or 0, (1 + (h5 >= 1.5*h+.5)) is never zero and 1/(1+h) will always be chosen. > [[elided Yahoo spam]] > ? ? > here was as a change (not by me!) adding wrong parentheses > ? ? > there (or maybe adding what the previously "missing" parens > ? ? > implied, but not what they intended!). > ? ? > The original code had been > ? ?? > ? ? > U = 1 + (h5 >= 1.5*h+.5) ? 1/(1+h) : 1.5/(1+h5); > ? ? > and "of course" was intended to mean > ? ? > U = 1 + ((h5 >= 1.5*h+.5) ? 1/(1+h) : 1.5/(1+h5)); > ? ? > and this what I'll change it to, now. > ? ? >> The comment for 'rounding_eps' says "1e-7 is consistent with seq.default()". Currently, seq.default() uses 1e-10 as fuzz. > ? ? > Hmm, yes, thank you; this was correct when written, > ? ? > but seq.default had been changed in the mean time, > ? ? > namely in? svn r51095 | 2010-02-03 > ? ? > Usually we are cautious / reluctant to change such things w/o > ? ? > any bug that we see to fix. > ? ? > OTOH, we did have? bug cases we'd wanted to amend for seq() / > ? ? > seq.int(); > ? ? > and I'll look into updating the "pretty - epsilon" also to > ? ? > 1e-10. > [[elided Yahoo spam]] > I've committed now what I think has been suggested > above ... to R-devel only : > ------------------------------------------------------------------------ > r73094 | maechler | 2017-08-15 09:10:27 +0200 (Tue, 15. Aug 2017) | 1 Zeile > Ge?nderte Pfade: > ?? M doc/NEWS.Rd > ?? M src/appl/pretty.c > ?? M src/main/engine.c > ?? M tests/reg-large.R > ?? M tests/reg-tests-2.Rout.save > pretty(x, n) fix overflow for large n suggested by Suhartu Aggano, R-devel, 2017-08-11