Re: [Rd] "plot.ts" doesn't respect the value of "pch" (+ blocked from Bugzilla signups)
> On Aug 24, 2016, at 5:59 PM, Gregory Werbin
> wrote:
>
> I did a search on Bugzilla for "plot.ts" and didn't find anything on this
> issue. I tried to sign up for Bugzilla to report it, but my e-mail address
> didn't pass your "syntax checking" for a legal e-mail address.
>
> The bug is easily reproducible on my machine as follows:
>
> ## start
>
> # generate some data
> y <- arima.sim(list(), 150)
>
> # this will definitely dispatch to a ".ts" method
> class(y)[1] == 'ts'
>
> # compare and note that `cex = 0.5` has no effect
> plot(y, type = 'b', pch = 16)
> plot(y, type = 'b', pch = 16, cex = 0.5)
>
> # it works if `y` is coerced back to a regular vector
> plot(as.numeric(y), type = 'b', pch = 16, cex = 0.5)
>
> # another way to see the issue
> plot.ts(y, type = 'b', pch = 16, cex = 0.5)
> plot.default(y, type = 'b', pch = 16, cex = 0.5)
>
> ## end
>
> Skimming through source code for `plot.ts`, it seems like the `cex` argument
> is being "eaten" by a `...` somewhere without being properly passed to
> `plot.default`.
'...' does not "eat" parameters, it passes them on.
Looking at the very top of the body we see this in the definition of the
internal `plotts` function:
cex = par("cex"), lty = par("lty"), lwd = par("lwd"),
axes = TRUE, frame.plot = axes, ann = par("ann"), cex.lab =
par("cex.lab"),
col.lab = par("col.lab"), font.lab = par("font.lab"),
cex.axis = par("cex.axis"), col.axis = par("col.axis"),
And at the end of the body we se the call to plotts (including the "dots")
So I would suggest using par-settings.
par(cex=0.5)
plot(y, type = 'b', pch = 16)
(Question seems more appropriate for r-help.)
--
David.
>
> The output of `R.version` is:
> platform x86_64-apple-darwin15.5.0
> arch x86_64
> os darwin15.5.0
> system x86_64, darwin15.5.0
> status
> major 3
> minor 3.1
> year 2016
> month 06
> day21
> svn rev70800
> language R
> version.string R version 3.3.1 (2016-06-21)
> nickname Bug in Your Hair
>
> Greg
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "plot.ts" doesn't respect the value of "pch" (+ blocked from Bugzilla signups)
> David Winsemius
> on Thu, 25 Aug 2016 00:00:04 -0700 writes:
>> On Aug 24, 2016, at 5:59 PM, Gregory Werbin
wrote:
>>
>> I did a search on Bugzilla for "plot.ts" and didn't find anything on
this issue. I tried to sign up for Bugzilla to report it, but my e-mail address
didn't pass your "syntax checking" for a legal e-mail address.
If you read (and you should :-)
https://www.r-project.org/bugs.html
you will see the reason for the "syntax checking".
We currently need manual white listing (of e-mail addresses),
because we had months of "spam" bug reports and then complete
spam explosion aka "bug site devastation" action.
I have added your e-mail (above) to be valid / legal...
Please "subscribe", because we will not keep that changed string for so long.
[ Actually, I'd tend to say that for short term, we are now
looking for volunteers for "bugzilla moderation" ]
>>
>> The bug is easily reproducible on my machine as follows:
>>
>> ## start
>>
>> # generate some data
>> y <- arima.sim(list(), 150)
>>
>> # this will definitely dispatch to a ".ts" method
>> class(y)[1] == 'ts'
>>
>> # compare and note that `cex = 0.5` has no effect
>> plot(y, type = 'b', pch = 16)
>> plot(y, type = 'b', pch = 16, cex = 0.5)
>>
>> # it works if `y` is coerced back to a regular vector
>> plot(as.numeric(y), type = 'b', pch = 16, cex = 0.5)
>>
>> # another way to see the issue
>> plot.ts(y, type = 'b', pch = 16, cex = 0.5)
>> plot.default(y, type = 'b', pch = 16, cex = 0.5)
>>
>> ## end
>>
>> Skimming through source code for `plot.ts`, it seems like the `cex`
argument is being "eaten" by a `...` somewhere without being properly passed to
`plot.default`.
> '...' does not "eat" parameters, it passes them on.
> Looking at the very top of the body we see this in the definition of the
internal `plotts` function:
> cex = par("cex"), lty = par("lty"), lwd = par("lwd"),
> axes = TRUE, frame.plot = axes, ann = par("ann"), cex.lab =
par("cex.lab"),
> col.lab = par("col.lab"), font.lab = par("font.lab"),
> cex.axis = par("cex.axis"), col.axis = par("col.axis"),
> And at the end of the body we se the call to plotts (including the "dots")
> So I would suggest using par-settings.
> par(cex=0.5)
> plot(y, type = 'b', pch = 16)
as a workaround, yes, thank you David!
> (Question seems more appropriate for r-help.)
Still, I would tend to think that it was reasonable feature
request to ask for plot.ts() to be improved there, and then
R-devel or the R-bugzilla would be ok, too.
Martin Maechler, ETH Zurich
> --
> David.
>>
>> The output of `R.version` is:
>> platform x86_64-apple-darwin15.5.0
>> arch x86_64
>> os darwin15.5.0
>> system x86_64, darwin15.5.0
>> status
>> major 3
>> minor 3.1
>> year 2016
>> month 06
>> day21
>> svn rev70800
>> language R
>> version.string R version 3.3.1 (2016-06-21)
>> nickname Bug in Your Hair
>>
>> Greg
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> David Winsemius
> Alameda, CA, USA
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "plot.ts" doesn't respect the value of "pch" (+ blocked from Bugzilla signups)
I've had a chance to read the source more thoroughly. The chain of
events is as follows:
1. Local function `plotts()` is defined with argument `cex` that
defaults to `par("cex")`
2. `...` is passed to `plotts()`. If "cex" is an element in `...`,
inside `plotts()` the variable `cex` is assigned thereby (overriding the
default arg). Importantly, this means that the element "cex" is captured
and _removed_ from `...`. `...` is eventually passed to `plot.window()`.
3.
- In the univariate case (NCOL(x) == 1): When `lines.default()` is
called to actually plot the data
(https://github.com/wch/r-source/blob/trunk/src/library/stats/R/ts.R#L588
and
https://github.com/wch/r-source/blob/trunk/src/library/stats/R/ts.R#L597
for reference), `cex` is not included in the call.
- In the bivariate case (NCOL(x) > 1): Because "cex" was captured and
removed from `...`, it is not passed to `plot.default` when it is called
(https://github.com/wch/r-source/blob/trunk/src/library/stats/R/ts.R#L548).
It turns out that the "eating" is not being done by `...` but by the
signature of `plotts`.
The documentation currently reads:
...: additional graphical arguments, see 'plot', 'plot.default' and
'par'.
This, to me, suggests parity with the 'plot' function in how the
arguments in '...' are handled. Therefore either the code is wrong or
the documentation is incomplete and misleading.
I filed this is as a bug because it's undocumented, and inconsistent
with how other arguments typically passed through `plot.default` are
handled.
I'll be happy to do the patch myself -- I just need to know which thing
to patch (the source or the docs).
Greg
On 2016-08-25 03:00, David Winsemius wrote:
On Aug 24, 2016, at 5:59 PM, Gregory Werbin
wrote:
I did a search on Bugzilla for "plot.ts" and didn't find anything on
this issue. I tried to sign up for Bugzilla to report it, but my
e-mail address didn't pass your "syntax checking" for a legal e-mail
address.
The bug is easily reproducible on my machine as follows:
## start
# generate some data
y <- arima.sim(list(), 150)
# this will definitely dispatch to a ".ts" method
class(y)[1] == 'ts'
# compare and note that `cex = 0.5` has no effect
plot(y, type = 'b', pch = 16)
plot(y, type = 'b', pch = 16, cex = 0.5)
# it works if `y` is coerced back to a regular vector
plot(as.numeric(y), type = 'b', pch = 16, cex = 0.5)
# another way to see the issue
plot.ts(y, type = 'b', pch = 16, cex = 0.5)
plot.default(y, type = 'b', pch = 16, cex = 0.5)
## end
Skimming through source code for `plot.ts`, it seems like the `cex`
argument is being "eaten" by a `...` somewhere without being properly
passed to `plot.default`.
'...' does not "eat" parameters, it passes them on.
Looking at the very top of the body we see this in the definition of
the internal `plotts` function:
cex = par("cex"), lty = par("lty"), lwd = par("lwd"),
axes = TRUE, frame.plot = axes, ann = par("ann"), cex.lab =
par("cex.lab"),
col.lab = par("col.lab"), font.lab = par("font.lab"),
cex.axis = par("cex.axis"), col.axis = par("col.axis"),
And at the end of the body we se the call to plotts (including the
"dots")
So I would suggest using par-settings.
par(cex=0.5)
plot(y, type = 'b', pch = 16)
(Question seems more appropriate for r-help.)
--
David.
The output of `R.version` is:
platform x86_64-apple-darwin15.5.0
arch x86_64
os darwin15.5.0
system x86_64, darwin15.5.0
status
major 3
minor 3.1
year 2016
month 06
day21
svn rev70800
language R
version.string R version 3.3.1 (2016-06-21)
nickname Bug in Your Hair
Greg
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] summary.default rounding on numeric seems inconsistent with other R behaviors
> John Mount > on Wed, 24 Aug 2016 07:25:50 -0700 writes: >> On Aug 24, 2016, at 2:36 AM, Martin Maechler >> wrote: >> >>> >> >> [Talking to myself .. ;-)] Yes, but that's the tough part >> to change. >> >> This thread's topic is really only about changing >> summary.default(), and I have started testing such a >> change now, and that does seem very sensible: >> >> - No rounding in summary.default(), but - (almost) >> back-compatible rounding in its print() method. >> >> My current plan is to commit this to R-devel in a day or >> so, unless unforeseen issues emerge. >> >> Martin >> > That is potentially a very good outcome. Thank you so > much for producing and testing a patch. I have now committed such a change to R-devel: r71150 | maechler | 2016-08-25 21:57:19 +0200 (Thu, 25 Aug 2016) | 1 line Changed paths: M /trunk/doc/NEWS.Rd M /trunk/src/library/base/R/summary.R M /trunk/src/library/base/man/summary.Rd M /trunk/src/library/stats/R/ecdf.R M /trunk/tests/Examples/stats-Ex.Rout.save M /trunk/tests/reg-tests-2.Rout.save summary.default() no longer rounds by default; just *prints* rounded I do expect quite a few packages giving slightly changed output, typically uniformly not-worse one, but just "typically". Note that I did also have to patch stats:::print.summary.ecdf() because that had relied on the fact that summary() did round itself already. Other useR's code may need similar changes... and so this *is* a user visible change, listed accordingly in NEWS (the above doc/NEWS.Rd in the sources). I hope very much that the overall and longer term benefit will vastly outweigh the nuisance (to people publishing, e.g.) that quite a few "basic" outputs will slightly change. The benefit for maintainers and old timers like me will be that we will not need to answer this (non-official) FAQ nor excuse a peculiar behavior in the future . But yes, I expect a flurry of questions starting in April 2017, and hope that the smart readers of this list will share the load answering them .. ;-) Martin Maechler ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sort.int(c(2, NA, 4), index.return=TRUE, na.last=NA, method)$ix differ for method="radix" and "shell"/"quick" (+ new default in R-devel)
Does sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="radix")$ix give the intended result, because I get: > sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="radix") $x [1] 2 4 $ix [1] 1 3 With method="shell" and method="quick" in R devel, I get: > sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="shell") $x [1] 2 4 $ix [1] 1 2 > sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="quick") $x [1] 2 4 $ix [1] 1 2 Is this correct? Should we expect sort.int(c(2,NA,4), index.return=TRUE, na.last=NA)$ix to be the same regardless of 'method'? BACKGROUND: I recently discovered that some of my package tests on functions using sort(x, index.return=TRUE) where double 'x' may contain missing values fails. I traced it down to the update in R-devel (2016-08-2? r70856) where method="radix" became the new default; svn log -r 70856 r70856 | lawrence | 2016-06-29 16:59:30 -0700 (Wed, 29 Jun 2016) | 3 lines radix is default sort algorithm for doubles (no more rounding), grouping() puts NAs last. which I think is why we in R devel now observe: > sort(c(2,NA,4), index.return=TRUE) $x [1] 2 4 $ix [1] 1 3 whereas prior to this we saw: > sort(c(2,NA,4), index.return=TRUE) $x [1] 2 4 $ix [1] 1 2 /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sort.int(c(2, NA, 4), index.return=TRUE, na.last=NA, method)$ix differ for method="radix" and "shell"/"quick" (+ new default in R-devel)
The radix sort should be consistent with the others, i.e., it should behave like sort.list(), not order(). I will correct this. On Thu, Aug 25, 2016 at 4:39 PM, Henrik Bengtsson wrote: > Does sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, > method="radix")$ix give the intended result, because I get: > >> sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="radix") > $x > [1] 2 4 > > $ix > [1] 1 3 > > With method="shell" and method="quick" in R devel, I get: > >> sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="shell") > $x > [1] 2 4 > > $ix > [1] 1 2 > >> sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="quick") > $x > [1] 2 4 > > $ix > [1] 1 2 > > Is this correct? Should we expect sort.int(c(2,NA,4), > index.return=TRUE, na.last=NA)$ix to be the same regardless of > 'method'? > > > > BACKGROUND: > > I recently discovered that some of my package tests on functions using > sort(x, index.return=TRUE) where double 'x' may contain missing values > fails. I traced it down to the update in R-devel (2016-08-2? r70856) > where method="radix" became the new default; > > svn log -r 70856 > > r70856 | lawrence | 2016-06-29 16:59:30 -0700 (Wed, 29 Jun 2016) | 3 lines > > radix is default sort algorithm for doubles (no more rounding), > grouping() puts NAs last. > > which I think is why we in R devel now observe: > >> sort(c(2,NA,4), index.return=TRUE) > $x > [1] 2 4 > > $ix > [1] 1 3 > > whereas prior to this we saw: > >> sort(c(2,NA,4), index.return=TRUE) > $x > [1] 2 4 > > $ix > [1] 1 2 > > /Henrik > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
