[Rd] about gsoc ideas
Hi, James You have put comments on my gsoc ideas, but I have replied it lately and can I have some talk with you? My proposal is about vocal tract modeling, thanks! -- Xiang Wang Institue Of Acoustics, CAS [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tiny typo in ?prop.test: if for is
On 18/04/2010 12:53 PM, Ben Bolker wrote:
from revision 51769:
Index: prop.test.Rd
===
--- prop.test.Rd(revision 51769)
+++ prop.test.Rd(working copy)
@@ -60,7 +60,7 @@
If there is only one group, then the null tested is that the
underlying probability of success is \code{p}, or .5 if \code{p} is
- not given. The alternative is that the probability of success if less
+ not given. The alternative is that the probability of success is less
than, not equal to, or greater than \code{p} or 0.5, respectively, as
specified by \code{alternative}. A confidence interval for the
underlying proportion with confidence level as specified by
Thanks, I've fixed it.
Duncan Murdoch
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check tells me 'no visible binding for globalvariable ', what does it mean?
At 01:09 16/04/2010, mark.braving...@csiro.au wrote:
Speaking as a copious generator of CMD CHECK notes: I don't see that
there's a problem to be solved here-- i.e. I don't see why it's
worth changing good code or adding conventions just to circumvent
CMD CHECK notes. (If the code is bad, of course it should be
changed!) As the original poster said, the CMD CHECK note is only a
note, not a warning-- it's checking for *possible* problems. With
my packages, especially debug mvbutils, CHECK issues 100s of lines
of notes, which (after inspection) I don't worry about-- they
arise from RCMD CHECK not understanding my code (eg non-default
scopings), not from coding errors. I would be very unhappy at having
to add enormous amounts of explanation to the packages simply to
alleviate a non-problem!
Similarly, some compilers give notes about possibly non-initialized
variables etc, but these are often a result of the compiler not
understanding the code. I do look at them, and decide whether there
are problems that need fixing or not-- it's no big deal to ignore
them if not useful. Presumably the RCMD CHECK notes are useful to
some coders, in which case good; but nothing further really seems needed.
As the original poster can I endorse that, I was trying to improve my
understanding. I was not worried by it.
Just to follow up on the suggestions made for eliminating the note I
posted that Duncan's suggestion worked.
I think you can avoid the warning by rewriting that call to
curve() as
curve(function(x) orfun(x, exp(estimate)), from = 0.001, to =
0.999, add = TRUE)
It does remove the note but then throws an error when called
Error in xy.coords(x, y) : 'x' and 'y' lengths differ
Henrik's suggestion of setting x to a value and then removing it
works but in the light of the discussions I think I will just leave
the note in place.
Thanks to everyone for their help and suggestions
Mark
--
Mark Bravington
CSIRO Mathematical Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
l...@stat.uiowa.edu wrote:
On Mon, 12 Apr 2010, William Dunlap wrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Henrik Bengtsson
Sent: Monday, April 12, 2010 8:24 AM
To: Duncan Murdoch
Cc: r-devel; Michael Dewey
Subject: Re: [Rd] R CMD check tells me 'no visible binding for
globalvariable ', what does it mean?
On Mon, Apr 12, 2010 at 5:08 PM, Duncan Murdoch
murd...@stats.uwo.ca wrote:
On 12/04/2010 10:51 AM, Michael Dewey wrote:
When I run R CMD check on a package I have recently started work
on I get the following:
* checking R code for possible problems ... NOTE
addlinear: no visible binding for global variable 'x'
I appreciate that this is only a NOTE and so I assume is R's
equivalent of 'This is perfectly legal but I wonder whether it is
really what you intended' but I would like to understand it.
In the relevant function addlinear the following function is
defined locally:
orfun - function(x, oddsratio) {1/(1+1/(oddsratio *
(x/(1-x}
and then used later in curve
curve(orfun(x, exp(estimate)), from = 0.001, to = 0.999,
add = TRUE)
These are the only occurrences of 'x'.
Is it just telling me that I have never assigned a value to x? Or
is it more sinister than that? As far as I can tell the function
does what I intended.
The curve() function evaluates the first argument in a strange
way, and this confuses the code checking. (The variable name x
is special to curve().)
I think you can avoid the warning by rewriting that call to
curve() as
curve(function(x) orfun(x, exp(estimate)), from = 0.001, to =
0.999, add = TRUE)
...or
x - NULL; rm(x); # Dummy to trick R CMD check curve(orfun(x,
exp(estimate)), from = 0.001, to = 0.999, add = TRUE)
Or we could come up with a scheme to telling the usage checking
functions in codetools that some some or all arguments of certain
functions are evaluated in odd ways so it should not check them.
E.g., irregularUsage(curve, expr) irregularUsage(lm, subset,
formula) # subset and formula arguments of lm
irregularUsage(expression, ...) # ... arguments to expression
Perhaps one could add such indications to the NAMESPACE file or to a
new file in a package. The former is kludgy but the latter requires
changes to the packaging system.
This is done at the moment in a very ad hoc way for functions in the
core packages. I will make a note to add something for curve. This
is an interesting case, as only the variable 'x' should be viewed as
special for code analysis purposes if I understand the intent in
curve properly.
Providing a mechanism for user functions to be annotated for code
analysis might be useful, and might help in making the handling of
core package functions with special evaluation rulesa little less ad
hloc. On
[Rd] transient memory allocation and external pointers
Hello, The Writing R extensions manual section 6.1.1 describes the transient memory allocation function R_alloc, and states that memory allocated by R_alloc is automatically freed after the .C or .Call function is completed. However, based on my understanding of R's memory handling, as well as some test functions I have written, I suspect that this is not quite accurate. If the .Call function returns an external pointer to something created with R_alloc, then this object seems to stick around after the .Call function is completed, and is subject to garbage collection once the external pointer object is removed. Does anyone know, can I count on this behavior on any platform? It would certainly be useful for me. ie, Can I create an external pointer to something created with R_alloc, and trust that it will not be free'd until the external pointer object is removed? And if so, should the manual be edited to describe this behavior? Thanks, Melissa Hubisz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Syncing window plot update events during long-running evaluation
I have two source packages, one normal and another a Tcl/Tk UI for controlling the former. However, as all UI arguments are passed to a single (potentially VERY long-running) function in the normal package, all output shows up after the completion of that function. I have a sort-of workaround for updating progress on UI during this, but one issue remains consistent. Early in the process, the normal package displays a graph so the user can determine whether it is worthwhile to continue. Problem is that the plot window shows up onscreen (empty) but never fills until the everything is done, defeating its purpose; I need a means of flushing pending R graphic events. While trying to figure out how to fix this, I have noticed that executing the browser() method allows the plot window to fill prior to completion of the rest of the routine. Is there some means of triggering a pause in R execution that can be immediately resumed? Assuming browser() as a candidate, I would like to invoke it, then immediately continue (without user interaction being required to type 'cont'). I had hoped to use 'browser(expr=FALSE)' but that doesn't seem to help. Any ideas appreciated. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] utf8.def
I am trying to check my packages with R-rc and latex is failing to find utf8.def. I presume my latex installation is defective or too old, or is this file distributed with R and I just don't have a path set correctly? Paul __ * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: ! LaTeX Error: File `utf8.def' not found. Type X to quit or RETURN to proceed, or enter new name. (Default extension: def) ! Emergency stop. read * l.118 \endinput ^^M * checking PDF version of manual without index ... ERROR La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] utf8.def
On Mon, 19 Apr 2010, Paul Gilbert wrote: I am trying to check my packages with R-rc And what is that? Please do note what the posting guide says about giving accurate version information. and latex is failing to find utf8.def. I presume my latex installation is defective or too old, or is this file distributed with R and I just don't have a path set correctly? It is part of the required version of LaTeX. From the NEWS file for 2.11.0: o UTF-8 is now used for the reference manual and package manuals. This requires LaTeX '2005/12/01' or later. Paul __ * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: ! LaTeX Error: File `utf8.def' not found. Type X to quit or RETURN to proceed, or enter new name. (Default extension: def) ! Emergency stop. read * l.118 \endinput ^^M * checking PDF version of manual without index ... ERROR La version fran??aise suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le pr??sent courriel peut contenir de l'information privil??gi??e ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires d??sign??s est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer imm??diatement et envoyer sans d??lai ?? l'exp??diteur un message ??lectronique pour l'aviser que vous avez ??limin?? de votre ordinateur toute copie du courriel re??u. [[alternative HTML version deleted]] -- 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] utf8.def
-Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: April 19, 2010 11:20 AM To: Paul Gilbert Cc: r-devel@r-project.org Subject: Re: [Rd] utf8.def On Mon, 19 Apr 2010, Paul Gilbert wrote: I am trying to check my packages with R-rc And what is that? Please do note what the posting guide says about giving accurate version information. R version 2.11.0 RC (2010-04-18 r51771) and latex is failing to find utf8.def. I presume my latex installation is defective or too old, or is this file distributed with R and I just don't have a path set correctly? It is part of the required version of LaTeX. From the NEWS file for 2.11.0: o UTF-8 is now used for the reference manual and package manuals. This requires LaTeX '2005/12/01' or later. I'm a bit confused about the version numbering scheme for latex. latex --version reports TeX (Web2C 7.4.5) 3.14159 kpathsea version 3.4.5 Is that LaTeX '2005/12/01' or later? Does it make sense that R is building ok, and apparently using utf8.def according to the NEWS extract, but my packages don't find it? Thanks, Paul Paul __ * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: ! LaTeX Error: File `utf8.def' not found. Type X to quit or RETURN to proceed, or enter new name. (Default extension: def) ! Emergency stop. read * l.118 \endinput ^^M * checking PDF version of manual without index ... ERROR === = La version fran??aise suit le texte anglais. -- -- This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. -- -- Le pr??sent courriel peut contenir de l'information privil??gi??e ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires d??sign??s est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer imm??diatement et envoyer sans d??lai ?? l'exp??diteur un message ??lectronique pour l'aviser que vous avez ??limin?? de votre ordinateur toute copie du courriel re??u. [[alternative HTML version deleted]] -- 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 La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] transient memory allocation and external pointers
On Apr 19, 2010, at 10:39 AM, Melissa Jane Hubisz wrote: Hello, The Writing R extensions manual section 6.1.1 describes the transient memory allocation function R_alloc, and states that memory allocated by R_alloc is automatically freed after the .C or .Call function is completed. However, based on my understanding of R's memory handling, as well as some test functions I have written, I suspect that this is not quite accurate. If the .Call function returns an external pointer to something created with R_alloc, then this object seems to stick around after the .Call function is completed, and is subject to garbage collection once the external pointer object is removed. Yes, because the regular rules for the lifetime of an R object apply since it is in fact an R object. It is subject to garbage collection so if you assign it anywhere its lifetime will be tied to that object (in your example EXTPTRSXP). Although this is true in general (because that is the only way how it can be safely managed by the memory system), I'm not sure it is guaranteed by the API - i.e. it could be changed at any point to an arbitrary memory location which does not necessarily have that semantics. So you can decide to run with it but the fact that this is undocumented means it is not guaranteed to stay that way forever so you may need to change your code if it does. Cheers, Simon Does anyone know, can I count on this behavior on any platform? It would certainly be useful for me. ie, Can I create an external pointer to something created with R_alloc, and trust that it will not be free'd until the external pointer object is removed? And if so, should the manual be edited to describe this behavior? Thanks, Melissa Hubisz __ 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] utf8.def
On Mon, 19 Apr 2010, Paul Gilbert wrote: -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: April 19, 2010 11:20 AM To: Paul Gilbert Cc: r-devel@r-project.org Subject: Re: [Rd] utf8.def On Mon, 19 Apr 2010, Paul Gilbert wrote: I am trying to check my packages with R-rc And what is that? Please do note what the posting guide says about giving accurate version information. R version 2.11.0 RC (2010-04-18 r51771) and latex is failing to find utf8.def. I presume my latex installation is defective or too old, or is this file distributed with R and I just don't have a path set correctly? It is part of the required version of LaTeX. From the NEWS file for 2.11.0: o UTF-8 is now used for the reference manual and package manuals. This requires LaTeX '2005/12/01' or later. I'm a bit confused about the version numbering scheme for latex. latex --version reports TeX (Web2C 7.4.5) 3.14159 kpathsea version 3.4.5 Is that LaTeX '2005/12/01' or later? LaTeX is not tex, and 'latex' is a link to 'tex' usually. To get the LaTeX version, look further. E.g a LaTeX log might say **refman.tex (./refman.tex LaTeX2e 2009/09/24 (which is the current one, according to the TeXLive 2009 updater). Does it make sense that R is building ok, and apparently using utf8.def according to the NEWS extract, but my packages don't find it? Well, did you build the reference manual? It is not part of the default build (e.g. 'make pdf' is needed). -- 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] utf8.def
Thanks Brian. Yes, make pdf fails and my latex is too old (2001/06/01). Paul -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: April 19, 2010 12:14 PM To: Paul Gilbert Cc: r-devel@r-project.org Subject: RE: [Rd] utf8.def On Mon, 19 Apr 2010, Paul Gilbert wrote: -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: April 19, 2010 11:20 AM To: Paul Gilbert Cc: r-devel@r-project.org Subject: Re: [Rd] utf8.def On Mon, 19 Apr 2010, Paul Gilbert wrote: I am trying to check my packages with R-rc And what is that? Please do note what the posting guide says about giving accurate version information. R version 2.11.0 RC (2010-04-18 r51771) and latex is failing to find utf8.def. I presume my latex installation is defective or too old, or is this file distributed with R and I just don't have a path set correctly? It is part of the required version of LaTeX. From the NEWS file for 2.11.0: o UTF-8 is now used for the reference manual and package manuals. This requires LaTeX '2005/12/01' or later. I'm a bit confused about the version numbering scheme for latex. latex --version reports TeX (Web2C 7.4.5) 3.14159 kpathsea version 3.4.5 Is that LaTeX '2005/12/01' or later? LaTeX is not tex, and 'latex' is a link to 'tex' usually. To get the LaTeX version, look further. E.g a LaTeX log might say **refman.tex (./refman.tex LaTeX2e 2009/09/24 (which is the current one, according to the TeXLive 2009 updater). Does it make sense that R is building ok, and apparently using utf8.def according to the NEWS extract, but my packages don't find it? Well, did you build the reference manual? It is not part of the default build (e.g. 'make pdf' is needed). -- 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 La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lapack, determinant, multivariate normal density, solution to linear system, C language
On Mon, Apr 12, 2010 at 10:27 PM, shotwelm shotw...@musc.edu wrote:
r-devel list,
I have recently written an R package that solves a linear least squares
problem, and computes the multivariate normal density function.
For both of those applications you can use a Cholesky decomposition of
the symmetric matrix. If the Cholesky decomposition fails then you
have a singular least squares problem or a singular
variance-covariance matrix for your multivariate normal density
function.
Have you tried comparing the speed of your code to
prod(diag(chol(mm))^2
or, probably better, is to use the logarithm of the determinant
2 * sum(log(diag(chol(mm)))
If you use the Matrix package class dpoMatrix to solve the linear
system it will cache the results of the Cholesky decomposition when
solving the system so later evaluation of the determinant will be very
fast - although I suspect you would need to be working with matrices
of sizes in the hundreds or doing the same operation thousands of
times before you would notice a difference.
If you really insist on doing this in compiled code you just need to
call F77_CALL(dpotrf) then accumulate the product of the diagonal
elements of the resulting factor.
You could use packed storage but the slight advantage in memory usage
(at best, 1/2 of the full storage usage) is not worth the pain of
writing code to navigate the packed storage locations.
The bulk
of the code is written in C, with interfacing code to the BLAS and
Lapack libraries. The motivation here is speed. I ran into a problem
computing the determinant of a symmetric matrix in packed storage.
Apparently, there are no explicit routines for this as part of Lapack.
While there IS an explicit routine for this in Linpack, I did not want
to use the older library. Also, right before I needed the determinant of
the matrix A, I had used the Lapack routine dspsv to solve the linear
system Ax=b, which does much of the work of computing a determinant
also. In fact, the solution I came up with involves the output of this
routine (which might be obvious to Lapack designers, but not me)
My modest Googleing turned up very little unique material (as is typical
with BLAS/Lapack/Linpack queries). Hence, I am writing the r-devel list
partly to document the solution I've come up with, but mainly to elicit
additional wisdom from seasoned R programmers.
My solution to the problem is illustrated in the appended discussion and
C code. Thanks for your input.
-Matt Shotwell
--
The Lapack routine dspsv solves the linear system of equations Ax=b,
where A is a symmetric matrix in packed storage format. The dspsv
function performs the factorization A=UDU', where U is a unitriangular
matrix and D is a block diagonal matrix where the blocks are of
dimension 1x1 or 2x2. In addition to the solution for x, the dspsv
function also returns the matrices U and D. The matrix D may then be
used to compute the determinant of A. Recall from linear algebra that
det(A) = det(UDU') = det(U)det(D)det(U'). Since U is unitriangular,
det(U) = 1. The determinant of D is the product of the determinants of
the diagonal blocks. If a diagonal block is of dimension 1x1, then the
determinant of the block is simply the value of the single element in
the block. If the diagonal block is of dimension 2x2 then the
determinant of the block may be computed according to the well-known
formula b11*b22-b12*b21, where bij is the value in the i'th row and j'th
column of the block.
int i, q, info, *ipiv, one = 1;
double *b, *A, *D, det;
/*
** A and D are upper triangular matrices in packed storage
** A[] = a00, a01, a11, a02, a12, a22, a03, a13, a23, a33, ...
** use the following macro to address the element in the
** i'th row and j'th column for i = j
*/
#define UMAT(i, j) (i + j * ( j + 1 ) / 2)
/*
** additional code should be here
** - set q
** - allocate ipiv...
** - allocate and fill A and b...
*/
/*
** solve Ax=b using A=UDU' factorization where
** A represents a qxq matrix, b a 1xq vector.
** dspsv outputs the elements of the matrix D
** is upper triangular packed storage
** in the memory addressed by A. That is, A is
** replaced by D when dspsv returns.
*/
F77_CALL(dspsv)(U, q, one, A, ipiv, b, q, info);
if( info 0 ) { /*issue warning, system is singular*/ }
if( info 0 ) { /*issue error, invalid argument*/ }
/*
** compute the determinant det = det(A)
** if ipiv[i] 0, then D(i,i) is a 1x1 block diagonal
** if ipiv[i] = ipiv[i-1] 0, then D(i-1,i-1),
** D(i-1,i), and D(i,i) form the upper triangle
** of a 2x2 block diagonal
*/
D = A;
det = 1.0;
for( i = 0; i q; i++ ) {
if( ipiv[ i ] 0 ) {
det *= D[ UMAT(i,i) ];
} else if( i 0 ipiv[ i ] 0 ipiv[ i-1 ] == ipiv[ i ] ) {
det *= D[ UMAT(i,i) ] * D[ UMAT(i-1,i-1) ] -\
D[ UMAT(i-1,i) ] * D[ UMAT(i-1,i) ];
}
}
__
Re: [Rd] transient memory allocation and external pointers
On 4/19/10 8:59 AM, Simon Urbanek wrote:
On Apr 19, 2010, at 10:39 AM, Melissa Jane Hubisz wrote:
Hello,
The Writing R extensions manual section 6.1.1 describes the transient
memory allocation function R_alloc, and states that memory allocated
by R_alloc is automatically freed after the .C or .Call function is
completed. However, based on my understanding of R's memory handling,
as well as some test functions I have written, I suspect that this is
not quite accurate. If the .Call function returns an external pointer
to something created with R_alloc, then this object seems to stick
around after the .Call function is completed, and is subject to
garbage collection once the external pointer object is removed.
Yes, because the regular rules for the lifetime of an R object apply
since it is in fact an R object. It is subject to garbage collection
so if you assign it anywhere its lifetime will be tied to that object
(in your example EXTPTRSXP).
I may be misunderstanding the question, but I think the answer is
actually that it is *not* safe to put memory allocated via R_alloc into
the external pointer address of an EXTPTRSXP.
Here's what I think Melissa is doing:
SEXP make_test_xp(SEXP s)
{
SEXP ans;
const char *s0 = CHAR(STRING_ELT(s, 0));
char *buf = (char *)R_alloc(strlen(s0) + 1, sizeof(char));
memcpy(buf, s0, strlen(s0) + 1);
ans = R_MakeExternalPtr(buf, R_NilValue, R_NilValue);
return ans;
}
The memory allocated by R_alloc is released at the end of the .Call
via vmaxset(vmax). Using R_alloc in this way will lead to memory
corruption (it does for me when I made a simple test case).
For memory that really is external (not SEXP), then you should instead
use Calloc and register a finalizer for the external pointer that will
do any required cleanup and then call Free.
If instead you want to have an externally managed SEXP, you could put it
in the protected slot of the external pointer, but then you should
allocate it using standard R allocation functions.
+ seth
--
Seth Falcon | @sfalcon | http://userprimary.net/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Issue with aggregate.ts and/or %\% on Windows
I've stumbled across an issue with aggregate.ts that either is due to a misuse of %/% or something deeper relating to numerical precision on Windows. The test code is x - rep(6:10, 1:5) as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5)) On Linux and Mac I get the correct answer x - rep(6:10, 1:5) as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5) [1] 7.2 8.8 10.0 sessionInfo() R version 2.11.0 RC (2010-04-18 r51771) i386-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base and on Windows I get an incorrect answer x - rep(6:10, 1:5) as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5)) [1] 7.0 8.5 9.5 sessionInfo() R version 2.11.0 beta (2010-04-11 r51685) i386-pc-mingw32 locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base Walking through the aggregate.ts code I found this difference is due to what 1 %/% 0.2 produces on the different platforms. On Mac and Linux I get 1 %/% 0.2 [1] 5 and on Windows I get 1 %/% 0.2 [1] 4 I don't know if %/% supports floating point operands so I'm not sure how to report this issue, but here it is anyway. Patrick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in aggregate.ts
Hi,
I am getting unexpected behaviour from aggregate.ts(). The 'ndeltat'
argument is effectively being reduced by 1 in some cases, even when it
is an integer, with the result that the blocks to be aggregated are
not of the expected size, and also that the end() of the aggregated
series is much later than the end() of the original series.
rawts - ts(rep(1:10, each = 5), start = 1)
## ndeltat = 5, but splits into blocks of 4 rather than 5:
agts - aggregate(rawts, ndeltat = 5,
FUN = function(x) {str(x);mean(x)})
int [1:4] 1 1 1 1
int [1:4] 1 2 2 2
int [1:4] 2 2 3 3
int [1:4] 3 3 3 4
int [1:4] 4 4 4 4
int [1:4] 5 5 5 5
int [1:4] 5 6 6 6
int [1:4] 6 6 7 7
int [1:4] 7 7 7 8
int [1:4] 8 8 8 8
int [1:4] 9 9 9 9
int [1:4] 9 10 10 10
## Adding a small amount onto ndeltat bumps it up to blocks of 5:
agts2 - aggregate(rawts, ndeltat = 5 + getOption(ts.eps) / 2,
FUN = function(x) {str(x);mean(x)})
int [1:5] 1 1 1 1 1
int [1:5] 2 2 2 2 2
int [1:5] 3 3 3 3 3
int [1:5] 4 4 4 4 4
int [1:5] 5 5 5 5 5
int [1:5] 6 6 6 6 6
int [1:5] 7 7 7 7 7
int [1:5] 8 8 8 8 8
int [1:5] 9 9 9 9 9
int [1:5] 10 10 10 10 10
## Compare start / end / deltat / length for the two series.
sapply(list(`ndeltat=5` = agts, `ndeltat=5+` = agts2),
function(x) c(start = start(x)[1], end = end(x)[1],
deltat = deltat(x), length = length(x)))
#ndeltat=5 ndeltat=5+
# start 1 1.00
# end 56 46.45 ## `rawts` ends at 50
# deltat 5 5.05
# length12 10.00
sessionInfo()
R version 2.11.0 RC (2010-04-18 r51771)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
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 4670
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] bug in aggregate.ts
Sorry, I didn't notice Patrick Aboyoun's email reporting the same
issue just some minutes ago.
On 20 April 2010 10:41, Felix Andrews fe...@nfrac.org wrote:
Hi,
I am getting unexpected behaviour from aggregate.ts(). The 'ndeltat'
argument is effectively being reduced by 1 in some cases, even when it
is an integer, with the result that the blocks to be aggregated are
not of the expected size, and also that the end() of the aggregated
series is much later than the end() of the original series.
rawts - ts(rep(1:10, each = 5), start = 1)
## ndeltat = 5, but splits into blocks of 4 rather than 5:
agts - aggregate(rawts, ndeltat = 5,
FUN = function(x) {str(x);mean(x)})
int [1:4] 1 1 1 1
int [1:4] 1 2 2 2
int [1:4] 2 2 3 3
int [1:4] 3 3 3 4
int [1:4] 4 4 4 4
int [1:4] 5 5 5 5
int [1:4] 5 6 6 6
int [1:4] 6 6 7 7
int [1:4] 7 7 7 8
int [1:4] 8 8 8 8
int [1:4] 9 9 9 9
int [1:4] 9 10 10 10
## Adding a small amount onto ndeltat bumps it up to blocks of 5:
agts2 - aggregate(rawts, ndeltat = 5 + getOption(ts.eps) / 2,
FUN = function(x) {str(x);mean(x)})
int [1:5] 1 1 1 1 1
int [1:5] 2 2 2 2 2
int [1:5] 3 3 3 3 3
int [1:5] 4 4 4 4 4
int [1:5] 5 5 5 5 5
int [1:5] 6 6 6 6 6
int [1:5] 7 7 7 7 7
int [1:5] 8 8 8 8 8
int [1:5] 9 9 9 9 9
int [1:5] 10 10 10 10 10
## Compare start / end / deltat / length for the two series.
sapply(list(`ndeltat=5` = agts, `ndeltat=5+` = agts2),
function(x) c(start = start(x)[1], end = end(x)[1],
deltat = deltat(x), length = length(x)))
# ndeltat=5 ndeltat=5+
# start 1 1.00
# end 56 46.45 ## `rawts` ends at 50
# deltat 5 5.05
# length 12 10.00
sessionInfo()
R version 2.11.0 RC (2010-04-18 r51771)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
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 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
--
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 4670
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] Issue with aggregate.ts and/or %\% on Windows
Patrick Aboyoun wrote: I've stumbled across an issue with aggregate.ts that either is due to a misuse of %/% or something deeper relating to numerical precision on Windows. The test code is x - rep(6:10, 1:5) as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5)) On Linux and Mac I get the correct answer x - rep(6:10, 1:5) as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5) [1] 7.2 8.8 10.0 sessionInfo() R version 2.11.0 RC (2010-04-18 r51771) i386-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base and on Windows I get an incorrect answer x - rep(6:10, 1:5) as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5)) [1] 7.0 8.5 9.5 sessionInfo() R version 2.11.0 beta (2010-04-11 r51685) i386-pc-mingw32 locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base Walking through the aggregate.ts code I found this difference is due to what 1 %/% 0.2 produces on the different platforms. On Mac and Linux I get 1 %/% 0.2 [1] 5 and on Windows I get 1 %/% 0.2 [1] 4 I don't know if %/% supports floating point operands so I'm not sure how to report this issue, but here it is anyway. It's not as straightforward as that. I get 4 on one (32 bit) Linux, and 5 on another (64 bit). Based on samples of size one, I wouldn't want to conjecture that bitness is the root cause, but it is probably not the OS per se, rather the CPU or compiler version. It is even more insidious: I see on the SAME system 1%/%0.2 [1] 4 1/0.2==5 [1] TRUE so it isn't just the usual precision issue. Of course, exact calculations with floating-point numbers is unsafe at any speed, but this is quite peculiar. Presumably, it comes about because of intermediate storage in an extended precision register. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
