Re: [Rd] summary.default rounding on numeric seems inconsistent with other R behaviors

[Martin Maechler]

> Martin Maechler 
> on Tue, 23 Aug 2016 14:33:58 +0200 writes:

> Dirk Eddelbuettel 
> on Fri, 19 Aug 2016 11:40:05 -0500 writes:

>> It is the old story of defined behaviour and expected outcomes. Hard to
>> change now.

> yes...  not impossible though... see below

>> So I would suggest you do something like this in your ~/.Rprofile:

R> smry <- function(...) summary(..., digits=6)
R> smry(15L)
>> Min. 1st Qu.  MedianMean 3rd Qu.Max.
>> 15  15  15  15  15  15
R> 

>> Maybe call it Summary() instead.

> yes, do use a different name.   There other such functions, 'summarize()'.

> Simone wrote

>> I had raised the matter ten years ago, and I was told that the topic was
>> already very^3 old
>> 
>> https://stat.ethz.ch/pipermail/r-devel/2006-September/042684.html
>> 
>> there is some discussion on its origin and also a declaration of intents 
to
>> change the default behaviour, which, unfortunately, remained a 
declaration.
>> I agree that R could do better here, let's hope in less than ten years
>> though. ;-)

> and the 2006 thread he mentions is basically a similar question
> and a reply by me that I agreed to some extent that a change was
> desirable ... originally we had adhered to the S "standard"
> which became the S+ one and at that time I did still have access
> to a running instance of S-PLUS 6.2 where I had seen that
> Insightful (the company selling curating and selling S-PLUS)
> also had decided to change the ~15 year old S "standard"... and
> indeed I was implicitly *asking* for proposals of such a change,
> but I think I never saw a (careful) proposal.

> In the spirit of probably 99% of other "base R" code, a change
> should really *not* round __at all__ in the summary() methods,
> but *only* in the print() methods of such summary() results.

> OTOH, for back compatibility, if a user does use  summary(.., digits=.)
> explicitly, these digits should be 'obeyed' of course.

> I think summary(<1-variable>)  could easily, and relatively 
"back-compatibly"
> be changed in the above vain.

> One "real problem" is the wrong decision (also from S and S-PLUS
> times IIRC) to return a "character" matrix for
> summary(, ..)
> or summary(, ..)
> (For a data frame, I think it should return a list() of
> single-variable summary()es, or then a numeric matrix .. in
> both cases have a good print() method)

> because when you return a character matrix, all the numbers are
> already rounded, ... and if we follow the above approach they 
> would have to be rounded further... ``the horror''

> I wonder how much code out there is relying on the internal
> structure of  summary().. because that is the one
> part I'd definitely want to change, too.

[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

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

[Rd] feature request for non-sweave vignettes

[Patrick Brown]

Currently Makefiles for vignettes are only supported for .tex files.  Could
the tools package be modified to allow file extensions to be specified for
a vignette engine?  Having the pandoc pdf conversion in a Makefile rather
than through R would be tidier in some cases.

If I specify my vignette engine as

```
tools::vignetteEngine(
  'myengine',
  pattern = '\\.[Rr](md|nw)$',
  output = c('md', 'tex'),
  ...
)
```

the `tools:::find_vignette_product` function could have

`if (final) c("pdf", "html") else unique(c("pdf", "html", "tex",
engine$output))`

that's probably the only line that would need changing.

p

Patrick Brown
Department of Statistical Sciences, University of Toronto
Analytics and Informatics, Cancer Care Ontario
pbrown.ca

[[alternative HTML version deleted]]

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

---
John Mount
http://www.win-vector.com/  
Our book: Practical Data Science with R http://www.manning.com/zumel/ 





[[alternative HTML version deleted]]

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

Re: [Rd] feature request for non-sweave vignettes

[Duncan Murdoch]

On 24/08/2016 8:09 AM, Patrick Brown wrote:

Currently Makefiles for vignettes are only supported for .tex files.  Could
the tools package be modified to allow file extensions to be specified for
a vignette engine?  Having the pandoc pdf conversion in a Makefile rather
than through R would be tidier in some cases.

If I specify my vignette engine as

```
tools::vignetteEngine(
  'myengine',
  pattern = '\\.[Rr](md|nw)$',
  output = c('md', 'tex'),
  ...
)
```

the `tools:::find_vignette_product` function could have

`if (final) c("pdf", "html") else unique(c("pdf", "html", "tex",
engine$output))`

that's probably the only line that would need changing.


Sounds reasonable.  Try it out in R-devel, and submit a patch.

Note that there is at least one other request for vignette improvements, 
i.e.
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16333, with a 
promise to submit a patch.  It hasn't arrived in 16 months.  So please 
don't promise a patch unless you intend to deliver.


Duncan Murdoch

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

[Rd] "plot.ts" doesn't respect the value of "pch" (+ blocked from Bugzilla signups)

[Gregory Werbin]

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


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