[Rd] IDWT - Inverse Discrete Wavelet Transform

[ruoccoma]

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'

[Janko Thyson]

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 

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 

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 

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

[Karl Forner]

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

[Kasper Daniel Hansen]

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'

[Duncan Murdoch]

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

[Ben Bolker]

ruoccoma  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

[Simon Urbanek]

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

[Simon Urbanek]

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

Re: [Rd] r-2.13 fails make check

[Simon Urbanek]

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'

[Janko Thyson]

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 

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.


[[alternativ

Re: [Rd] Feature request: extend functionality of 'unlist()' by args 'delim=c("/", "_", etc.)' and 'keep.special=TRUE/FALSE'

[Janko Thyson]

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 

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]]

___