Re: [Rd] Max likelihood using GPU
Thanks Rob, I have notified the maintainer about the suggestion. Oyvind From: Robert Lowe ra...@cam.ac.uk To: oyvfos oyv...@yahoo.no Cc: r-devel@r-project.org Sent: Wed, May 18, 2011 2:27:15 PM Subject: Re: [Rd] Max likelihood using GPU Hi Oyvind, I believe this is possible to implement. There is already some work ongoing in using the GPU in R and they use the CUDA toolkit as the reference you supplied do. http://brainarray.mbni.med.umich.edu/Brainarray/rgpgpu/ Thanks, Rob On 18 May 2011, at 10:07, oyvfos wrote: Dear all, Probably many of you experience long computation times when estimating large number of parameters using maximum likelihood with functions that reguire numerical methods such as integration or root-finding. Maximum likelihood is an example of paralellization that could sucessfully utilize GPU. The general algorithm is described here: http://openlab-mu-internal.web.cern.ch/openlab-mu-internal/03_Documents/4_Presentations/Slides/2010-list/CHEP-Maximum-likelihood-fits-on-GPUs.pdf. . Is it possible to implement this algorithm in R ? Kind regards, Oyvind Foshaug -- View this message in context: http://r.789695.n4.nabble.com/Max-likelihood-using-GPU-tp3532034p3532034.html Sent from the R devel mailing list archive at Nabble.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
Re: [Rd] Max likelihood using GPU
Hi Oyvind, I believe this is possible to implement. There is already some work ongoing in using the GPU in R and they use the CUDA toolkit as the reference you supplied do. http://brainarray.mbni.med.umich.edu/Brainarray/rgpgpu/ Thanks, Rob On 18 May 2011, at 10:07, oyvfos wrote: Dear all, Probably many of you experience long computation times when estimating large number of parameters using maximum likelihood with functions that reguire numerical methods such as integration or root-finding. Maximum likelihood is an example of paralellization that could sucessfully utilize GPU. The general algorithm is described here: http://openlab-mu-internal.web.cern.ch/openlab-mu-internal/03_Documents/4_Presentations/Slides/2010-list/CHEP-Maximum-likelihood-fits-on-GPUs.pdf. Is it possible to implement this algorithm in R ? Kind regards, Oyvind Foshaug -- View this message in context: http://r.789695.n4.nabble.com/Max-likelihood-using-GPU-tp3532034p3532034.html Sent from the R devel mailing list archive at Nabble.com. __ 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] IDWT - Inverse Discrete Wavelet Transform
Hello, I am not expert in wavelet. i am working with a discrete dataset in 3D. I applied the D4 wavelet transform to each dimension sequentially. I made some analysis in the transformed space and i detected some interesting vowel. My question is. How is it possible to map a 3d coordinate in the transformed space to the related coordinate in the 3d original dataset? (i think that probably one (x,y,z point in the 3d transformed space will be related probably with 8 vowels in the orginal one...)) Thanks in advance for the help Massimiliano -- View this message in context: http://r.789695.n4.nabble.com/IDWT-Inverse-Discrete-Wavelet-Transform-tp3535334p3535334.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Feature request: extend functionality of 'unlist()' by args 'delim=c(/, _, etc.)' and 'keep.special=TRUE/FALSE'
Dear list, I hope this is the right place to post a feature request. If there's exists a more formal channel (e.g. as for bug reports), I'd appreciate a pointer. I work a lot with named nested lists with arbitrary degrees of nestedness. In order to retrieve the names and/or values of bottom layer/bottom tier, I love the functionality of 'unlist()', or 'names(unlist(x))', respectively as it avoids traversing the nested lists via recursive loop constructs. I'm also aware that the general suggestion is probably to keep nestedness as low as possible when working with lists, but arbitrary deeply nested lists came in quite handy for me as long as each element is named and as long as I can quickly add and retrieve element values via name paths. Here's a little example list: lst - list(a=list(a.1=list(a.1.1=NA, a.1.2=5), a.2=list()), b=NULL) It would be awesome if 'unlist(x)' could be extended with the following functionality: 1) An argument such as 'delim' that controls how the respective layer names are pasted. Right now, they are always separated by a dot: names(unlist(lst)) [1] a.a.1.a.1.1 a.a.1.a.1.2 Desired: names(unlist(lst, delim=/)) [1] a/a.1/a.1.1 a/a.1/a.1.2 names(unlist(lst, delim=_)) [1] a_a.1_a.1.1 a_a.1_a.1.2 2) An argument that allows to include either elements of zero length or of value NULL to be *included* in the resulting output. Right now, they are dropped (which makes perfect sense as NULL values and zero length values are dropped in vectors): c(1,2, NULL, numeric()) [1] 1 2 unlist(lst) a.a.1.a.1.1 a.a.1.a.1.2 NA 5 Desired: unlist(lst, delim=/, keep.special=TRUE) $a/a.1/a.1.1 [1] NA $a/a.1/a.1.2 [1] 5 $a/a.2 list() $b NULL Of course, this would not be a true 'unlist' anymore, but something like 'retrieveBottomLayer()'. Thanks a lot for providing such fast stuff as 'unlist()'! Unfortunately, I don't know my way around internal C routines and therefore I would greatly appreciate if core team developers would consider my two suggestions. Best regards, Janko -- *Janko Thyson* janko.thy...@ku-eichstaett.de mailto:janko.thy...@ku-eichstaett.de Catholic University of Eichstätt-Ingolstadt Ingolstadt School of Management Statistics and Quantitative Methods Auf der Schanz 49 D-85049 Ingolstadt www.wfi.edu/lsqm http://www.wfi.edu/lsqm Fon: +49 841 937-1923 Fax: +49 841 937-1965 This e-mail and any attachment is for authorized use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. -- *Janko Thyson* janko.thy...@googlemail.com mailto:janko.thy...@googlemail.com Jesuitenstraße 3 D-85049 Ingolstadt Mobile: +49 (0)176 83294257 This e-mail and any attachment is for authorized use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in svg() : cairo-based devices are not supported on this build
Hello, Sorry if it is not the right place.. I installed R-2.13.0 on a x86_64 linux server. All went fine, but the svg() function yells: svg() Error in svg() : cairo-based devices are not supported on this build I have the Cairo, cairoDevice, RSvgDevice packages installed, and running. Cairo.capabilities() png jpeg tiff pdf svgps x11 win TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE I tried to google around unsuccessfully. The only thing I noticed in config.log is: r_cv_has_pangocairo=no r_cv_cairo_works=yes r_cv_has_cairo=yes #define HAVE_WORKING_CAIRO 1 #define HAVE_CAIRO_PDF 1 #define HAVE_CAIRO_PS 1 #define HAVE_CAIRO_SVG 1 So what can be wrong ?? Thank you Karl [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] r-2.13 fails make check
I am only reporting this because it is the current release branch and
not devel.
R-2.13 from svn revision 55957 builds fine, but fails make check.
This happened with a fresh svn checkout 12 hours ago and it still
happens as of now. Two days ago I could build R-2.13 and it passed
make check on the same system, so I doubt it is a system problem. But
just in case my system details are a fresh install of OS X Snow
Leopard (new machine) with Xcode 4 and Simon's gfortran and a number
of his other libraries (readline, cairo, libpng, jpeg, pixman and some
others).
Output from make check:
running code in '../../R-2.13-src/tests/reg-examples1.R' ... OK
running code in '../../R-2.13-src/tests/reg-examples2.R' ... OK
running code in '../../R-2.13-src/tests/reg-packages.R' ...make[3]:
*** [reg-packages.Rout] Error 1
make[2]: *** [test-Reg] Error 2
make[1]: *** [test-all-basics] Error 1
make: *** [check] Error 2
locating tests/reg-packages.Rout.fail I find
stopifnot(require(myTst,lib = myLib))
Loading required package: myTst
sm - findMethods(show, where= as.environment(package:myTst))
stopifnot(names(sm@names) == foo)
unlink(myTst_*)
## More building installing packages
## NB: tests were added here for 2.11.0.
## NB^2: do not do this in the R sources!
## and this testdir is not installed.
pkgSrcPath - file.path(Sys.getenv(SRCDIR), Pkgs)
if(file_test(-d, pkgSrcPath)) {
+ ## could use file.copy(recursive = TRUE)
+ system(paste('cp -r', shQuote(pkgSrcPath), shQuote(tempdir(
+ pkgPath - file.path(tempdir(), Pkgs)
+ op - options(warn=2)# There should be *NO* warnings here!
+ ## pkgB tests an empty R directory
+ dir.create(file.path(pkgPath, pkgB, R), recursive = TRUE,
+showWarnings = FALSE)
+ p.lis - c(pkgA, pkgB, exS4noNS, exNSS4)
+ for(p. in p.lis) {
+ cat(building package, p., ...\n)
+ r - build.pkg(file.path(pkgPath, p.))
+ cat(installing package, p., using file, r, ...\n)
+ ## we could install the tar file ... (see build.pkg()'s definition)
+ install.packages(r, lib = myLib, repos=NULL, type = source)
+ stopifnot(require(p.,lib = myLib, character.only=TRUE))
+ detach(pos = match(p., sub(^package:,, search(
+ }
+ ## TODO: not just print, but check the list:
+ print(installed.packages(lib.loc = myLib, priority = NA))
+ options(op)
+ unlink(myLib, recursive = TRUE)
+ unlink(file.path(pkgPath), recursive = TRUE)
+ }
building package pkgA ...
Error in parse_description_field(desc, BuildKeepEmpty, keep_empty1) :
object 'keep_empty1' not found
Execution halted
Error: (converted from warning) running command
'/Users/khansen/Source/R-2.13-build/bin/R CMD build --keep-empty-dirs
/var/folders/E3/E3ZBCIQ9El4LlIR92ARpyE+++TI/-Tmp-//Rtmpw9faGg/Pkgs/pkgA'
had status 1
Execution halted
Kasper
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Feature request: extend functionality of 'unlist()' by args 'delim=c(/, _, etc.)' and 'keep.special=TRUE/FALSE'
On 19/05/2011 8:15 AM, Janko Thyson wrote: Dear list, I hope this is the right place to post a feature request. If there's exists a more formal channel (e.g. as for bug reports), I'd appreciate a pointer. This is a good place to post. I work a lot with named nested lists with arbitrary degrees of nestedness. In order to retrieve the names and/or values of bottom layer/bottom tier, I love the functionality of 'unlist()', or 'names(unlist(x))', respectively as it avoids traversing the nested lists via recursive loop constructs. I'm also aware that the general suggestion is probably to keep nestedness as low as possible when working with lists, but arbitrary deeply nested lists came in quite handy for me as long as each element is named and as long as I can quickly add and retrieve element values via name paths. Here's a little example list: lst- list(a=list(a.1=list(a.1.1=NA, a.1.2=5), a.2=list()), b=NULL) It would be awesome if 'unlist(x)' could be extended with the following functionality: 1) An argument such as 'delim' that controls how the respective layer names are pasted. Right now, they are always separated by a dot: names(unlist(lst)) [1] a.a.1.a.1.1 a.a.1.a.1.2 Desired: names(unlist(lst, delim=/)) [1] a/a.1/a.1.1 a/a.1/a.1.2 names(unlist(lst, delim=_)) [1] a_a.1_a.1.1 a_a.1_a.1.2 2) An argument that allows to include either elements of zero length or of value NULL to be *included* in the resulting output. Right now, they are dropped (which makes perfect sense as NULL values and zero length values are dropped in vectors): c(1,2, NULL, numeric()) [1] 1 2 unlist(lst) a.a.1.a.1.1 a.a.1.a.1.2 NA 5 Desired: unlist(lst, delim=/, keep.special=TRUE) $a/a.1/a.1.1 [1] NA $a/a.1/a.1.2 [1] 5 $a/a.2 list() $b NULL Of course, this would not be a true 'unlist' anymore, but something like 'retrieveBottomLayer()'. Thanks a lot for providing such fast stuff as 'unlist()'! Unfortunately, I don't know my way around internal C routines and therefore I would greatly appreciate if core team developers would consider my two suggestions. The suggestions seem reasonable, but are difficult to implement. The problem is that unlist() is a generic function, but there's no unlist.default() in R: the default and method dispatch are implemented at the C level. Normally adding arguments to the default method doesn't cause problems elsewhere, because methods only need to be compatible with the generic. But since there's no way to modify the argument list of the default method in this case, the generic function would need to be modified, and that means every unlist method would need to be modified too. So I wouldn't want to take this on. In case someone else does, I'd suggest a different change than the keep.special argument. I think a coerce=TRUE argument would be better: If TRUE, you get the current behaviour, which coerces components according to the hierarchy listed on the help page. If FALSE, then no coercion is done, and unlist() just flattens the list into a new one, e.g. unlist( list(1, 2, NULL, list(A, B)), coerce=FALSE) would return list(1, 2, NULL, A, B) instead of c(1, 2, A, B). One workaround I thought of was to add an element to the list that couldn't be coerced, but this doesn't work. For example: e - environment() # can't be coerced x - list(1, 2, NULL, list(A, B), e) unlist(x) # Returns list(1,2,A,B,e) I think it would be reasonable for this version to retain the NULL, since it is not doing any coercion. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDWT - Inverse Discrete Wavelet Transform
ruoccoma ruoccoma at gmail.com writes: Hello, I am not expert in wavelet. i am working with a discrete dataset in 3D. I applied the D4 wavelet transform to each dimension sequentially. I made some analysis in the transformed space and i detected some interesting vowel. My question is. How is it possible to map a 3d coordinate in the transformed space to the related coordinate in the 3d original dataset? (i think that probably one (x,y,z point in the 3d transformed space will be related probably with 8 vowels in the orginal one...)) Thanks in advance for the help Massimiliano As written, this is a wavelet question, not an R one ... it's possible that you will get help, but if you don't it's because you're asking in the wrong place (i.e. on an R-help list). Also, if you do choose to continue asking on R lists, you should ask on r-help (the general help list) rather than here (r-devel, the list for r development). It would increase your chances a lot if you specified what you were doing (at a minimum, which contributed packages you are using -- as far as I know there is know wavelet capability in base R -- and probably which particular functions from those packages). It would be best if you could provide a reproducible question -- although I recognize that could be difficult in this case. You might also try stackoverflow.com or stackexchange.com good luck Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in svg() : cairo-based devices are not supported on this build
On May 19, 2011, at 8:45 AM, Karl Forner wrote: Hello, Sorry if it is not the right place.. I installed R-2.13.0 on a x86_64 linux server. All went fine, but the svg() function yells: svg() Error in svg() : cairo-based devices are not supported on this build I have the Cairo, cairoDevice, RSvgDevice packages installed, and running. Those are irrelevant for svg() which is provided by built-in cairo support in R, not the packages, so you want to check capabilities(): capabilities(cairo) cairo TRUE But if you have working Cairo package can simply use CairoSVG() instead of svg(). Cheers, Simon Cairo.capabilities() png jpeg tiff pdf svgps x11 win TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE I tried to google around unsuccessfully. The only thing I noticed in config.log is: r_cv_has_pangocairo=no r_cv_cairo_works=yes r_cv_has_cairo=yes #define HAVE_WORKING_CAIRO 1 #define HAVE_CAIRO_PDF 1 #define HAVE_CAIRO_PS 1 #define HAVE_CAIRO_SVG 1 So what can be wrong ?? Thank you Karl [[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] r-2.13 fails make check
Note to myself: read R-core before R-devel ;). It's apparently fixed by now. I
have restarted the nightly build so the binaries should be up again soon.
Cheers,
Simon
On May 19, 2011, at 10:03 AM, Simon Urbanek wrote:
Yes, this must be from some commit yesterday, because the build from previous
night worked. I see the same error in the nightly builds:
http://r.research.att.com/log-R-2.13-branch.leopard.i386.html
On May 19, 2011, at 8:47 AM, Kasper Daniel Hansen wrote:
I am only reporting this because it is the current release branch and
not devel.
R-2.13 from svn revision 55957 builds fine, but fails make check.
This happened with a fresh svn checkout 12 hours ago and it still
happens as of now. Two days ago I could build R-2.13 and it passed
make check on the same system, so I doubt it is a system problem. But
just in case my system details are a fresh install of OS X Snow
Leopard (new machine) with Xcode 4 and Simon's gfortran and a number
of his other libraries (readline, cairo, libpng, jpeg, pixman and some
others).
Output from make check:
running code in '../../R-2.13-src/tests/reg-examples1.R' ... OK
running code in '../../R-2.13-src/tests/reg-examples2.R' ... OK
running code in '../../R-2.13-src/tests/reg-packages.R' ...make[3]:
*** [reg-packages.Rout] Error 1
make[2]: *** [test-Reg] Error 2
make[1]: *** [test-all-basics] Error 1
make: *** [check] Error 2
locating tests/reg-packages.Rout.fail I find
stopifnot(require(myTst,lib = myLib))
Loading required package: myTst
sm - findMethods(show, where= as.environment(package:myTst))
stopifnot(names(sm@names) == foo)
unlink(myTst_*)
## More building installing packages
## NB: tests were added here for 2.11.0.
## NB^2: do not do this in the R sources!
## and this testdir is not installed.
pkgSrcPath - file.path(Sys.getenv(SRCDIR), Pkgs)
if(file_test(-d, pkgSrcPath)) {
+ ## could use file.copy(recursive = TRUE)
+ system(paste('cp -r', shQuote(pkgSrcPath), shQuote(tempdir(
+ pkgPath - file.path(tempdir(), Pkgs)
+ op - options(warn=2)# There should be *NO* warnings here!
+ ## pkgB tests an empty R directory
+ dir.create(file.path(pkgPath, pkgB, R), recursive = TRUE,
+showWarnings = FALSE)
+ p.lis - c(pkgA, pkgB, exS4noNS, exNSS4)
+ for(p. in p.lis) {
+ cat(building package, p., ...\n)
+ r - build.pkg(file.path(pkgPath, p.))
+ cat(installing package, p., using file, r, ...\n)
+ ## we could install the tar file ... (see build.pkg()'s definition)
+ install.packages(r, lib = myLib, repos=NULL, type = source)
+ stopifnot(require(p.,lib = myLib, character.only=TRUE))
+ detach(pos = match(p., sub(^package:,, search(
+ }
+ ## TODO: not just print, but check the list:
+ print(installed.packages(lib.loc = myLib, priority = NA))
+ options(op)
+ unlink(myLib, recursive = TRUE)
+ unlink(file.path(pkgPath), recursive = TRUE)
+ }
building package pkgA ...
Error in parse_description_field(desc, BuildKeepEmpty, keep_empty1) :
object 'keep_empty1' not found
Execution halted
Error: (converted from warning) running command
'/Users/khansen/Source/R-2.13-build/bin/R CMD build --keep-empty-dirs
/var/folders/E3/E3ZBCIQ9El4LlIR92ARpyE+++TI/-Tmp-//Rtmpw9faGg/Pkgs/pkgA'
had status 1
Execution halted
Kasper
__
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] Feature request: extend functionality of 'unlist()' by args 'delim=c(/, _, etc.)' and 'keep.special=TRUE/FALSE'
On 19.05.2011 14:58, Duncan Murdoch wrote: On 19/05/2011 8:15 AM, Janko Thyson wrote: Dear list, I hope this is the right place to post a feature request. If there's exists a more formal channel (e.g. as for bug reports), I'd appreciate a pointer. This is a good place to post. I work a lot with named nested lists with arbitrary degrees of nestedness. In order to retrieve the names and/or values of bottom layer/bottom tier, I love the functionality of 'unlist()', or 'names(unlist(x))', respectively as it avoids traversing the nested lists via recursive loop constructs. I'm also aware that the general suggestion is probably to keep nestedness as low as possible when working with lists, but arbitrary deeply nested lists came in quite handy for me as long as each element is named and as long as I can quickly add and retrieve element values via name paths. Here's a little example list: lst- list(a=list(a.1=list(a.1.1=NA, a.1.2=5), a.2=list()), b=NULL) It would be awesome if 'unlist(x)' could be extended with the following functionality: 1) An argument such as 'delim' that controls how the respective layer names are pasted. Right now, they are always separated by a dot: names(unlist(lst)) [1] a.a.1.a.1.1 a.a.1.a.1.2 Desired: names(unlist(lst, delim=/)) [1] a/a.1/a.1.1 a/a.1/a.1.2 names(unlist(lst, delim=_)) [1] a_a.1_a.1.1 a_a.1_a.1.2 2) An argument that allows to include either elements of zero length or of value NULL to be *included* in the resulting output. Right now, they are dropped (which makes perfect sense as NULL values and zero length values are dropped in vectors): c(1,2, NULL, numeric()) [1] 1 2 unlist(lst) a.a.1.a.1.1 a.a.1.a.1.2 NA 5 Desired: unlist(lst, delim=/, keep.special=TRUE) $a/a.1/a.1.1 [1] NA $a/a.1/a.1.2 [1] 5 $a/a.2 list() $b NULL Of course, this would not be a true 'unlist' anymore, but something like 'retrieveBottomLayer()'. Thanks a lot for providing such fast stuff as 'unlist()'! Unfortunately, I don't know my way around internal C routines and therefore I would greatly appreciate if core team developers would consider my two suggestions. The suggestions seem reasonable, but are difficult to implement. The problem is that unlist() is a generic function, but there's no unlist.default() in R: the default and method dispatch are implemented at the C level. Normally adding arguments to the default method doesn't cause problems elsewhere, because methods only need to be compatible with the generic. But since there's no way to modify the argument list of the default method in this case, the generic function would need to be modified, and that means every unlist method would need to be modified too. So I wouldn't want to take this on. Okay, get it. Thanks for the insight. In case someone else does, I'd suggest a different change than the keep.special argument. I think a coerce=TRUE argument would be better: If TRUE, you get the current behaviour, which coerces components according to the hierarchy listed on the help page. If FALSE, then no coercion is done, and unlist() just flattens the list into a new one, e.g. unlist( list(1, 2, NULL, list(A, B)), coerce=FALSE) would return list(1, 2, NULL, A, B) instead of c(1, 2, A, B). One workaround I thought of was to add an element to the list that couldn't be coerced, but this doesn't work. For example: e - environment() # can't be coerced x - list(1, 2, NULL, list(A, B), e) unlist(x) # Returns list(1,2,A,B,e) I think it would be reasonable for this version to retain the NULL, since it is not doing any coercion. Thanks for taking the time to address this. A function that also seemed pretty fast to me with respect to retrieving list structures is 'str(x)' and I thought about rewriting it to have it return the desired result. But as far as I understand the 'str.default()' method also just depends on recursive looping. Can you think of any other more efficient way to get the job done? Best regards, Janko Duncan Murdoch -- *Janko Thyson* janko.thy...@googlemail.com mailto:janko.thy...@googlemail.com Jesuitenstraße 3 D-85049 Ingolstadt Mobile: +49 (0)176 83294257 This e-mail and any attachment is for authorized use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Feature request: extend functionality of 'unlist()' by args 'delim=c(/, _, etc.)' and 'keep.special=TRUE/FALSE'
On 19.05.2011 14:58, Duncan Murdoch wrote: On 19/05/2011 8:15 AM, Janko Thyson wrote: Dear list, I hope this is the right place to post a feature request. If there's exists a more formal channel (e.g. as for bug reports), I'd appreciate a pointer. This is a good place to post. I work a lot with named nested lists with arbitrary degrees of nestedness. In order to retrieve the names and/or values of bottom layer/bottom tier, I love the functionality of 'unlist()', or 'names(unlist(x))', respectively as it avoids traversing the nested lists via recursive loop constructs. I'm also aware that the general suggestion is probably to keep nestedness as low as possible when working with lists, but arbitrary deeply nested lists came in quite handy for me as long as each element is named and as long as I can quickly add and retrieve element values via name paths. Here's a little example list: lst- list(a=list(a.1=list(a.1.1=NA, a.1.2=5), a.2=list()), b=NULL) It would be awesome if 'unlist(x)' could be extended with the following functionality: 1) An argument such as 'delim' that controls how the respective layer names are pasted. Right now, they are always separated by a dot: names(unlist(lst)) [1] a.a.1.a.1.1 a.a.1.a.1.2 Desired: names(unlist(lst, delim=/)) [1] a/a.1/a.1.1 a/a.1/a.1.2 names(unlist(lst, delim=_)) [1] a_a.1_a.1.1 a_a.1_a.1.2 2) An argument that allows to include either elements of zero length or of value NULL to be *included* in the resulting output. Right now, they are dropped (which makes perfect sense as NULL values and zero length values are dropped in vectors): c(1,2, NULL, numeric()) [1] 1 2 unlist(lst) a.a.1.a.1.1 a.a.1.a.1.2 NA 5 Desired: unlist(lst, delim=/, keep.special=TRUE) $a/a.1/a.1.1 [1] NA $a/a.1/a.1.2 [1] 5 $a/a.2 list() $b NULL Of course, this would not be a true 'unlist' anymore, but something like 'retrieveBottomLayer()'. Thanks a lot for providing such fast stuff as 'unlist()'! Unfortunately, I don't know my way around internal C routines and therefore I would greatly appreciate if core team developers would consider my two suggestions. The suggestions seem reasonable, but are difficult to implement. The problem is that unlist() is a generic function, but there's no unlist.default() in R: the default and method dispatch are implemented at the C level. Normally adding arguments to the default method doesn't cause problems elsewhere, because methods only need to be compatible with the generic. But since there's no way to modify the argument list of the default method in this case, the generic function would need to be modified, and that means every unlist method would need to be modified too. So I wouldn't want to take this on. Just one more question regarding this: would it then maybe possible to take the existing generic function 'unlist()', modify it and introduce it as a new function, say 'flatten()' for which methods exist for environments and lists?. That way you would not have to touch existing methods for 'unlist()'. Or is the introduction of new base functions discouraged in order to keep things manageable? Thanks again! In case someone else does, I'd suggest a different change than the keep.special argument. I think a coerce=TRUE argument would be better: If TRUE, you get the current behaviour, which coerces components according to the hierarchy listed on the help page. If FALSE, then no coercion is done, and unlist() just flattens the list into a new one, e.g. unlist( list(1, 2, NULL, list(A, B)), coerce=FALSE) would return list(1, 2, NULL, A, B) instead of c(1, 2, A, B). One workaround I thought of was to add an element to the list that couldn't be coerced, but this doesn't work. For example: e - environment() # can't be coerced x - list(1, 2, NULL, list(A, B), e) unlist(x) # Returns list(1,2,A,B,e) I think it would be reasonable for this version to retain the NULL, since it is not doing any coercion. Duncan Murdoch -- *Janko Thyson* janko.thy...@googlemail.com mailto:janko.thy...@googlemail.com Jesuitenstraße 3 D-85049 Ingolstadt Mobile: +49 (0)176 83294257 This e-mail and any attachment is for authorized use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
