[Rd] Unwanted axis labels when rug() has POSIXlt argument (PR#10380)
rug() may add integer axis labels when called with a POSIXlt object
as argument.
dtimes <- c("09/29/2007 12:54", "09/30/2007 00:14", "10/01/2007
00:14",
"10/02/2007 00:14", "10/03/2007 00:14", "10/04/2007
00:14",
"10/05/2007 00:14", "10/06/2007 00:14", "10/07/2007
00:14",
"10/08/2007 00:14")
z <- strptime(dtimes, "%m/%d/%Y %H:%M", tz="EST5EDT")
plot(z, rnorm(10))
rug(z)
This happens also undo Windows, both with 2.6.0 and 2.7.0 (2007-10-26
r43284)
--please do not edit the information below--
Version:
platform = i386-apple-darwin8.10.1
arch = i386
os = darwin8.10.1
system = i386, darwin8.10.1
status =
major = 2
minor = 6.0
year = 2007
month = 10
day = 03
svn rev = 43063
language = R
version.string = R version 2.6.0 (2007-10-03)
Locale:
C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads,
package:base
John Maindonald email: [EMAIL PROTECTED]
phone : +61 2 (6125)3473fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unwanted axis labels when rug() has POSIXlt argument (PR#10380)
On 27/10/2007 3:10 AM, [EMAIL PROTECTED] wrote:
> rug() may add integer axis labels when called with a POSIXlt object
> as argument.
>
> dtimes <- c("09/29/2007 12:54", "09/30/2007 00:14", "10/01/2007
> 00:14",
>"10/02/2007 00:14", "10/03/2007 00:14", "10/04/2007
> 00:14",
>"10/05/2007 00:14", "10/06/2007 00:14", "10/07/2007
> 00:14",
>"10/08/2007 00:14")
> z <- strptime(dtimes, "%m/%d/%Y %H:%M", tz="EST5EDT")
> plot(z, rnorm(10))
> rug(z)
>
> This happens also undo Windows, both with 2.6.0 and 2.7.0 (2007-10-26
> r43284)
rug() is documented to require a numeric vector as input, and z isn't
one of those, so there's an argument that this is user error. Still,
its behaviour is a little surprising.
The workaround is to use rug(as.numeric(z)).
Duncan Murdoch
>
> --please do not edit the information below--
>
> Version:
> platform = i386-apple-darwin8.10.1
> arch = i386
> os = darwin8.10.1
> system = i386, darwin8.10.1
> status =
> major = 2
> minor = 6.0
> year = 2007
> month = 10
> day = 03
> svn rev = 43063
> language = R
> version.string = R version 2.6.0 (2007-10-03)
>
> Locale:
> C
>
> Search Path:
> .GlobalEnv, package:stats, package:graphics, package:grDevices,
> package:utils, package:datasets, package:methods, Autoloads,
> package:base
>
> John Maindonald email: [EMAIL PROTECTED]
> phone : +61 2 (6125)3473fax : +61 2(6125)5549
> Centre for Mathematics & Its Applications, Room 1194,
> John Dedman Mathematical Sciences Building (Building 27)
> Australian National University, Canberra ACT 0200.
>
> __
> 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] Unwanted axis labels when rug() has POSIXlt argument (PR#10380)
Yes, I noticed after I had sent it that x was said to be numeric.
Incidentally, this does not happen, in my experience, with Date objects.
John Maindonald email: [EMAIL PROTECTED]
phone : +61 2 (6125)3473fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
On 27 Oct 2007, at 5:48 PM, Duncan Murdoch wrote:
> On 27/10/2007 3:10 AM, [EMAIL PROTECTED] wrote:
>> rug() may add integer axis labels when called with a POSIXlt object
>> as argument.
>> dtimes <- c("09/29/2007 12:54", "09/30/2007 00:14",
>> "10/01/2007 00:14",
>>"10/02/2007 00:14", "10/03/2007 00:14",
>> "10/04/2007 00:14",
>>"10/05/2007 00:14", "10/06/2007 00:14",
>> "10/07/2007 00:14",
>>"10/08/2007 00:14")
>> z <- strptime(dtimes, "%m/%d/%Y %H:%M", tz="EST5EDT")
>> plot(z, rnorm(10))
>> rug(z)
>> This happens also undo Windows, both with 2.6.0 and 2.7.0
>> (2007-10-26 r43284)
>
> rug() is documented to require a numeric vector as input, and z
> isn't one of those, so there's an argument that this is user
> error. Still, its behaviour is a little surprising.
>
> The workaround is to use rug(as.numeric(z)).
>
> Duncan Murdoch
>
>> --please do not edit the information below--
>> Version:
>> platform = i386-apple-darwin8.10.1
>> arch = i386
>> os = darwin8.10.1
>> system = i386, darwin8.10.1
>> status =
>> major = 2
>> minor = 6.0
>> year = 2007
>> month = 10
>> day = 03
>> svn rev = 43063
>> language = R
>> version.string = R version 2.6.0 (2007-10-03)
>> Locale:
>> C
>> Search Path:
>> .GlobalEnv, package:stats, package:graphics, package:grDevices,
>> package:utils, package:datasets, package:methods, Autoloads,
>> package:base
>> John Maindonald email: [EMAIL PROTECTED]
>> phone : +61 2 (6125)3473fax : +61 2(6125)5549
>> Centre for Mathematics & Its Applications, Room 1194,
>> John Dedman Mathematical Sciences Building (Building 27)
>> Australian National University, Canberra ACT 0200.
>> __
>> 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] Cell or PS3 Port
Hello, I am interested in optimizing some of R's vector math functions to utilize the SPE units of the Cell processor (commonly found in the Playstation 3) and I am wondering if anyone has already done any work in that area. I can't find anything using the search page or Google. (Admittedly it is difficult to search for information on a one-letter-named programming language whose contributed documentation intrinsically refers to "cells" frequently. :) I'm assuming it will be possible to compile R under a PS3 version of Linux, since it has a ppc64 architecture and R already runs on OS X. Are there any known caveats to compiling R for a distro like Ubuntu with X11 support? I'm just going through the Cell SDK documentation at this point so it will be a few days before I really get into the guts of it. Any information would be greatly appreciated. -Ed __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cell or PS3 Port
On 27 October 2007 at 10:35, Ed Knutson wrote: | I am interested in optimizing some of R's vector math functions to | utilize the SPE units of the Cell processor (commonly found in the | Playstation 3) and I am wondering if anyone has already done any work in | that area. I can't find anything using the search page or Google. | (Admittedly it is difficult to search for information on a | one-letter-named programming language whose contributed documentation | intrinsically refers to "cells" frequently. :) I'm assuming it will be See the r-devel archives for August where Doug Bates started a thread [Rd] Compiling R for the Sony Playstation 3 with many posts. The upshot,as I recall, is the he 'simply' installed Ubuntu on his PS3 in order to real software (read: Emacs, R) running on his 'dvd player' as he calls it. There is a lot of interest in making R work on things like the Cell as well as in GPGPU frameworks, at least for subroutines and libraries (and I understand that some work is ongoing in that area). The main R thread will probably remain single-threaded 'forever'. Others may have more pertinent comments. Hope this helps, Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] meaning of "trim" in mean()
There is only one _range_ mentioned, (0, 0.5). I don't see how you can construe 'that range' to be a reference to anything other than (0, 0.5). And why do you suppose the description for argument 'trim' is referring to 'values' of a different argument? It is telling you what happens for values of trim < 0 or > 0.5: that is not information that it is appropriate to excise. On Thu, 25 Oct 2007, Peter Dalgaard wrote: > Liaw, Andy wrote: >> (I see this in both R-patched r43124 and R-devel r43233.) >> In the Argument section of ?mean: >> >> trim the fraction (0 to 0.5) of observations to be trimmed from each >> end of x before the mean is computed. Values outside that range are >> taken as the nearest endpoint. >> >> Then in the Value section: >> >> If trim is non-zero, a symmetrically trimmed mean is computed with a >> fraction of trim observations deleted from each end before the mean is >> computed. >> >> The description in "trim" to me sounds like Windsorizing, rather than >> trimming. Should that be edited? >> >> > I think so: > >> x <- sort(rnorm(10)) >> mean(x,trim=.1) > [1] -0.6387413 >> mean(x[2:9]) > [1] -0.6387413 >> mean(x[c(2,2:9,9)]) # Winsorizing > [1] -0.6204222 > > So yes, it is trimming, not Winsorizing, and the last sentence in the > description of "trim" is misleading and should be, well..., trimmed. > > -- Brian D. Ripley, [EMAIL PROTECTED] 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
