On Wed, Jun 23, 2010 at 7:13 AM, Peter Dalgaard <pda...@gmail.com> wrote: > Gustaf Rydevik wrote: > >> Oh, I forgot to mention that the workaround of using as.double (or >> as.numeric) works fine, and I've done that. >> It's just that it can take quite a while (as in several hours) to >> figure out that the reason for the error is that you have to force >> difftime objects to be numeric in 2.11.1, when the code's been working >> fine before and the error messages are obscure. > > I don't think you realize the problems that could occur by assuming that > difftime objects are numerics ON ANY PARTICULAR SCALE! > > -- > Peter Dalgaard > Center for Statistics, Copenhagen Business School > Phone: (+45)38153501 > Email: pd....@cbs.dk Priv: pda...@gmail.com >
Ah. Yes, you're right that it would be problematic to say the least to assume that the difftime object is measured in days and not in, say, seconds. And I suppose that it makes sense to prioritize avoiding calculations that give misleading results over forcing changes in old code. I was just caught somewhat unprepared, and I know that my colleagues who is not quite as R-literate will be even more unprepared for old stuff no longer working. Usually, R prepares the user for these kind of things by throwing warnings a version or two before the change is actually implemented. But I guess that's not always practical. I take it that your argument would also work agains implementing simple difftime-methods of functions as well, where you force difftime objectws to be numeric? In that case, people can disregard my suggestion of adding a difftime-method to cut(). Anyhow, I'll stop whining now. Thanks for the good work you're doing in the R Core team. Regards, Gustaf -- Gustaf Rydevik, M.Sci. tel: +46(0)703 051 451 address:Essingetorget 40,112 66 Stockholm, SE skype:gustaf_rydevik ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
