Re: [Rd] Issues of R_pretty in src/appl/pretty.c

[Martin Maechler]

>>>>> Suharto Anggono <suharto_angg...@yahoo.com>
>>>>> on Sat, 19 Aug 2017 14:35:07 + writes:

> Yes, they work now.  I mentioned them partly because the
> commit description said overflow for large n and partly to
> be considered for regression tests.

Thank you, Suharto.

I subsequently have amended NEWS and added such regression tests
(in svn r73108 | 2017-08-19).

Martin

> 
> On Sat, 19/8/17, Martin Maechler
> <maech...@stat.math.ethz.ch> wrote:

    > Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c
> To: "Suharto Anggono Suharto Anggono" <suharto_angg...@yahoo.com>
> Cc: r-devel@r-project.org
> Date: Saturday, 19 August, 2017, 7:47 PM
 
>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel@r-project.org>
>>>>> on Fri, 18 Aug 2017 15:44:06 + 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 ?

[...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Issues of R_pretty in src/appl/pretty.c

[Suharto Anggono Suharto Anggono via R-devel]

Yes, they work now.

I mentioned them partly because the commit description said overflow for large 
n and partly to be considered for regression tests.


On Sat, 19/8/17, Martin Maechler <maech...@stat.math.ethz.ch> wrote:

 Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c

 Cc: r-devel@r-project.org
 Date: Saturday, 19 August, 2017, 7:47 PM

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel@r-project.org>
>>>>> on Fri, 18 Aug 2017 15:44:06 + 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 <maech...@stat.math.ethz.ch> wrote:

> Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c
> To: "Martin Maechler" <maech...@stat.math.ethz.ch>

> @r-project.org
> Date: Tuesday, 15 August, 2017, 3:55 PM

[snip]

> 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Issues of R_pretty in src/appl/pretty.c

[Martin Maechler]

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel@r-project.org>
>>>>> on Fri, 18 Aug 2017 15:44:06 + 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 <maech...@stat.math.ethz.ch> wrote:

> Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c
> To: "Martin Maechler" <maech...@stat.math.ethz.ch>

> @r-project.org
> Date: Tuesday, 15 August, 2017, 3:55 PM

>>>>> Martin Maechler <maech...@stat.math.ethz.ch>
>>>>>>      on Mon, 14 Aug 2017 11:46:07 +0200 writes:

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel@r-project.org>
>>>>>>      on Fri, 11 Aug 2017 17:11:06 + writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel@r-project.org>
>>>>>>      on Fri, 11 Aug 2017 17:11:06 + 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 100 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 :
> --

Re: [Rd] Issues of R_pretty in src/appl/pretty.c

[Suharto Anggono Suharto Anggono via R-devel]

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 <maech...@stat.math.ethz.ch> wrote:

 Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c
 To: "Martin Maechler" <maech...@stat.math.ethz.ch>

@r-project.org
 Date: Tuesday, 15 August, 2017, 3:55 PM

>>>>> Martin Maechler <maech...@stat.math.ethz.ch>
>>>>>     on Mon, 14 Aug 2017 11:46:07 +0200 writes:

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel@r-project.org>
>>>>>     on Fri, 11 Aug 2017 17:11:06 + writes:
>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel@r-project.org>
>>>>>     on Fri, 11 Aug 2017 17:11:06 + 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 100 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Issues of R_pretty in src/appl/pretty.c

[Martin Maechler]

> Martin Maechler 
> on Mon, 14 Aug 2017 11:46:07 +0200 writes:

> Suharto Anggono Suharto Anggono via R-devel 
> on Fri, 11 Aug 2017 17:11:06 + writes:
> Suharto Anggono Suharto Anggono via R-devel 
> on Fri, 11 Aug 2017 17:11:06 + 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 100 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.

> well spotted!

>> 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.

> Yes, strange indeed!
> 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.

> Thank you for your analysis and suggestions!

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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Issues of R_pretty in src/appl/pretty.c

[Martin Maechler]

> Suharto Anggono Suharto Anggono via R-devel 
> on Fri, 11 Aug 2017 17:11:06 + writes:
> Suharto Anggono Suharto Anggono via R-devel 
> on Fri, 11 Aug 2017 17:11:06 + 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 100 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.

well spotted!

> 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.

Yes, strange indeed!
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.

Thank you for your analysis and suggestions!

Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Issues of R_pretty in src/appl/pretty.c

[Suharto Anggono Suharto Anggono via R-devel]

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 100 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 .

*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.

Putting parentheses may avoid the floating point overflow. For example,
i_small = dx < cell * (U * imax2(1,*ndiv) * DBL_EPSILON) *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.

The comment for 'rounding_eps' says "1e-7 is consistent with seq.default()". 
Currently, seq.default() uses 1e-10 as fuzz.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel