Re: [Rd] as.Date without "origin"
Dear all, I would throw in my vote to have origin = "1970-01-01" as a default in as.Date(). Why? Well, in fact, the "converse" function as.numeric() does have an implicit default: > as.numeric(Sys.Date()) [1] 19298 In fact, as.numeric seems to not even have a method for class "Date", and so as.numeric() does not even have an argument "origin" or the like. In any case, when using Date objects, it may happen that the result is of clas numeric. For example: > ifelse(TRUE, Sys.Date(), Sys.Date() + 1) [1] 19298 So, in order to transform the result back to class "Date" using as.Date(), I always need to remember the universal default origin 1970-01-01 and I need to write it out explicitly. I find that rather inconvenient, and so having the default origin as a default would make very much sense to me here. Of course, for that particular example, it would also help me if ifelse() would properly handle Date vectors. Best Johannes > Gesendet: Mittwoch, 02. November 2022 um 14:38 Uhr > Von: "Dan Dalthorp via R-devel" > An: "Spencer Graves" > Cc: "r-devel@r-project.org" > Betreff: Re: [Rd] as.Date without "origin" > > I don't see a compelling rationale for changing the default behavior as.Date > to deviate from the wholly reasonable status quo of "as.Date will accept > numeric data (the number of days since an epoch), but only if origin is > supplied." That has been the expectation for a long, long time. > > In any case, the manual should match the behavior. > > -DHD > > > > > --- Original Message --- > On Wednesday, November 2nd, 2022 at 6:20 AM, Spencer Graves > wrote: > > > > > > > > I've felt that "as.Date" should default to origin "1970-01-01", so I > > added a modification to Ecfun: > > > > > > Ecfun::as.Date1970(0) > > > > > > If R-devel chose to change the default on this, I would happily > > deprecate Ecfun::as.Date1970 in favor of base::as.Date ;-) > > > > > > I would therefore support changing the documentation to match the new > > behavior. > > > > > > Spencer Graves > > > > > > On 11/2/22 7:30 AM, Dan Dalthorp via R-devel wrote: > > > > > The new (2022-10-11 r83083 ucrt) as.Date function returns a date rather > > > than an error when called without "origin" specified. > > > > > > # previous versions of R > > > as.Date(0) > > > # Error in as.Date.numeric(0) : 'origin' must be supplied > > > > > > # new: > > > as.Date(0) > > > # [1] "1970-01-01" > > > > > > This is at odds with the help file, which gives: > > > > > > origin > > > > > > aDateobject, or something which can be coerced byas.Date(origin, ...)to > > > such an object. > > > > > > And: > > > as.Datewill accept numeric data (the number of days since an epoch), > > > butonlyiforiginis supplied. > > > > > > The behavior described in the help file and implemented in previous > > > versions seems more reasonable than returning a date with an arbitrary > > > "origin". In any case, in the r-devel there is a mismatch between the > > > function and its description. > > > > > > -Dan > > > [[alternative HTML version deleted]] > > > > > > __ > > > 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 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 weirdness
Good morning, I would argue that in this specific simple example, R does the less confusing thing from a user's perspective (maybe not from a programmer's or philosopher's perspective): When using a function from a package that has not been loaded before and when this package creates an object of a "new" class that has not been seen before, R makes sure that its object system from now on recognizes this class. Cheers Johannes > Gesendet: Freitag, 25. Juni 2021 um 08:32 Uhr > Von: "Gabriel Becker" > An: "Gabor Grothendieck" > Cc: "Simon Urbanek" , "r-devel@r-project.org" > > Betreff: Re: [Rd] S3 weirdness > > On Thu, Jun 24, 2021 at 4:48 PM Gabor Grothendieck > wrote: > > > The fact that zoo:: in one part of the code has a side effect in > > another seems not to be in the spirit of functional programming or > > modularity. > > > > While this is true, there is no way I know of for a package function > to...well, function in the general case without its namespace loaded, and > as has been brought up many times on this list, unloading namespaces fully > also doesn't work in the fully general case. Given those facts, it seems > the current behavior is essentially all that is possible to be done, right? > > Also even if a namespace could be unloaded, can you imagine the penalty if > the namespace was loaded and then unloaded after every :: call? Some > scripts would just never complete at all. I kid, of course, but not by that > much I think... > > ~G > > > > > > On Thu, Jun 24, 2021 at 6:51 PM Simon Urbanek > > wrote: > > > > > > Gabor, > > > > > > just by using zoo::read.zoo() you *do* load the namespace: > > > > > > > args(zoo::read.zoo) > > > function (file, format = "", tz = "", FUN = NULL, regular = FALSE, > > > index.column = 1, drop = TRUE, FUN2 = NULL, split = NULL, > > > aggregate = FALSE, ..., text, read = read.table) > > > NULL > > > > sessionInfo() > > > R Under development (unstable) (2021-06-23 r80548) > > > Platform: x86_64-apple-darwin19.6.0 (64-bit) > > > Running under: macOS Catalina 10.15.7 > > > > > > Matrix products: default > > > BLAS: /Volumes/Builds/R/build/lib/libRblas.dylib > > > LAPACK: /Volumes/Builds/R/build/lib/libRlapack.dylib > > > > > > locale: > > > [1] en_NZ.UTF-8/en_NZ.UTF-8/en_NZ.UTF-8/C/en_NZ.UTF-8/en_NZ.UTF-8 > > > > > > attached base packages: > > > [1] stats graphics grDevices utils datasets methods base > > > > > > loaded via a namespace (and not attached): > > > [1] zoo_1.8-9 compiler_4.2.0 grid_4.2.0 lattice_0.20-44 > > > > > > which includes S3 method dispatch tables: > > > > > > > methods(as.ts) > > > [1] as.ts.default* as.ts.zoo* as.ts.zooreg* > > > see '?methods' for accessing help and source code > > > > > > so the behavior is as expected. > > > > > > Cheers, > > > Simon > > > > > > > > > > On 25/06/2021, at 9:56 AM, Gabor Grothendieck > > wrote: > > > > > > > > If we start up a vanilla session of R with no packages loaded and > > > > type the single line of code below as the first line entered then > > > > we get the output shown below. The NA in the output and the length > > > > of 7 indicate that as.ts dispatched as.ts.zoo since as.ts.default > > > > would have resulted in a length of 6 with no NA's. It should not have > > > > known about as.ts.zoo since we never explicitly loaded the zoo > > > > package using library or require. > > > > zoo:: was only used to refer to read.zoo. This seems to be a bug in > > > > the way R is currently working. > > > > > > > > as.ts(zoo::read.zoo(BOD)) > > > > ## Time Series: > > > > ## Start = 1 > > > > ## End = 7 > > > > ## Frequency = 1 > > > > ## [1] 8.3 10.3 19.0 16.0 15.6 NA 19.8 > > > > > > > > R.version.string > > > > ## [1] "R version 4.1.0 RC (2021-05-16 r80303)" > > > > > > > > -- > > > > Statistics & Software Consulting > > > > GKX Group, GKX Associates Inc. > > > > tel: 1-877-GKX-GROUP > > > > email: ggrothendieck at gmail.com > > > > > > > > __ > > > > R-devel@r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > > > -- > > Statistics & Software Consulting > > GKX Group, GKX Associates Inc. > > tel: 1-877-GKX-GROUP > > email: ggrothendieck at gmail.com > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > __ > 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] `basename` and `dirname` change the encoding to "UTF-8"
Hello, everyone, thank you for your quick and helpful responses and the detailed information. Sorry for not providing a reproducible example for the (potential) bug in `tools::makeLazyLoadDB`. The main point of my mail was the surprising behaviour of `basename` and `dirname`. Fixing those functions would probably solve my problem for me (as a workaround, probably hiding some underlying problem, and likely leading to a failure for someone else fighting with encodings). Concerning my underlying direct problem with `tools::makeLazyLoadDB`, I'm having difficulty to make my example reproducible. I'm trying to use a directory with a non-ASCII-name for a knitr cache. My R-4.0.0 here behaves different from my R-3.6.3, but when I filed a bug report with knitr, Yihui could not reproduce this difference (https://github.com/yihui/knitr/issues/1840). So I'll try R-4.0.2 next, let's see what happens. Cheers Johannes > Gesendet: Dienstag, 30. Juni 2020 um 09:25 Uhr > Von: "Tomas Kalibera" > An: "Johannes Rauh" , "r-devel" > Betreff: Re: [Rd] `basename` and `dirname` change the encoding to "UTF-8" > > On 6/29/20 4:39 PM, Johannes Rauh wrote: > > Dear R Developers, > > > > I noticed that `basename` and `dirname` always return "UTF-8" on Windows > > (tested with R-4.0.0 and R-3.6.3): > > > >> p <- "Föö/Bär" > >> Encoding(p) > > [1] "latin1" > >> Encoding(dirname(p)) > > [1] "UTF-8" > >> Encoding(basename(p)) > > [1] "UTF-8" > > > > Is this on purpose? At least I did not find any relevant comment in the > > documentation of `dirname`/`basename`. > > Background: I'm currently struggeling with a directory name containing a > > latin1-character. (I know that this is a bad idea, but I did not create > > the directory and I cannot rename it.) I now want to pass a > > latin1-directory name to a function, which internally uses > > `tools::makeLazyLoadDB`. At that point, internally, `dirname` is called, > > which changes the encoding, and things break. If I use `debug` to halt the > > processing and "fix" the encoding, things work as expected. > > > > So, if possible, I would prefer that `dirname` and `basename` preserve the > > encoding. > > Please try to always submit a minimal reproducible example with your > reports and test with at least the latest released version of R, ideally > also with R-devel. > > As you have not sent a reproducible example, it is hard to tell for > sure, but most likely as Kevin wrote you have run into a real bug, which > was however already fixed in 4.0.2 and in R-devel (17833). The lazy > loading cache did not work with file names in non-native encoding. > > That real bug has been uncovered by legitimate and correct changes like > the ones you report, where file operations started returning non-ASCII > strings in UTF-8. Historically in R such functions would instead return > native strings with misrepresented characters, and we were reluctant to > change that expecting waking bugs in code silently assuming native > encoding. Still, as people were increasingly running into problems with > non-representable characters, we did that change in several functions > anyway, and yes, it started waking up bugs. > > With some performance overhead and added complexity, we could be > returning preferentially results in native encoding, and in UTF-8 only > when they included non-representable characters. That would increase the > code complexity, increase performance overhead, but wake up existing > bugs with smaller probability. Note - some code that relied previously > on best-fit conversions done by Windows will have been broken anyway. We > would have to bypass win_iconv/iconv for that (adding more complexity). > Bugs in code not handling encodings properly would still be triggered > via non-representable characters. I've recently changed file.path() in > R-devel to be slightly more conservative again, along these lines. > > We can still do it more widely, but it is not high on the priority list. > The way to fix all of these problems is switching to UTF-8 as native > encoding on Windows and every day spent on tuning the existing behavior > postpones that real solution. > > Best > Tomas > > > > > > Best regards > > Johannes > > > > __ > > 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
[Rd] `basename` and `dirname` change the encoding to "UTF-8"
Dear R Developers, I noticed that `basename` and `dirname` always return "UTF-8" on Windows (tested with R-4.0.0 and R-3.6.3): > p <- "Föö/Bär" > Encoding(p) [1] "latin1" > Encoding(dirname(p)) [1] "UTF-8" > Encoding(basename(p)) [1] "UTF-8" Is this on purpose? At least I did not find any relevant comment in the documentation of `dirname`/`basename`. Background: I'm currently struggeling with a directory name containing a latin1-character. (I know that this is a bad idea, but I did not create the directory and I cannot rename it.) I now want to pass a latin1-directory name to a function, which internally uses `tools::makeLazyLoadDB`. At that point, internally, `dirname` is called, which changes the encoding, and things break. If I use `debug` to halt the processing and "fix" the encoding, things work as expected. So, if possible, I would prefer that `dirname` and `basename` preserve the encoding. Best regards Johannes __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] In base R: argument `list` does not accept lists
The function `base::rm` has an argument that is named `list`. However, if a
list is passed as `list` to `rm` (e.g.: `rm(list = list("x", "y"))`), an error
is raised: "invalid first argument".
Agreed, the documentation says that `list` should be "a character vector naming
objects to be removed." Still, wouldn't it make sense to allow a list of
characters as an argument?
The other alternative to make things consistent would be to rename the
argument, but that would break compatibility, of course.
Best
Johannes
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] system2 fails with quiet=TRUE, but runs through with quiet=FALSE
Hi,
I have recently tried to check the test coverage using library("covr") and,
interestingly, the command
> covr::package_coverage()
fails, while
> covr::package_coverage(quiet = FALSE)
runs through without problem. I traced the problem to a call to
utils::install.packages(), where the option quiet is passed on. In
utils::install.packages(), the problem seems to lie in the following call of
system2():
output <- if (quiet)
FALSE else ""
[...]
status <- system2(cmd0, args, env = env, stdout = output,
stderr = output)
Manually changing stdout to "" makes the program run through without error (but
then the output is there again, of course...).
The function system2 seems to be a wrapper around
.Internal(system(command, flags, f, stdout, stderr))
In this call, if quiet = TRUE, then flags <- 21, otherwise flags <- 22. stdout
and stderr are passed through from system2.
I should mention that I am working with R 3.3.1 on Windows 8.
Does anyone have an idea what the flags mean and how they can make a system
call fail?
Best
Johannes
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
