Re: [Rd] strptime(): on Linux system it seems to call system time?
On Sat, 20-Mar-2010 at 06:54PM +0100, Peter Dalgaard wrote:
[...]
|> It seems to be completely system-dependent. On Fedora 9, I see
|>
|>user system elapsed
|> 2.890 0.314 3.374
|>
|> but on openSUSE 10.3 it is
|>
|>user system elapsed
|> 3.924 6.992 10.917
|>
|> At any rate, I suspect that this is an issue with the operating system
|> and its C libraries, not with R as such.
Were those 32 or 64 bit?
With Fedora 11 and AMD Athlon 2 Ghz, I get
user system elapsed
1.395 0.294 1.885
with Mepis 7 on a Celeron 1.6 Ghz,
user system elapsed
3.890 5.896 9.845
Both of those are 32 bit.
Maybe 64 bit does things very differently.
--
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
___Patrick Connolly
{~._.~} Great minds discuss ideas
_( Y )_ Average minds discuss events
(:_~*~_:) Small minds discuss people
(_)-(_) . Eleanor Roosevelt
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")
Hi John,
John Chambers wrote:
The example is confusing and debatable, but not an obvious bug. And
your presentation of it is the cause of much of the confusion
(unintentionally I'm sure).
First, slipping from the as() function to methods for the coerce()
function might surprise a less experienced user. And in fact, that is
the point here. If you look at the as() function, it jumps through
several hoops and in particular selects a method from coerce in such a
way as NOT to use inheritance on the from= argument. (I think this
makes sense in this case). So I would assert that your selectMethod()
output below came from a different session than the as(1:4, "numeric").
Starting from a clean session with R 2.10.1:
> class(as(1:4,"numeric"))
[1] "integer"
> selectMethod("coerce", c("integer","numeric"))
Method Definition:
function (from, to = "numeric", strict = TRUE)
if (strict) {
class(from) <- "numeric"
from
} else from
Signatures:
from to
target "integer" "numeric"
defined "integer" "numeric"
Note, no call to as.numeric(). In a session without a previous call to
as(), your selectMethod() call triggered a standard inherited method
selection. And if you had then gone on to as(), the result would have
been different.
Yes indeed. From a fresh start:
> invisible(selectMethod("coerce", c("integer","numeric")))
> class(as(1:4, "numeric"))
[1] "numeric"
But without the initial call to selectMethod(), as(1:4, "numeric")
returns an integer vector.
Sorry but it's hard for me to understand the reasons for having
such behaviour, especially when selectMethod() is described as a
function "to *look* for a method corresponding to a given generic
function and signature". Apparently it does more than just looking...
In a different clean session:
> getMethod("coerce", c("integer", "numeric"))
Error in getMethod("coerce", c("integer", "numeric")) :
No method found for function "coerce" and signature integer, numeric
> selectMethod("coerce", c("integer", "numeric"))
Method Definition:
function (from, to, strict = TRUE)
{
value <- as.numeric(from)
if (strict)
attributes(value) <- NULL
value
}
Signatures:
from to
target "integer" "numeric"
defined "ANY" "numeric"
> class(as(1:4,"numeric"))
[1] "numeric"
No argument about this being confusing. Perhaps one should prohibit
standard selectMethod() on coerce() but that seems a bit arcane to
thwart folks like you!
Suggested improvements for the current implementation are welcome, so
long as they consider the best definition of as() in the general sense.
So one problem seems to be that, on a fresh start, *both*
as(1:4, "numeric")
and
selectMethod("coerce", c("integer", "numeric"))
will cache a coerce method for the c("integer", "numeric") signature,
but they don't cache the *same* method!
The automatic method cached by 'as(1:4, "numeric")' seems to be
coming from:
getClassDef("integer")@contains$nume...@coerce
Maybe one way to improve things would be to modify this part of
the class definition for "integer" so it is in sync with
selectMethod("coerce", c("integer", "numeric")).
There are other situations where the coerce methods are not
in sync:
> getClassDef("factor")@contains$inte...@coerce
function (from, strict = TRUE)
{
attributes(from) <- NULL
from
}
> selectMethod("coerce", c("factor", "integer"))
Method Definition:
function (from, to, strict = TRUE)
{
value <- as.integer(from)
if (strict)
attributes(value) <- NULL
value
}
That isn't a problem here because both methods will produce
the same result but is there any reason why the former
couldn't use the same code as the latter?
A more radical approach would be to have a call to
selectMethod("coerce", c("integer", "numeric"))
have the same effect on the table of coerce methods than a
call to
as(1:4, "numeric")
i.e. the former will insert the same automatic method as the
latter. That means that all the hard work made by the as()
function in order to find/create/cache an appropriate method
would need to be moved to selectMethod() so in that function
'f="coerce"' would become a special case.
Then as() would become a 10 line function (or less) that would
basically delegate to selectMethod("coerce", ...) to do the hard
work. This solution seems better to me as it would then guarantee
consistency between what as() does and what
selectMethod("coerce", ...) says.
Cheers,
H.
Regards,
John
On 3/31/10 3:52 PM, Hervé Pagès wrote:
Hi,
> class(as(1:4, "numeric"))
[1] "integer"
Surprising but an explanation could be that an integer
vector being a particular case of numeric vector, this
coercion has nothing to do because 1:4 is already numeric.
And indeed:
> is.numeric(1:4)
[1] TRUE
> is.numeric(as(1:4, "numeric"))
[1] TRUE
However, 'as(1:4, "numeric")' is inconsistent with
> class(as.numeric(1:4))
[1] "numeric"
And, even more confusi
Re: [Rd] strptime(): on Linux system it seems to call system time?
Let me lay this to rest. For some reason the OP did not use a
vectorized call to strptime but 10 individual calls (as well as
making *false* claims about what strptime does and what is 'completely
unnecessary', and seemingly being igorant of system.time()).
I do not believe this is ever an issue for well-written R code.
Each time strptime() is called it needs to find and set the timezone
(as whether an input is valid or not and whether it is in DST depends
on the timezone). If tz = "", the default, it needs to ask the system
what the current timezone is via the C call tzset. On well-written C
runtimes tzset caches and so is fast after the first time. On some
others it reads files such as /etc/localtime each time.
On my Linux system (x86_64 Fedora 12)
system.time(for (i in 1:10) strptime("2010-03-10 17:00:00", "%F %H:%M:%S"))
user system elapsed
1.048 0.222 2.086
system.time(strptime(rep("2010-03-10 17:00:00", 10), "%F %H:%M:%S"))
user system elapsed
0.371 0.184 0.579
whereas on my 2008 Mac laptop
user system elapsed
7.402 0.015 7.441
user system elapsed
6.689 0.013 6.716
and on my 2005 Windows laptop
user system elapsed
2.470.002.47
user system elapsed
1.390.001.40
(for which the credit is entirely due to the replacement code in R:
Windows' datetime code is only used for strftime).
So looks like Apple could improve their POSIX datetime runtime, but
I've never seen an R application where parsing dates took longer than
reading the original posting (let alone the time taken to read some
good books on how to time R code and write it efficiently).
On Thu, 1 Apr 2010, Patrick Connolly wrote:
On Sat, 20-Mar-2010 at 06:54PM +0100, Peter Dalgaard wrote:
[...]
|> It seems to be completely system-dependent. On Fedora 9, I see
|>
|>user system elapsed
|> 2.890 0.314 3.374
|>
|> but on openSUSE 10.3 it is
|>
|>user system elapsed
|> 3.924 6.992 10.917
|>
|> At any rate, I suspect that this is an issue with the operating system
|> and its C libraries, not with R as such.
Were those 32 or 64 bit?
With Fedora 11 and AMD Athlon 2 Ghz, I get
user system elapsed
1.395 0.294 1.885
with Mepis 7 on a Celeron 1.6 Ghz,
user system elapsed
3.890 5.896 9.845
Both of those are 32 bit.
Maybe 64 bit does things very differently.
--
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
___Patrick Connolly
{~._.~} Great minds discuss ideas
_( Y )_ Average minds discuss events
(:_~*~_:) Small minds discuss people
(_)-(_) . Eleanor Roosevelt
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Is it valid to do x == Inf?
Hi, I found in a bit of code the following test for infinity: if (x == Inf) ... Is that valid, or should it be (as I always thought): if (is.infinite(x)) ...? Does it depend on whether 'x' is float or integer? My question is related to testing for missing values where is.na(x) is required. /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is it valid to do x == Inf?
On Thu, Apr 1, 2010 at 11:03 AM, Henrik Bengtsson wrote: > Hi, > > I found in a bit of code the following test for infinity: > > if (x == Inf) ... > > Is that valid, or should it be (as I always thought): > > if (is.infinite(x)) ...? > > Does it depend on whether 'x' is float or integer? > > My question is related to testing for missing values where is.na(x) is > required. Well, '-Inf' is infinite too: > is.infinite(-Inf) [1] TRUE but is not equal to Inf: > Inf == -Inf [1] FALSE Also, ?is.infinite says it is a generic method, so is.infinite(x) could be doing anything, depending on x. I would say the best way of testing if x is a numeric value of plus infinity would be to test x==Inf. Also also, is.infinite (on a numeric vector) returns FALSE on NA, and NaN, whereas x==Inf returns NA values for non nice-number inputs. Barry -- blog: http://geospaced.blogspot.com/ web: http://www.maths.lancs.ac.uk/~rowlings web: http://www.rowlingson.com/ twitter: http://twitter.com/geospacedman pics: http://www.flickr.com/photos/spacedman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Make a donation via PayPal? (was: [R] Monetary support to the R-project)
Dear R developers I understand that this is not a proper r-devel message, but it still touches to the organisation of the R project. I would like to make a small donation to the project, but I am not comfortable with sending my credit card details via post or mail and, as echoed elsewhere on r-help, would prefer to go through a generally accepted service such as PayPal. Would there be any interest from the R project to implement this? Thank you Liviu On 3/8/10, Henrik Bengtsson wrote: > For companies and others wondering how to "give something back", it is > possible to support R and the R Foundation either through a donation: > > http://www.r-project.org/ -> Foundation -> Donations > [http://www.r-project.org/foundation/donations.html] > > or via a membership: > > http://www.r-project.org/ -> Foundation -> Membership > [http://www.r-project.org/foundation/membership.html] > > or both. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Make a donation via PayPal? (was: [R] Monetary support to the R-project)
You need to ask the Treasurer of the R Foundation, who is Kurt Hornik (and who is on vacation). On Thu, 1 Apr 2010, Liviu Andronic wrote: Dear R developers I understand that this is not a proper r-devel message, but it still touches to the organisation of the R project. More the R Foundation, a legally separate entity. I would like to make a small donation to the project, but I am not comfortable with sending my credit card details via post or mail and, as echoed elsewhere on r-help, would prefer to go through a generally accepted service such as PayPal. Depends on your country as to whether it is accepted at all, let alone 'generally accepted'. I've never seen an EU foundation which accepted it and there used at least to be legalities as to why. Would there be any interest from the R project to implement this? Thank you Liviu On 3/8/10, Henrik Bengtsson wrote: For companies and others wondering how to "give something back", it is possible to support R and the R Foundation either through a donation: http://www.r-project.org/ -> Foundation -> Donations [http://www.r-project.org/foundation/donations.html] or via a membership: http://www.r-project.org/ -> Foundation -> Membership [http://www.r-project.org/foundation/membership.html] or both. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RSS feeds now link to bug reports
Sometime last year Hadley Wickham suggested that the R daily news feed (http://developer.r-project.org/RSSfeeds.html) should link to bug reports. Now that Simon has moved the bug reporting system to Bugzilla, this is finally possible, and I've just rebuilt the news items with those links in place. For example, see the item under 2.11.0 BUG FIXES in http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2010/04/01#n2010-04-01 Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Difference Linux / Windows
On Mar 31, 2010, at 18:38 , Seth Falcon wrote: On 3/31/10 1:12 PM, Christophe Genolini wrote: Hi the list, I am writing a package that happen to not be compatible with linux because I did not know that the function "savePlot" was available only on windows. Is there a list of "incompatible" function? How can I get this kind of information? One way is to obtain a copy of the R sources and then grep the Rd files for '#ifdef'. I don't claim this is convenient. nor sufficient - lot of it is simply in the windows directory (such as savePlot). The safest approach right now is simply to read the documentation - savePlot does tell you that it works only for the Windows device. I'm not aware of an automated list (save for dumping the function lists per-package on each platform). Cheers, Simon There has been discussion, and I believe general consensus, that we'd like to eliminate the conditional documentation. This requires editing the Rd files to make the contents sensible (you can't just remove the #ifdef's). Patches along these lines would be welcome. + seth -- Seth Falcon | @sfalcon | http://userprimary.net/ __ 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] Difference Linux / Windows
Since this seems more like a wish-list discussion, if someone actually starts thinking about the issue I would like to add the following somewhat related point: It would be nice if there were a mechanism, in task views or that could be used by task views, to avoid attempting to install packages that will fail on the platform. The current ctv mechanism is difficult for system administrators because they actually have to know enough about R packages to decide which failures are ok and which ones are not. Paul >-Original Message- >From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r- >project.org] On Behalf Of Simon Urbanek >Sent: April 1, 2010 11:38 AM >To: Seth Falcon >Cc: r-devel@r-project.org >Subject: Re: [Rd] Difference Linux / Windows > > >On Mar 31, 2010, at 18:38 , Seth Falcon wrote: > >> On 3/31/10 1:12 PM, Christophe Genolini wrote: >>> Hi the list, >>> I am writing a package that happen to not be compatible with linux >>> because I did not know that the function "savePlot" was available >>> only >>> on windows. Is there a list of "incompatible" function? How can I get >>> this kind of information? >> >> One way is to obtain a copy of the R sources and then grep the Rd >> files for '#ifdef'. >> >> I don't claim this is convenient. >> > >nor sufficient - lot of it is simply in the windows directory (such as >savePlot). >The safest approach right now is simply to read the documentation - >savePlot does tell you that it works only for the Windows device. I'm >not aware of an automated list (save for dumping the function lists >per-package on each platform). > >Cheers, >Simon > > >> There has been discussion, and I believe general consensus, that >> we'd like to eliminate the conditional documentation. This requires >> editing the Rd files to make the contents sensible (you can't just >> remove the #ifdef's). Patches along these lines would be welcome. >> >> + seth >> >> -- >> Seth Falcon | @sfalcon | http://userprimary.net/ >> >> __ >> 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 La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")
On 3/31/10 4:52 PM, John Chambers wrote:
The example is confusing and debatable, but not an obvious bug. And
your presentation of it is the cause of much of the confusion
(unintentionally I'm sure).
To restate the issue (I think):
In a new R session if you happen to call:
selectMethod("coerce", c("integer", "numeric"))
*Before* having made a call like as(1:4, "numeric") then there is a
side-effect of creating definition "A" of the integer => numeric coerce
method. From this point forward all calls to as(x, "numeric") when x is
"integer" will return as.numeric(x).
If instead you do not call selectMethod, then when calling as(x,
"numeric") for x "integer" you get definition "B", the documented
behavior, which simply returns x.
Presumably there are other similar cases where this will be an issue.
So while I agree this could be considered obscure, this qualifies as a
bug in my book. It seems desirable that selectMethod not change the
state of the system in a user-visible fashion. And calling
selectMethod, or any other function, should not alter dispatch unless
documented to do so.
I'm also suspicious of the behavior of the strict argument:
> class(as(1:4, "numeric"))
[1] "integer"
> class(as(1:4, "numeric", strict = TRUE))
[1] "integer"
> class(as(1:4, "numeric", strict = FALSE))
[1] "integer"
Is that intended?
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is it valid to do x == Inf?
On Thu, 1 Apr 2010, Henrik Bengtsson wrote: Hi, I found in a bit of code the following test for infinity: if (x == Inf) ... Is that valid Yes, if you don't want to also include -Inf , or should it be (as I always thought): if (is.infinite(x)) ...? If you don't want to distinguish Inf and -Inf Does it depend on whether 'x' is float or integer? There isn't an integer infinity. Integer values larger than the maximum reprensentable give NA eg > .Machine$integer.max+1L [1] NA My question is related to testing for missing values where is.na(x) is required. NA is different, because NA by its nature can't compare equal to anything: x==NA asks: "Is x equal to some number I don't know?", to which the answer is "Don't know". x==Inf asks "Is x positive infinite?", which is a perfectly well-defined question. -thomas Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Difference Linux / Windows
On Apr 1, 2010, at 11:59 , Paul Gilbert wrote: Since this seems more like a wish-list discussion, if someone actually starts thinking about the issue I would like to add the following somewhat related point: It would be nice if there were a mechanism, in task views or that could be used by task views, to avoid attempting to install packages that will fail on the platform. The current ctv mechanism is difficult for system administrators because they actually have to know enough about R packages to decide which failures are ok and which ones are not. Well, that is an entirely different issue and it is easy since we already have the mechanism in place: OS_type. Cheers, Simon -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r- project.org] On Behalf Of Simon Urbanek Sent: April 1, 2010 11:38 AM To: Seth Falcon Cc: r-devel@r-project.org Subject: Re: [Rd] Difference Linux / Windows On Mar 31, 2010, at 18:38 , Seth Falcon wrote: On 3/31/10 1:12 PM, Christophe Genolini wrote: Hi the list, I am writing a package that happen to not be compatible with linux because I did not know that the function "savePlot" was available only on windows. Is there a list of "incompatible" function? How can I get this kind of information? One way is to obtain a copy of the R sources and then grep the Rd files for '#ifdef'. I don't claim this is convenient. nor sufficient - lot of it is simply in the windows directory (such as savePlot). The safest approach right now is simply to read the documentation - savePlot does tell you that it works only for the Windows device. I'm not aware of an automated list (save for dumping the function lists per-package on each platform). Cheers, Simon There has been discussion, and I believe general consensus, that we'd like to eliminate the conditional documentation. This requires editing the Rd files to make the contents sensible (you can't just remove the #ifdef's). Patches along these lines would be welcome. + seth -- Seth Falcon | @sfalcon | http://userprimary.net/ __ 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 = = = = = = = = = = = = = = == La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. __ 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] Minor typo in ?.Primitive
The help page for .Primitive has this line: ## start quote This function is almost never used: get(name, envir=basenv()) works equally well and ## end quote basenv() should be baseenv(). Checked for r51392 and r51520. -Peter Ehlers __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")
The point I was making was that as() is not just a synonym for selecting
a method from coerce() by the usual inheritance rules. I don't believe
it should be, and the documentation emphasizes that inheritance is not
used in the ordinary way.
If one were to start rewriting code (which I'm not suggesting) my
preference would be to have coerce() not be a generic function,
eliminating the offending selectMethod() calls.
John
On 4/1/10 12:31 AM, Hervé Pagès wrote:
Hi John,
John Chambers wrote:
The example is confusing and debatable, but not an obvious bug. And
your presentation of it is the cause of much of the confusion
(unintentionally I'm sure).
First, slipping from the as() function to methods for the coerce()
function might surprise a less experienced user. And in fact, that
is the point here. If you look at the as() function, it jumps
through several hoops and in particular selects a method from coerce
in such a way as NOT to use inheritance on the from= argument. (I
think this makes sense in this case). So I would assert that your
selectMethod() output below came from a different session than the
as(1:4, "numeric").
Starting from a clean session with R 2.10.1:
> class(as(1:4,"numeric"))
[1] "integer"
> selectMethod("coerce", c("integer","numeric"))
Method Definition:
function (from, to = "numeric", strict = TRUE)
if (strict) {
class(from) <- "numeric"
from
} else from
Signatures:
from to
target "integer" "numeric"
defined "integer" "numeric"
Note, no call to as.numeric(). In a session without a previous call
to as(), your selectMethod() call triggered a standard inherited
method selection. And if you had then gone on to as(), the result
would have been different.
Yes indeed. From a fresh start:
> invisible(selectMethod("coerce", c("integer","numeric")))
> class(as(1:4, "numeric"))
[1] "numeric"
But without the initial call to selectMethod(), as(1:4, "numeric")
returns an integer vector.
Sorry but it's hard for me to understand the reasons for having
such behaviour, especially when selectMethod() is described as a
function "to *look* for a method corresponding to a given generic
function and signature". Apparently it does more than just looking...
In a different clean session:
> getMethod("coerce", c("integer", "numeric"))
Error in getMethod("coerce", c("integer", "numeric")) :
No method found for function "coerce" and signature integer, numeric
> selectMethod("coerce", c("integer", "numeric"))
Method Definition:
function (from, to, strict = TRUE)
{
value <- as.numeric(from)
if (strict)
attributes(value) <- NULL
value
}
Signatures:
from to
target "integer" "numeric"
defined "ANY" "numeric"
> class(as(1:4,"numeric"))
[1] "numeric"
No argument about this being confusing. Perhaps one should prohibit
standard selectMethod() on coerce() but that seems a bit arcane to
thwart folks like you!
Suggested improvements for the current implementation are welcome, so
long as they consider the best definition of as() in the general sense.
So one problem seems to be that, on a fresh start, *both*
as(1:4, "numeric")
and
selectMethod("coerce", c("integer", "numeric"))
will cache a coerce method for the c("integer", "numeric") signature,
but they don't cache the *same* method!
The automatic method cached by 'as(1:4, "numeric")' seems to be
coming from:
getClassDef("integer")@contains$nume...@coerce
Maybe one way to improve things would be to modify this part of
the class definition for "integer" so it is in sync with
selectMethod("coerce", c("integer", "numeric")).
There are other situations where the coerce methods are not
in sync:
> getClassDef("factor")@contains$inte...@coerce
function (from, strict = TRUE)
{
attributes(from) <- NULL
from
}
> selectMethod("coerce", c("factor", "integer"))
Method Definition:
function (from, to, strict = TRUE)
{
value <- as.integer(from)
if (strict)
attributes(value) <- NULL
value
}
That isn't a problem here because both methods will produce
the same result but is there any reason why the former
couldn't use the same code as the latter?
A more radical approach would be to have a call to
selectMethod("coerce", c("integer", "numeric"))
have the same effect on the table of coerce methods than a
call to
as(1:4, "numeric")
i.e. the former will insert the same automatic method as the
latter. That means that all the hard work made by the as()
function in order to find/create/cache an appropriate method
would need to be moved to selectMethod() so in that function
'f="coerce"' would become a special case.
Then as() would become a 10 line function (or less) that would
basically delegate to selectMethod("coerce", ...) to do the hard
work. This solution seems better to me as it would then guarantee
consistency between what as() does and what
selectMethod("coerce", ...) says.
Cheers,
H.
Regards,
John
On 3/31/10 3:52
Re: [Rd] Difference Linux / Windows
On Thu, Apr 1, 2010 at 4:37 PM, Simon Urbanek wrote: > > On Mar 31, 2010, at 18:38 , Seth Falcon wrote: > >> On 3/31/10 1:12 PM, Christophe Genolini wrote: >>> >>> Hi the list, >>> I am writing a package that happen to not be compatible with linux >>> because I did not know that the function "savePlot" was available only >>> on windows. Is there a list of "incompatible" function? How can I get >>> this kind of information? >> >> One way is to obtain a copy of the R sources and then grep the Rd files >> for '#ifdef'. >> >> I don't claim this is convenient. >> > > nor sufficient - lot of it is simply in the windows directory (such as > savePlot). > The safest approach right now is simply to read the documentation - savePlot > does tell you that it works only for the Windows device. I'm not aware of an > automated list (save for dumping the function lists per-package on each > platform). It works only on the "windows()" device on the Windows platform. The savePlot function *is* on the Linux platform (contrary to OP message, modulo whether a mention of 'windows' meant the platform or the device) but only for Cairo x11() devices. Clear? Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")
On 4/1/10 9:45 AM, Seth Falcon wrote: So while I agree this could be considered obscure, this qualifies as a bug in my book. It seems desirable that selectMethod not change the state of the system in a user-visible fashion. And calling selectMethod, or any other function, should not alter dispatch unless documented to do so. As I said in my reply to Hervé, if a change is proposed, I'd prefer it to be to disallow the selectMethod() call by not making coerce() a generic, or at least not one visible outside the namespace. Your general stricture on selectMethod() sounds good, except that the function has the optional argument useInheritance=. Then it will always be possible to have different side effects depending on how selectMethod() is called. I would have no difficulty in principle with making the side-effects ONLY when it's called in the standard way, as happens implicitly from method dispatch. To do that, however, requires making the change suggested in my previous paragraph, otherwise the user can still frustrate the current implementation of as(). I'm also suspicious of the behavior of the strict argument: > class(as(1:4, "numeric")) [1] "integer" > class(as(1:4, "numeric", strict = TRUE)) [1] "integer" > class(as(1:4, "numeric", strict = FALSE)) [1] "integer" Is that intended? In the part of my mail you cut out, you'll see that this has to do with the semantics of class(from) <- "numeric" I have no strong feelings on that, if someone wants to implement and defend a change. John + seth __ 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] Difference Linux / Windows
On 31/03/2010 6:38 PM, Seth Falcon wrote: On 3/31/10 1:12 PM, Christophe Genolini wrote: > Hi the list, > I am writing a package that happen to not be compatible with linux > because I did not know that the function "savePlot" was available only > on windows. Is there a list of "incompatible" function? How can I get > this kind of information? One way is to obtain a copy of the R sources and then grep the Rd files for '#ifdef'. I don't claim this is convenient. There has been discussion, and I believe general consensus, that we'd like to eliminate the conditional documentation. This requires editing the Rd files to make the contents sensible (you can't just remove the #ifdef's). Patches along these lines would be welcome. Producing those patches would be a lot of work even to incorporate, let alone write. Another possibility is some sort of markup in the display to indicate platform-specific bits. That would be a lot easier to implement; the hard part is the design. We have to design for 4 different output formats: LaTeX, HTML, plain text, and executable example code. We need to design for help files that display differently on different platforms, and for help files that only exist on a subset of the platforms. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strptime(): on Linux system it seems to call system time?
Thanks for the two posts.
What if the timezone is set? Then the issue of system calls for the
timezone falls away, no?
system.time(for (i in 1:10) strptime("2010-03-10 17:00:00", "%F
%H:%M:%S", tz="DST"))
Output on Linux Box (64-bit R 2.10.1 running on Intel Xeon E5520 @
2.27GHz):
user system elapsed
3.0963.2526.371
ORIGINAL
user system elapsed
3.338.94112.273
This is does speed up things considerably, but I still don't know for
what all that system time is used? If I can trace system calls, I will
follow up.
As far as vectorization is concerned, this example was meant as
reproducible "toy" code to illustrate an issue in a more complex,
non-"vectorizable" setup.
Alex
-Original Message-
From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
Sent: Thursday, April 01, 2010 4:38 AM
To: Patrick Connolly
Cc: Peter Dalgaard; r-devel@r-project.org; Alexander Peterhansl
Subject: Re: [Rd] strptime(): on Linux system it seems to call system
time?
Let me lay this to rest. For some reason the OP did not use a
vectorized call to strptime but 10 individual calls (as well as
making *false* claims about what strptime does and what is 'completely
unnecessary', and seemingly being igorant of system.time()).
I do not believe this is ever an issue for well-written R code.
Each time strptime() is called it needs to find and set the timezone
(as whether an input is valid or not and whether it is in DST depends
on the timezone). If tz = "", the default, it needs to ask the system
what the current timezone is via the C call tzset. On well-written C
runtimes tzset caches and so is fast after the first time. On some
others it reads files such as /etc/localtime each time.
On my Linux system (x86_64 Fedora 12)
system.time(for (i in 1:10) strptime("2010-03-10 17:00:00", "%F
%H:%M:%S"))
user system elapsed
1.048 0.222 2.086
system.time(strptime(rep("2010-03-10 17:00:00", 10), "%F %H:%M:%S"))
user system elapsed
0.371 0.184 0.579
whereas on my 2008 Mac laptop
user system elapsed
7.402 0.015 7.441
user system elapsed
6.689 0.013 6.716
and on my 2005 Windows laptop
user system elapsed
2.470.002.47
user system elapsed
1.390.001.40
(for which the credit is entirely due to the replacement code in R:
Windows' datetime code is only used for strftime).
So looks like Apple could improve their POSIX datetime runtime, but
I've never seen an R application where parsing dates took longer than
reading the original posting (let alone the time taken to read some
good books on how to time R code and write it efficiently).
On Thu, 1 Apr 2010, Patrick Connolly wrote:
> On Sat, 20-Mar-2010 at 06:54PM +0100, Peter Dalgaard wrote:
>
> [...]
>
> |> It seems to be completely system-dependent. On Fedora 9, I see
> |>
> |>user system elapsed
> |> 2.890 0.314 3.374
> |>
> |> but on openSUSE 10.3 it is
> |>
> |>user system elapsed
> |> 3.924 6.992 10.917
> |>
> |> At any rate, I suspect that this is an issue with the operating
system
> |> and its C libraries, not with R as such.
>
> Were those 32 or 64 bit?
>
> With Fedora 11 and AMD Athlon 2 Ghz, I get
>
> user system elapsed
> 1.395 0.294 1.885
>
> with Mepis 7 on a Celeron 1.6 Ghz,
>
> user system elapsed
> 3.890 5.896 9.845
>
> Both of those are 32 bit.
> Maybe 64 bit does things very differently.
>
>
>
> --
>
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
> ___Patrick Connolly
> {~._.~} Great minds discuss ideas
> _( Y )_Average minds discuss events
> (:_~*~_:) Small minds discuss people
> (_)-(_) . Eleanor Roosevelt
>
>
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")
John Chambers wrote:
The point I was making was that as() is not just a synonym for selecting
a method from coerce() by the usual inheritance rules. I don't believe
it should be, and the documentation emphasizes that inheritance is not
used in the ordinary way.
I got this. If you look carefully at the change I'm suggesting for
selectMethod(), you will notice that I said that f="coerce" would
then need to become a special case.
In other words, when f="coerce", the usual inheritance rules are
replaced by the rules that are currently implemented in as() and
described in its man page.
So to summarize: (1) the code in as() that is currently in charge of
selecting/creating/caching the most adequate coerce method is moved
to selectMethod(), (2) the sections in ?as that describe the rules
of this non-standard inheritance are moved to ?selectMethod.
If one were to start rewriting code (which I'm not suggesting) my
preference would be to have coerce() not be a generic function,
eliminating the offending selectMethod() calls.
Then how one would know what as() is doing *exactly* i.e. which
coerce method was used or will be used in such or such situation?
showMethods()/selectMethod() are great tools because they allow the
developer to predict things and troubleshoot.
If you don't like putting the non-standard inheritance rules in
selectMethod() (when f="coerce") then you can always add something
like selectAsMethod() and put them here, and also add something
like showAsMethods(). I guess that's more or less what you are
saying when you propose to have coerce() not be a generic function,
at least not an usual one.
But it's important to expose selectAsMethod()/showAsMethods() to
the user. We absolutely need them!
Now I'm not sure I understand your concern about putting this
stuff in the existing selectMethod()/showMethods(). Why not just
ignore the useInheritance= arg when f="coerce"? Again, this would
be a special case anyway (and documented). The advantage of this
solution (over selectAsMethod()/showAsMethods()) is to avoid having
to introduce and expose 2 new names, so the user doesn't have to
switch between select*/show* tools depending on whether f="coerce"
or not.
H.
John
On 4/1/10 12:31 AM, Hervé Pagès wrote:
Hi John,
John Chambers wrote:
The example is confusing and debatable, but not an obvious bug. And
your presentation of it is the cause of much of the confusion
(unintentionally I'm sure).
First, slipping from the as() function to methods for the coerce()
function might surprise a less experienced user. And in fact, that
is the point here. If you look at the as() function, it jumps
through several hoops and in particular selects a method from coerce
in such a way as NOT to use inheritance on the from= argument. (I
think this makes sense in this case). So I would assert that your
selectMethod() output below came from a different session than the
as(1:4, "numeric").
Starting from a clean session with R 2.10.1:
> class(as(1:4,"numeric"))
[1] "integer"
> selectMethod("coerce", c("integer","numeric"))
Method Definition:
function (from, to = "numeric", strict = TRUE)
if (strict) {
class(from) <- "numeric"
from
} else from
Signatures:
from to
target "integer" "numeric"
defined "integer" "numeric"
Note, no call to as.numeric(). In a session without a previous call
to as(), your selectMethod() call triggered a standard inherited
method selection. And if you had then gone on to as(), the result
would have been different.
Yes indeed. From a fresh start:
> invisible(selectMethod("coerce", c("integer","numeric")))
> class(as(1:4, "numeric"))
[1] "numeric"
But without the initial call to selectMethod(), as(1:4, "numeric")
returns an integer vector.
Sorry but it's hard for me to understand the reasons for having
such behaviour, especially when selectMethod() is described as a
function "to *look* for a method corresponding to a given generic
function and signature". Apparently it does more than just looking...
In a different clean session:
> getMethod("coerce", c("integer", "numeric"))
Error in getMethod("coerce", c("integer", "numeric")) :
No method found for function "coerce" and signature integer, numeric
> selectMethod("coerce", c("integer", "numeric"))
Method Definition:
function (from, to, strict = TRUE)
{
value <- as.numeric(from)
if (strict)
attributes(value) <- NULL
value
}
Signatures:
from to
target "integer" "numeric"
defined "ANY" "numeric"
> class(as(1:4,"numeric"))
[1] "numeric"
No argument about this being confusing. Perhaps one should prohibit
standard selectMethod() on coerce() but that seems a bit arcane to
thwart folks like you!
Suggested improvements for the current implementation are welcome, so
long as they consider the best definition of as() in the general sense.
So one problem seems to be that, on a fresh start, *both*
as(1:4, "numeric")
and
selectMethod("coerce", c("intege
Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")
The problem that you have exposed is that if one uses the *standard*
form of selectMethod() on function "coerce", this could corrupt the
intended set of methods used by as(). Of course, no one was expected to
do this, but it's not caught or warned (as opposed to a direct call to
coerce(), which does generate a warning).
If people think this is something of sufficient importance to put high
on the fix-it list, contributions are welcome as always.
However, it seems a really bad idea to start making the definition of
method selection by inheritance depend in an arbitrary way on which
function is operated on. Documenting what selection does is hard enough
as it is.
A solution localized to the as() computation is to treat the mechanism
involved in a call to setAsMethod as something special, and provide
whatever information is needed via showAsMethods(), or similar. From a
tutorial view, it might be good to emphasize that this is NOT the usual
method dispatch--indeed, the present discussion supports that view.
Method selection in a functional language is a difficult concept,
particularly for programmers coming from a standard OOP background. If
we're going to change it, let's aim to make it simpler, not more
complicated. What about getting rid of the kludgy argument
useInheritance= in a future version, if nobody has a use for it other
than in as()? If you look at the code, you'll see that would simplify
it significantly, and even speed up selection somewhat. There's a change
I would be happy about!
John
On 4/1/10 2:59 PM, Hervé Pagès wrote:
John Chambers wrote:
The point I was making was that as() is not just a synonym for
selecting a method from coerce() by the usual inheritance rules. I
don't believe it should be, and the documentation emphasizes that
inheritance is not used in the ordinary way.
I got this. If you look carefully at the change I'm suggesting for
selectMethod(), you will notice that I said that f="coerce" would
then need to become a special case.
In other words, when f="coerce", the usual inheritance rules are
replaced by the rules that are currently implemented in as() and
described in its man page.
So to summarize: (1) the code in as() that is currently in charge of
selecting/creating/caching the most adequate coerce method is moved
to selectMethod(), (2) the sections in ?as that describe the rules
of this non-standard inheritance are moved to ?selectMethod.
If one were to start rewriting code (which I'm not suggesting) my
preference would be to have coerce() not be a generic function,
eliminating the offending selectMethod() calls.
Then how one would know what as() is doing *exactly* i.e. which
coerce method was used or will be used in such or such situation?
showMethods()/selectMethod() are great tools because they allow the
developer to predict things and troubleshoot.
If you don't like putting the non-standard inheritance rules in
selectMethod() (when f="coerce") then you can always add something
like selectAsMethod() and put them here, and also add something
like showAsMethods(). I guess that's more or less what you are
saying when you propose to have coerce() not be a generic function,
at least not an usual one.
But it's important to expose selectAsMethod()/showAsMethods() to
the user. We absolutely need them!
Now I'm not sure I understand your concern about putting this
stuff in the existing selectMethod()/showMethods(). Why not just
ignore the useInheritance= arg when f="coerce"? Again, this would
be a special case anyway (and documented). The advantage of this
solution (over selectAsMethod()/showAsMethods()) is to avoid having
to introduce and expose 2 new names, so the user doesn't have to
switch between select*/show* tools depending on whether f="coerce"
or not.
H.
John
On 4/1/10 12:31 AM, Hervé Pagès wrote:
Hi John,
John Chambers wrote:
The example is confusing and debatable, but not an obvious bug. And
your presentation of it is the cause of much of the confusion
(unintentionally I'm sure).
First, slipping from the as() function to methods for the coerce()
function might surprise a less experienced user. And in fact, that
is the point here. If you look at the as() function, it jumps
through several hoops and in particular selects a method from coerce
in such a way as NOT to use inheritance on the from= argument. (I
think this makes sense in this case). So I would assert that your
selectMethod() output below came from a different session than the
as(1:4, "numeric").
Starting from a clean session with R 2.10.1:
> class(as(1:4,"numeric"))
[1] "integer"
> selectMethod("coerce", c("integer","numeric"))
Method Definition:
function (from, to = "numeric", strict = TRUE)
if (strict) {
class(from) <- "numeric"
from
} else from
Signatures:
from to
target "integer" "numeric"
defined "integer" "numeric"
Note, no call to as.numeric(). In a session without a previous call
to as(), your selectMetho
