Re: [R] Stratifying data with xyplot
See the examples here: https://www.stat.ubc.ca/~jenny/STAT545A/block10_latticeNittyGritty.html On Mon, Mar 11, 2019 at 2:26 PM Sebastien Bihorel < sebastien.biho...@cognigencorp.com> wrote: > Hi, > > I am a big user/fan of the lattice package for plotting. As far as I know, > lattice only offers one method to stratify data within a xyplot panel, > using the groups arguments. > A contrario, the ggplot package allow users to use different variables for > coloring, setting the symbols, the line types or the size of symbols. This > frequently comes handy. > My question is whether any work has been done in the lattice ecosystem to > reproduce this functionality? If so, I would greatly appreciate any > pointers to the appropriate package documentation. > > Thank you > > Sebastien > > __ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > -- Kevin Wright [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
[R] Stratifying data with xyplot
Hi, I am a big user/fan of the lattice package for plotting. As far as I know, lattice only offers one method to stratify data within a xyplot panel, using the groups arguments. A contrario, the ggplot package allow users to use different variables for coloring, setting the symbols, the line types or the size of symbols. This frequently comes handy. My question is whether any work has been done in the lattice ecosystem to reproduce this functionality? If so, I would greatly appreciate any pointers to the appropriate package documentation. Thank you Sebastien __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Q re: logical indexing with is.na
logical indexing requires the logical index to be of the same length as the vector being indexed. If it is not, then the index is wrapped to be of sufficient length. The result on line 3 is y[c(TRUE, TRUE, FALSE, TRUE)] where the last TRUE was originally the first component of !is.na(y[1:3]) Grant Izmirlian, Ph.D. Mathematical Statistician izmir...@mail.nih.gov Delivery Address: 9609 Medical Center Dr, RM 5E130 Rockville MD 20850 Postal Address: BG 9609 RM 5E130 MSC 9789 9609 Medical Center Dr Bethesda, MD 20892-9789 ofc: 240-276-7025 cell: 240-888-7367 fax: 240-276-7845 From: David Goldsmith Sent: Saturday, March 9, 2019 8:36 PM To: r-help@r-project.org Subject: [R] Q re: logical indexing with is.na Hi! Newbie (self-)learning R using P. Dalgaard's "Intro Stats w/ R"; not new to statistics (have had grad-level courses and work experience in statistics) or vectorized programming syntax (have extensive experience with MatLab, Python/NumPy, and IDL, and even a smidgen--a long time ago--of experience w/ S-plus). In exploring the use of is.na in the context of logical indexing, I've come across the following puzzling-to-me result: > y; !is.na(y[1:3]); y[!is.na(y[1:3])] [1] 0.3534253 -1.6731597 NA -0.2079209 [1] TRUE TRUE FALSE [1] 0.3534253 -1.6731597 -0.2079209 As you can see, y is a four element vector, the third element of which is NA; the next line gives what I would expect--T T F--because the first two elements are not NA but the third element is. The third line is what confuses me: why is the result not the two element vector consisting of simply the first two elements of the vector (or, if vectorized indexing in R is implemented to return a vector the same length as the logical index vector, which appears to be the case, at least the first two elements and then either NA or NaN in the third slot, where the logical indexing vector is FALSE): why does the implementation "go looking" for an element whose index in the "original" vector, 4, is larger than BOTH the largest index specified in the inner-most subsetting index AND the size of the resulting indexing vector? (Note: at first I didn't even understand why the result wasn't simply 0.3534253 -1.6731597 NA but then I realized that the third logical index being FALSE, there was no reason for *any* element to be there; but if there is, due to some overriding rule regarding the length of the result relative to the length of the indexer, shouldn't it revert back to *something* that indicates the "FALSE"ness of that indexing element?) Thanks! DLG > sessionInfo() R version 3.5.2 (2018-12-20) Platform: x86_64-apple-darwin15.6.0 (64-bit) Running under: macOS High Sierra 10.13.6 Matrix products: default BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] ISwR_2.0-7 loaded via a namespace (and not attached): [1] compiler_3.5.2 tools_3.5.2 [[alternative HTML version deleted]] [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] About wilcox test
First, I'm pretty sure this is a statistics question, not an R question. But you're asserting there is a difference in the data. The statistical test is telling you that this apparent difference is within the range of chance variation. There's not a contradiction there, unless you mean there is a statistically significant difference with the Wilcox test in some other computation method. Pat On 3/11/19, 12:47 PM, "R-help on behalf of javed khan" wrote: Hi, I have two set of data in excel: A column( 16.38, -31, -16.77, 127, -57, 23.44 and so on) B column ( -12, -59.23, -44, 34.23, 55.5, -12.12 and so on) I run the wilcox test as : wilcox.test(A , B, data = mydata, paired = FALSE) I got always the p value very high, like 0.60 Even I make changes in the data, it gives me 0.7, 0.4 etc which is too high than 0.05 and can not thus reject the null hypothesis. What could be the problem as I know there is difference in the data? Regards [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
[R] About wilcox test
Hi, I have two set of data in excel: A column( 16.38, -31, -16.77, 127, -57, 23.44 and so on) B column ( -12, -59.23, -44, 34.23, 55.5, -12.12 and so on) I run the wilcox test as : wilcox.test(A , B, data = mydata, paired = FALSE) I got always the p value very high, like 0.60 Even I make changes in the data, it gives me 0.7, 0.4 etc which is too high than 0.05 and can not thus reject the null hypothesis. What could be the problem as I know there is difference in the data? Regards [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R-es] Problema codificación archivos
Javier, Lo estoy haciendo todo dentro de R. ¿Quieres decir que el editor propio de R que uso para los scripts puede no coincidir con ell de R para ejecutar códigos? Saludos Enviado desde mi iPhone El 11 mar. 2019, a la(s) 13:04, Javier Nieto escribió: > Hola > > Deberías cambiar el encoding de tu ide o editor de texto. Si no mal he > entendido una cosa es el enconding del ide y otra con la que R ejecuta el > código (los 2 se ejecutan en la misma pantalla aunque sean diferentes > causando que se vean cosas como las que comentas) y ambos deberían de > coincidir desde el momento de la creación del archivo y si no toca modificar > a mano a fin de lograr la coincidencia. > > > Saludos > De: R-help-es en nombre de Sebastian Kruk > > Enviado: domingo, 10 de marzo de 2019 07:09 p. m. > Para: Javier Marcuzzi > CC: Lista R > Asunto: Re: [R-es] Problema codificación archivos > > Gracias Javier. Voy a probar. Saludos, Sebastián. > > Enviado desde Correo para Windows 10 > > De: Javier Marcuzzi > Enviado: domingo, 10 de marzo de 2019 14:53 > Para: Sebastian Kruk > CC: Lista R > Asunto: Re: [R-es] Problema codificación archivos > > Estimado Sebastian Kruk > > Yo utilizo Microsoft R-open 3.5.1 y la r-project se encuentra en 3.5.3, ¿si > intenta con cualquiera de estas dos? > > Javier Rubén Marcuzzi > > El dom., 10 mar. 2019 a las 13:12, Sebastian Kruk () > escribió: > Estimados Usuarios-R: > > Muy buenos dias. > > Estoy teniendo problemas cuando grabo un script en R con la codificación > del archivo. > > Tengo Windows 10 y R 3.5.2 64 bits. > > Por ejemplo grabo un script donde aparecen las palabras "España" y > "España" . > Cuando lo abro de vuelta se transforman en "España" y "España" > respectivamente. > Y si las dejo asi se siguen transformando. > > Supongo que tiene que ver con la codificación. Probé cambiar > options(encoding) pero no anduvo. > > ¿Cómo me aconsejan resolverlo? > > Saludos, > > Sebastián. > > [[alternative HTML version deleted]] > > ___ > R-help-es mailing list > R-help-es@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-help-es > > > [[alternative HTML version deleted]] > > ___ > R-help-es mailing list > R-help-es@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-help-es [[alternative HTML version deleted]] ___ R-help-es mailing list R-help-es@r-project.org https://stat.ethz.ch/mailman/listinfo/r-help-es
[R] R 3.5.3 is released
The build system rolled up R-3.5.3.tar.gz (codename "Great Truth") this morning. The list below details the changes in this release. This is the wrap-up release for the 3.5.x series, so actually, not much has happened. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.5.3.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 3bba37aa1dd06de3f781200a8081302f MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = ab129f42b1d5ca25122db6b1bda0fcd9 MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9 MD5 (R-latest.tar.gz) = 525e902dd331c387f271692a1537aff8 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = 08158353102084599797db8c9ccf8e2a MD5 (VERSION-INFO.dcf) = cb61b0eb560efcbbec47128abf3fb761 MD5 (R-3/R-3.5.3.tar.gz) = 525e902dd331c387f271692a1537aff8 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 98df47801c33cc4f4a4de98447cb2bd40e09c0920195f540a981ceed874714f2 FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL 4c6eb7cd9d8f4c1858a8f853698d2954d42d5d8b71c5c4d20bc6bd970f034bfe NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.2 2bfa37b7bd709f003d6b8a172ddfb6d03ddd2d672d6096439523039f7a8e678c R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES 2d2e85e85574c4430951f6b070c08cd5aff1602abfd1bb162bed6d89c436b11f THANKS 1ce83e7a843f95e8b0d5abf6ced7426cc337cc607f9862f99d46a7d05793ac15 VERSION-INFO.dcf 2bfa37b7bd709f003d6b8a172ddfb6d03ddd2d672d6096439523039f7a8e678c R-3/R-3.5.3.tar.gz This is the relevant part of the NEWS file: CHANGES IN R 3.5.3: INSTALLATION on a UNIX-ALIKE: * Detection of flags for C++98/11/14/17 has been improved: in particular if CXX??STD is set, it is tried first with no additional flags. PACKAGE INSTALLATION: * New macro F_VISIBILITY as an alternative to F77_VISIBILITY. This will become the preferred form in R 3.6.0. BUG FIXES: * writeLines(readLines(fnam), fnam) now works as expected, thanks to Peter Meissner's PR#17528. * setClassUnion() no longer warns, but uses message() for now, when encountering "non local" subclasses of class members. * stopifnot(exprs = T) no longer fails. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com ___ r-annou...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-announce __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] [FORGED] Q re: logical indexing with is.na
Hi Do you want something like this? > x <- c(1,2,NA, 3, 4, 5, NA, 6,7,8, NA, NA, 9,10) > y <- c(1,2,NA, NA, 3, 4, 5, 6, NA, 7,8, NA, NA, 9,10) > identical(x[which(!is.na(x))], y[which(!is.na(y))]) [1] TRUE If I expect NA and want to extract or compare something, I tend to use which to select only non NA elements. Cheers Petr > -Original Message- > From: R-help On Behalf Of David Goldsmith > Sent: Sunday, March 10, 2019 7:16 AM > Cc: r-help@r-project.org > Subject: Re: [R] [FORGED] Q re: logical indexing with is.na > > Thanks, all. I had read about recycling, but I guess I didn't fully > appreciate all > the "weirdness" it might produce. :/ > > With this explained, I'm going to ask a follow-up, which is only contextually > related: the impetus for this discovery was checking "corner cases" to > determine if all(x[!is.na(x)]==y[!is.na(y)]) would suffice to determine > equality of > two vectors containing NA's. Between the above result; my related discovery > that this indexing preserves relative positional info but not absolute > positional > info; and the performance penalty when comparing long vectors that may be > unequal "early on"; I've concluded that--if it (can be made to) "short > circuit"--it > would probably be better to use an implicit loop. So that's my Q: will (or > can) > an implicit loop (be made to) "exit early" if a specified condition is met > before > all indices have been checked? > > Thanks again! > > DLG > > On Sat, Mar 9, 2019 at 9:07 PM Jeff Newmiller > wrote: > > > Regarding the mention of logical indexing, under ?Extract I see: > > > > For [-indexing only: i, j, ... can be logical vectors, indicating > > elements/slices to select. Such vectors are recycled if necessary to > > match the corresponding extent. i, j, ... can also be negative > > integers, indicating elements/slices to leave out of the selection. > > > > On March 9, 2019 6:57:05 PM PST, Rolf Turner > > wrote: > > >On 3/10/19 2:36 PM, David Goldsmith wrote: > > >> Hi! Newbie (self-)learning R using P. Dalgaard's "Intro Stats w/ > > >> R"; > > >not > > >> new to statistics (have had grad-level courses and work experience > > >> in > > >> statistics) or vectorized programming syntax (have extensive > > >experience > > >> with MatLab, Python/NumPy, and IDL, and even a smidgen--a long time > > >ago--of > > >> experience w/ S-plus). > > >> > > >> In exploring the use of is.na in the context of logical indexing, > > >I've come > > >> across the following puzzling-to-me result: > > >> > > >>> y; !is.na(y[1:3]); y[!is.na(y[1:3])] > > >> [1] 0.3534253 -1.6731597 NA -0.2079209 > > >> [1] TRUE TRUE FALSE > > >> [1] 0.3534253 -1.6731597 -0.2079209 > > >> > > >> As you can see, y is a four element vector, the third element of > > >which is > > >> NA; the next line gives what I would expect--T T F--because the > > >> first > > >two > > >> elements are not NA but the third element is. The third line is > > >> what confuses me: why is the result not the two element vector > > >> consisting > > >of > > >> simply the first two elements of the vector (or, if vectorized > > >indexing in > > >> R is implemented to return a vector the same length as the logical > > >index > > >> vector, which appears to be the case, at least the first two > > >> elements > > >and > > >> then either NA or NaN in the third slot, where the logical indexing > > >vector > > >> is FALSE): why does the implementation "go looking" for an element > > >whose > > >> index in the "original" vector, 4, is larger than BOTH the largest > > >index > > >> specified in the inner-most subsetting index AND the size of the > > >resulting > > >> indexing vector? (Note: at first I didn't even understand why the > > >result > > >> wasn't simply > > >> > > >> 0.3534253 -1.6731597 NA > > >> > > >> but then I realized that the third logical index being FALSE, there > > >was no > > >> reason for *any* element to be there; but if there is, due to some > > >> overriding rule regarding the length of the result relative to the > > >length > > >> of the indexer, shouldn't it revert back to *something* that > > >indicates the > > >> "FALSE"ness of that indexing element?) > > >> > > >> Thanks! > > > > > >It happens because R is eco-concious and re-cycles. :-) > > > > > >Try: > > > > > >ok <- c(TRUE,TRUE,FALSE) > > >(1:4)[ok] > > > > > >In general in R if there is an operation involving two vectors then > > >the shorter one gets recycled to provide sufficiently many entries to > > >match those of the longer vector. > > > > > >This in the foregoing example the first entry of "ok" gets used > > >again, to make a length 4 vector to match up with 1:4. The result is > > >the same > > > > > >as (1:4)[c(TRUE,TRUE,FALSE,TRUE)]. > > > > > >If you did (1:7)[ok] you'd get the same result as that from > > >(1:7)[c(TRUE,TRUE,FALSE,TRUE,TRUE,FALSE,TRUE)] i.e. "ok" gets > > >recycled 2 and 1/3 times. > > > > > >Try 10*(1:3) + 1:4, 10*(1:3) + 1:5, 10*(1:3) +
