Re: [Rd] rowSums, rowMean and rowCumSums?
Hi, you can compute cumsums for each row with t(apply(x, 1, cumsum)) As this is a simple, direct implementation, I see no reason to make it a named function. Cheers -Felix 2009/7/31 Christophe Dutang : > Dear list, > > Don't you think it could be useful to have in R base a function > rowCumSums, that compute cumulative sums for each row of a matrix? > > My implementation of rowCumSums is > > rowCumSums <- function(x) t(mapply(function(row)cumsum(x[row,]), > 1:NROW(x))) > > I'm sure it can be improved to have other arguments like na.rm or dims. > > Is there any hope to have this function in R? > > Christophe > > -- > Christophe Dutang > Ph.D. student at ISFA, Lyon, France > website: http://dutangc.free.fr > > > > > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 1670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Checking package on Windows (and seemingly irreproducible errors in CRAN checks)
Simon Urbanek wrote:
On Jul 30, 2009, at 7:33 , Carlos J. Gil Bellosta wrote:
Dear Uwe,
The thing that I find funny is that the check of the package on
Windows for R 2.10.x works on r-forge as you can see here:
http://r-forge.r-project.org/R/?group_id=426&log=check_x86_32_windows&pkg=colbycol&flavor=devel
May I be facing some kind of Windows configuration specific issue
here? I am sorry that I am very Windows-illiterate...
Just from the plain output I suspect that the problem is handling of
paths in the 3rd party system used (Python) is different from R's on
Windows and the package author is not converting them properly. It seems
as if Python is trying to use the path 'd:/temp/Rtmp1mB6qg/dir72ae2cd6'
literally instead of using 'd:\temp\Rtmp1mB6qg\dir72ae2cd6'. I'm a bit
surprised, because Java does the right thing:
System.out.println("'"+(new File("z:/foo/bar"))+"'"); will print
correctly 'z:\foo\bar'.
I would suspect that the difference between R-Forge and CRAN may
probably be just the setting of TMP/TEMP... [just a guess ;)]
Good idea. Unfortunately, changing d:\temp to d:/temp in my setting does
not help...
Uwe
Cheers,
Simon
This is not something that worries me much "per se", as I am
implementing some changes in the package and the new version does not
resemble the current one too much, but intrigues me quite a lot.
Best regards,
Carlos J. Gil Bellosta
http://www.datanalytics.com
2009/7/29 Uwe Ligges :
Mathieu Ribatet wrote:
Dear Carlos,
From your check results:
cbc.data <- cbc.read.table( system.file("data",
"cbc.test.data.txt", package = "colbycol"), sep = "\t" )
Warning in file(file, "r") :
cannot open file '0001': No such file or directory
I think you're trying to read the file "cbc.test.data.txt"
located
in
the folder "data" of your package skeleton. Is that right? If so, maybe
using
paste(system.file(package = "colbycol"),
"data/cbc.test.data.txt", sep="/")
will solve your issue - although I didn't try.
It won't slve it, because reading that file works, but reading file
"0001"
does ot which is handled within cbc.read.table() in the lines
for( column in names(columns) ){
tmp <- read.table( columns[[column]]$filename, sep = sep,
na.strings
= "", comment.char = "", quote = "", header = FALSE, ... )[,1]
I guess the problem happens before during the Java stuff where the
0001 file
is never created (at least not in the location you expect).
On the console I see error messages like
Exception in thread "main" Traceback (most recent call last):
File "d:/temp/colbycol/python/colbycol.py", line 6, in
os.chdir( work_dir )
File "D:\RCompile\CRANpkg\lib\2.9\rSymPy\jython\Lib\os.py", line
261, in
chdir
raise OSError(errno.ENOENT, strerror(errno.ENOENT), path)
OSError: [Errno 2] No such file or directory:
'd:/temp/Rtmp1mB6qg/dir72ae2cd6'
Best,
Uwe Ligges
__
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] Checking package on Windows (and seemingly irreproducible errors in CRAN checks)
Carlos J. Gil Bellosta wrote:
Hello,
The issue is no longer an issue concerning my package as I have
changed the part that drives the error (for unrelated reasons).
It is true that I might have done a greater effort to make the package
fully cross-platform. I did R-CMD-checks on Unbuntu and CentOS but
never on Windows. But I did install the package on Windows and
successfully run, among other, the examples that fail on CRAN servers.
What makes me curious about Windows is how can it be that the checks
pass on some machines (r-forge´s) but fail on CRAN´s. If there were
any blunt violation of cross-platform implementation practices, all
Windows checks would fail. However, some succeed.
Perhaps this is an idle intellectual exercise. But one can probably
ask himself the following two questions:
1) If I R-CMD-check my package on _my_ Windows box, how can I be sure
that the check will also succeed in other Windows box?
You cannot (same as for any other OS where some settings are different
between machines). It might also be related to the fact that my Server
runs Windows Server 2008 64bit, due to permission problems, or due to
third party requirements (Java / Phyton that are not correctly
satisfied) - which is why I asked you to specify the requirements that
makes it work under your machine.
Best,
Uwe Ligges
2) Is there any lesson to learn concerning cross-platform
implementation to learn from this case (there seems to be and I am
learning it, by the way).
Best regards and thank you for your comments on this issue.
Carlos J. Gil Bellosta
http://www.datanalytics.com
2009/7/30 Simon Urbanek :
On Jul 30, 2009, at 7:33 , Carlos J. Gil Bellosta wrote:
Dear Uwe,
The thing that I find funny is that the check of the package on
Windows for R 2.10.x works on r-forge as you can see here:
http://r-forge.r-project.org/R/?group_id=426&log=check_x86_32_windows&pkg=colbycol&flavor=devel
May I be facing some kind of Windows configuration specific issue
here? I am sorry that I am very Windows-illiterate...
Just from the plain output I suspect that the problem is handling of paths
in the 3rd party system used (Python) is different from R's on Windows and
the package author is not converting them properly. It seems as if Python is
trying to use the path 'd:/temp/Rtmp1mB6qg/dir72ae2cd6' literally instead of
using 'd:\temp\Rtmp1mB6qg\dir72ae2cd6'. I'm a bit surprised, because Java
does the right thing: System.out.println("'"+(new File("z:/foo/bar"))+"'");
will print correctly 'z:\foo\bar'.
I would suspect that the difference between R-Forge and CRAN may probably be
just the setting of TMP/TEMP... [just a guess ;)]
Cheers,
Simon
This is not something that worries me much "per se", as I am implementing
some changes in the package and the new version does not resemble the
current one too much, but intrigues me quite a lot.
Best regards,
Carlos J. Gil Bellosta
http://www.datanalytics.com
2009/7/29 Uwe Ligges :
Mathieu Ribatet wrote:
Dear Carlos,
From your check results:
cbc.data <- cbc.read.table( system.file("data",
"cbc.test.data.txt", package = "colbycol"), sep = "\t" )
Warning in file(file, "r") :
cannot open file '0001': No such file or directory
I think you're trying to read the file "cbc.test.data.txt" located
in
the folder "data" of your package skeleton. Is that right? If so, maybe
using
paste(system.file(package = "colbycol"),
"data/cbc.test.data.txt", sep="/")
will solve your issue - although I didn't try.
It won't slve it, because reading that file works, but reading file
"0001"
does ot which is handled within cbc.read.table() in the lines
for( column in names(columns) ){
tmp <- read.table( columns[[column]]$filename, sep = sep,
na.strings
= "", comment.char = "", quote = "", header = FALSE, ... )[,1]
I guess the problem happens before during the Java stuff where the 0001
file
is never created (at least not in the location you expect).
On the console I see error messages like
Exception in thread "main" Traceback (most recent call last):
File "d:/temp/colbycol/python/colbycol.py", line 6, in
os.chdir( work_dir )
File "D:\RCompile\CRANpkg\lib\2.9\rSymPy\jython\Lib\os.py", line 261, in
chdir
raise OSError(errno.ENOENT, strerror(errno.ENOENT), path)
OSError: [Errno 2] No such file or directory:
'd:/temp/Rtmp1mB6qg/dir72ae2cd6'
Best,
Uwe Ligges
__
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] update.formula and backticked colons
On Thu, Jul 30, 2009 at 2:30 PM, Sundar Dorai-Raj wrote: > On Thu, Jul 30, 2009 at 2:28 PM, Sundar Dorai-Raj wrote: >> I just noticed the following in update.formula and I'm wondering if >> this behavior is the intention of the developers. Here's an example: >> >> update(`a: b` ~ x, ~ . + y) >> >> Note now that the response has no backticks and is interpreted as a:b >> (i.e. ":" is now an operator). This is because in update.formula the >> call to terms.formula uses simplify = TRUE. I'm working with data that >> has a lot of colons in their names and for reporting purposes I don't >> want to use make.names to avoid this situation. I do have a solution >> which simply avoids using update.formula, but I wonder if the >> developers would consider removing the "simplify" argument and allow >> it to be passed through "...", which is currently ignored by >> update.formula. Alternatively, add a simplify=TRUE to the >> update.formula call, which can manually be set to FALSE by the user. >> >> I would love to hear any comments or criticisms of my findings. >> >> Thanks, >> >> --sundar >> > > Forgot my version info > >> version > _ > platform x86_64-unknown-linux-gnu > arch x86_64 > os linux-gnu > system x86_64, linux-gnu > status > major 2 > minor 9.1 > year 2009 > month 06 > day 26 > svn rev 48839 > language R > version.string R version 2.9.1 (2009-06-26) > This bounced on me so I don't know if it actually made it through. Sorry if this is a repost. --sundar __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] update.formula and backticked colons
You can always check the list archives (the ETHZ ones): it did make it. See the thread starting at https://stat.ethz.ch/pipermail/r-devel/2009-July/054184.html I need to look more carefully, but this is not what ... is documented to do and it would need to be an extra argument for this method. Since terms.formula predates backticks, perhaps the change is better made there? On Fri, 31 Jul 2009, Sundar Dorai-Raj wrote: On Thu, Jul 30, 2009 at 2:30 PM, Sundar Dorai-Raj wrote: On Thu, Jul 30, 2009 at 2:28 PM, Sundar Dorai-Raj wrote: I just noticed the following in update.formula and I'm wondering if this behavior is the intention of the developers. Here's an example: update(`a: b` ~ x, ~ . + y) Note now that the response has no backticks and is interpreted as a:b (i.e. ":" is now an operator). This is because in update.formula the call to terms.formula uses simplify = TRUE. I'm working with data that has a lot of colons in their names and for reporting purposes I don't want to use make.names to avoid this situation. I do have a solution which simply avoids using update.formula, but I wonder if the developers would consider removing the "simplify" argument and allow it to be passed through "...", which is currently ignored by update.formula. Alternatively, add a simplify=TRUE to the update.formula call, which can manually be set to FALSE by the user. I would love to hear any comments or criticisms of my findings. Thanks, --sundar Forgot my version info version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major 2 minor 9.1 year 2009 month 06 day 26 svn rev 48839 language R version.string R version 2.9.1 (2009-06-26) This bounced on me so I don't know if it actually made it through. Sorry if this is a repost. --sundar __ 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] update.formula and backticked colons
> -Original Message- > From: r-devel-boun...@r-project.org > [mailto:r-devel-boun...@r-project.org] On Behalf Of Sundar Dorai-Raj > Sent: Thursday, July 30, 2009 2:28 PM > To: r-de...@stat.math.ethz.ch > Subject: [Rd] update.formula and backticked colons > > I just noticed the following in update.formula and I'm wondering if > this behavior is the intention of the developers. Here's an example: > > update(`a: b` ~ x, ~ . + y) > > Note now that the response has no backticks and is interpreted as a:b > (i.e. ":" is now an operator). This is because in update.formula the > call to terms.formula uses simplify = TRUE. I'm working with data that > has a lot of colons in their names and for reporting purposes I don't > want to use make.names to avoid this situation. I do have a solution > which simply avoids using update.formula, but I wonder if the > developers would consider removing the "simplify" argument and allow > it to be passed through "...", which is currently ignored by > update.formula. Alternatively, add a simplify=TRUE to the > update.formula call, which can manually be set to FALSE by the user. > > I would love to hear any comments or criticisms of my findings. > > Thanks, > > --sundar It would be nice to get right of the deparse/parse cycle in terms.formula, since that often causes problems. However, I think that adding backticks=TRUE to terms.formula:fixFormulaObject's call to deparse(form[[2L]]) would fix the immediate problem. (I haven't spent much time looking for bad side effects of this change to terms.formula, which gets called in a lot of other situations.) Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] update.formula and backticked colons
> -Original Message- > From: William Dunlap > Sent: Friday, July 31, 2009 10:15 AM > To: 'Sundar Dorai-Raj'; r-de...@stat.math.ethz.ch > Subject: RE: [Rd] update.formula and backticked colons > > > -Original Message- > > From: r-devel-boun...@r-project.org > > [mailto:r-devel-boun...@r-project.org] On Behalf Of Sundar Dorai-Raj > > Sent: Thursday, July 30, 2009 2:28 PM > > To: r-de...@stat.math.ethz.ch > > Subject: [Rd] update.formula and backticked colons > > > > I just noticed the following in update.formula and I'm wondering if > > this behavior is the intention of the developers. Here's an example: > > > > update(`a: b` ~ x, ~ . + y) > > > > Note now that the response has no backticks and is > interpreted as a:b > > (i.e. ":" is now an operator). This is because in update.formula the > > call to terms.formula uses simplify = TRUE. I'm working > with data that > > has a lot of colons in their names and for reporting > purposes I don't > > want to use make.names to avoid this situation. I do have a solution > > which simply avoids using update.formula, but I wonder if the > > developers would consider removing the "simplify" argument and allow > > it to be passed through "...", which is currently ignored by > > update.formula. Alternatively, add a simplify=TRUE to the > > update.formula call, which can manually be set to FALSE by the user. > > > > I would love to hear any comments or criticisms of my findings. > > > > Thanks, > > > > --sundar > > It would be nice to get right of the deparse/parse cycle in > terms.formula, > since that often causes problems. However, I think that > adding backticks=TRUE Typo above: backtick should be singular. > to terms.formula:fixFormulaObject's call to > deparse(form[[2L]]) would fix the > immediate problem. (I haven't spent much time looking for > bad side effects > of this change to terms.formula, which gets called in a lot > of other situations.) > > Bill Dunlap > TIBCO Software Inc - Spotfire Division > wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
