[Rd] Inverting a square matrix using solve() with LAPACK=TRUE (PR#13762)
Full_Name: Ravi Varadhan
Version: 2.8.1
OS: Windows
Submission from: (NULL) (162.129.251.19)
Inverting a matrix with solve(), but using LAPACK=TRUE, gives erroneous
results:
Here is an example:
hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
h5 <- hilbert(5)
hinv1 <- solve(qr(h5))
hinv2 <- solve(qr(h5, LAPACK=TRUE))
all.equal(hinv1, hinv2) # They are not equal
Here is a function that I wrote to correct this problem:
solve.lapack <- function(A, LAPACK=TRUE, tol=1.e-07) {
# A function to invert a matrix using "LAPACK" or "LINPACK"
if (nrow(A) != ncol(A)) stop("Matrix muxt be square")
qrA <- qr(A, LAPACK=LAPACK, tol=tol)
if (LAPACK) {
apply(diag(1, ncol(A)), 2, function(x) solve(qrA, x))
} else solve(qrA)
}
hinv3 <- solve.lapack(h5)
all.equal(hinv1, hinv3) # Now, they are equal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inverting a square matrix using solve() with LAPACK=TRUE (PR#13762)
rvarad...@jhmi.edu wrote:
Full_Name: Ravi Varadhan
Version: 2.8.1
OS: Windows
Submission from: (NULL) (162.129.251.19)
Inverting a matrix with solve(), but using LAPACK=TRUE, gives erroneous
results:
Thanks, but there seems to be a much easier fix.
Inside coef.qr, we have
coef[qr$pivot, ] <-
.Call("qr_coef_real", qr, y, PACKAGE = "base")[seq_len(p)]
which should be [seq_len(p),]
(otherwise, in the matrix case, the RHS will recycle only the 1st p
elements, i.e., the 1st column).
Here is an example:
hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
h5 <- hilbert(5)
hinv1 <- solve(qr(h5))
hinv2 <- solve(qr(h5, LAPACK=TRUE))
all.equal(hinv1, hinv2) # They are not equal
Here is a function that I wrote to correct this problem:
solve.lapack <- function(A, LAPACK=TRUE, tol=1.e-07) {
# A function to invert a matrix using "LAPACK" or "LINPACK"
if (nrow(A) != ncol(A)) stop("Matrix muxt be square")
qrA <- qr(A, LAPACK=LAPACK, tol=tol)
if (LAPACK) {
apply(diag(1, ncol(A)), 2, function(x) solve(qrA, x))
} else solve(qrA)
}
hinv3 <- solve.lapack(h5)
all.equal(hinv1, hinv3) # Now, they are equal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inverting a square matrix using solve() with LAPACK=TRUE (PR#13765)
rvarad...@jhmi.edu wrote:
> Full_Name: Ravi Varadhan
> Version: 2.8.1
> OS: Windows
> Submission from: (NULL) (162.129.251.19)
>
>
> Inverting a matrix with solve(), but using LAPACK=TRUE, gives erroneous
> results:
Thanks, but there seems to be a much easier fix.
Inside coef.qr, we have
coef[qr$pivot, ] <-
.Call("qr_coef_real", qr, y, PACKAGE = "base")[seq_len(p)]
which should be [seq_len(p),]
(otherwise, in the matrix case, the RHS will recycle only the 1st p
elements, i.e., the 1st column).
>
> Here is an example:
>
> hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
> h5 <- hilbert(5)
> hinv1 <- solve(qr(h5))
> hinv2 <- solve(qr(h5, LAPACK=TRUE))
> all.equal(hinv1, hinv2) # They are not equal
>
> Here is a function that I wrote to correct this problem:
>
> solve.lapack <- function(A, LAPACK=TRUE, tol=1.e-07) {
> # A function to invert a matrix using "LAPACK" or "LINPACK"
> if (nrow(A) != ncol(A)) stop("Matrix muxt be square")
> qrA <- qr(A, LAPACK=LAPACK, tol=tol)
> if (LAPACK) {
> apply(diag(1, ncol(A)), 2, function(x) solve(qrA, x))
> } else solve(qrA)
> }
>
> hinv3 <- solve.lapack(h5)
> all.equal(hinv1, hinv3) # Now, they are equal
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inverting a square... (PR#13765)
Drats!. Jitterbug is up to its old PR renaming trick again... This should have been a followup to PR#13762. Will refile. p.dalga...@biostat.ku.dk wrote: > rvarad...@jhmi.edu wrote: >> Full_Name: Ravi Varadhan >> Version: 2.8.1 >> OS: Windows >> Submission from: (NULL) (162.129.251.19) >> >> >> Inverting a matrix with solve(), but using LAPACK=3DTRUE, gives errone= ous >> results: >=20 > Thanks, but there seems to be a much easier fix. =2E --=20 O__ Peter Dalgaard =C3=98ster Farimagsgade 5, Entr.B= c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inverting a square... (PR#13762)
Refiling this. The actual fix was slightly more complicated. Will soon
be committed to R-Patched (aka 2.9.1 beta).
-p
rvarad...@jhmi.edu wrote:
> Full_Name: Ravi Varadhan
> Version: 2.8.1
> OS: Windows
> Submission from: (NULL) (162.129.251.19)
>=20
>=20
> Inverting a matrix with solve(), but using LAPACK=3DTRUE, gives erroneo=
us
> results:
Thanks, but there seems to be a much easier fix.
Inside coef.qr, we have
coef[qr$pivot, ] <-
=2ECall("qr_coef_real", qr, y, PACKAGE =3D "base")[seq_len(p)]
which should be [seq_len(p),]
(otherwise, in the matrix case, the RHS will recycle only the 1st p
elements, i.e., the 1st column).
>=20
> Here is an example:
>=20
> hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
> h5 <- hilbert(5)
> hinv1 <- solve(qr(h5))
> hinv2 <- solve(qr(h5, LAPACK=3DTRUE))=09
> all.equal(hinv1, hinv2) # They are not equal
>=20
> Here is a function that I wrote to correct this problem:
>=20
> solve.lapack <- function(A, LAPACK=3DTRUE, tol=3D1.e-07) {
> # A function to invert a matrix using "LAPACK" or "LINPACK"
> if (nrow(A) !=3D ncol(A)) stop("Matrix muxt be square")
> qrA <- qr(A, LAPACK=3DLAPACK, tol=3Dtol)
> if (LAPACK) {
> apply(diag(1, ncol(A)), 2, function(x) solve(qrA, x))=20
> } else solve(qrA)
> }
>=20
> hinv3 <- solve.lapack(h5)
> all.equal(hinv1, hinv3) # Now, they are equal
>=20
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--=20
O__ Peter Dalgaard =C3=98ster Farimagsgade 5, Entr.B=
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Argument as.integer(NA) to a function C
Hi the list,
I am writing a R function that call a C function. The C function needs
integers but I do not manage to give a NA integer as argument :
--- C code ---
void essai(int *t){
Rprintf("\nT0=%i T1=%i T2=%i T3=%i",t[0],t[1],t[2],t[3]);
}
--- R ---
boub <- c(1,2,3,4)
.C("pour",as.integer(boub),NAOK=TRUE)
# T0=1 T1=2 T2=3 T3=4[[1]]
# [1] 1 2 3 4
boub <- c(1,2,NA,4)
.C("essai",as.integer(boub),NAOK=TRUE)
# T0=1 T1=2 T2=-2147483648 T3=4[[1]]
# [1] 1 2 NA 4
--- ---
In the second example, T2=-2147483648 and not NA.
I check the "writing R extension", there is a part that explain that the
test of NA is not the same between double and integer (NA_INTEGER,
ISNA), but I did not find explanation on passing NA argument as integer.
Any idea of what is wrong in my code?
Christophe
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Argument as.integer(NA) to a function C
On Jun 18, 2009, at 9:57 , Christophe Genolini wrote:
Hi the list,
I am writing a R function that call a C function. The C function
needs integers but I do not manage to give a NA integer as argument :
--- C code ---
void essai(int *t){
Rprintf("\nT0=%i T1=%i T2=%i T3=%i",t[0],t[1],t[2],t[3]);
}
--- R ---
boub <- c(1,2,3,4)
.C("pour",as.integer(boub),NAOK=TRUE)
# T0=1 T1=2 T2=3 T3=4[[1]]
# [1] 1 2 3 4
boub <- c(1,2,NA,4)
.C("essai",as.integer(boub),NAOK=TRUE)
# T0=1 T1=2 T2=-2147483648 T3=4[[1]]
# [1] 1 2 NA 4
--- ---
In the second example, T2=-2147483648 and not NA.
I check the "writing R extension", there is a part that explain that
the test of NA is not the same between double and integer
(NA_INTEGER, ISNA), but I did not find explanation on passing NA
argument as integer.
Any idea of what is wrong in my code?
I don't see any problem - in C there is no inherent NA, so what you
get is NA_INTEGER value which prints as -2147483648 when you print it
as integer (which is what you do in essai).
Cheers,
S
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] binding message from R CMD check
When I run R CMD check on the survival package I get one error message that I have not been able to figure out: survfitCI: no visible binding for global variable 'n.nevent' I've examined the code and can't see the problem -- the variable in question appears several times. Is there as way to find out EXACTLY what line it objects to? Terry T __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Argument as.integer(NA) to a function C
On Thu, 18 Jun 2009, Christophe Genolini wrote:
Hi the list,
I am writing a R function that call a C function. The C function needs
integers but I do not manage to give a NA integer as argument :
--- C code ---
void essai(int *t){
Rprintf("\nT0=%i T1=%i T2=%i T3=%i",t[0],t[1],t[2],t[3]);
}
--- R ---
boub <- c(1,2,3,4)
.C("pour",as.integer(boub),NAOK=TRUE)
# T0=1 T1=2 T2=3 T3=4[[1]]
# [1] 1 2 3 4
boub <- c(1,2,NA,4)
.C("essai",as.integer(boub),NAOK=TRUE)
# T0=1 T1=2 T2=-2147483648 T3=4[[1]]
# [1] 1 2 NA 4
--- ---
In the second example, T2=-2147483648 and not NA.
I check the "writing R extension", there is a part that explain that the test
of NA is not the same between double and integer (NA_INTEGER, ISNA), but I
did not find explanation on passing NA argument as integer.
Any idea of what is wrong in my code?
Simple: Rprintf does not know about NAs (and nor does printf). From
the manual:
The most useful function for printing from a C routine compiled into
R is Rprintf. This is used in exactly the same way as printf, but
is guaranteed to write to R's output (which might be a GUI console
rather than a file).
The value of NA is stored as NA_INTEGER = -2^32, and if you want your
C code to be aware of it, *you* need to program so that value is
treated specially. (Since double NAs are stored as a particular NaN,
the default C handling of doubles will probably do something sensible
but careful code will also need to take the difference between NaNs
into account.)
--
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] binding message from R CMD check
On Thu, 18 Jun 2009, Terry Therneau wrote: When I run R CMD check on the survival package I get one error message that I have not been able to figure out: survfitCI: no visible binding for global variable 'n.nevent' I've examined the code and can't see the problem -- the variable in question appears several times. Is there as way to find out EXACTLY what line it objects to? No, as it examines the parsed code (and codetools predates srcref records). But grep finds only one occurrence in survival, at gannet% grep -F n.nevent * survfitCI.S: n.event=unlist(n.nevent), Is it a typo for n.event? -- 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
[Rd] R_parseVector and syntax error [was: error messages while parsing with rniParse]
Hello, [I'm redirecting this here from stats-rosuda-devel] When parsing R code through R_parseVector and the code generates an error (syntax error), is there a way to grab the error. It looks like yyerror populates the buffer "R_ParseErrorMsg", but then the variable is not part of the public api. Would it be possible to add yet another entry point to the parser that would basically wrap R_parseVector so that it would have an extra char* argument that would bring back the error message if there is an error? Romain Simon Urbanek wrote: On Jun 15, 2009, at 12:05 , Romain Francois wrote: Hello, In JRI, is there a way to get the error message that is generated by the parser through rniParse For example, if I have this : long y = re.rniParse( "rnorm( 10 ))", 1 ) ; this obviously generates a parse error, so y will be the same as (R_NilValue) : long null_id = re.rniEval( re.rniParse( "NULL", 1 ), 0 ) ; I guess the underlying question is : "Is R_ParseErrorMsg exposed to JRI". AFAICT R_ParseErrorMsg and friends are not exposed by the R API - they are not accessible outside, so they cannot be use by JRI. It would be nice if there was a way of accessing that info, but R doesn't currently support that. Cheers, Simon The reason is I would like to bring back the message as part of an exception generated when the code does not parse. Romain -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ScalarLong?
I was surprised to see that there is a ScalarInteger function in Rinlinedfuns.h, but nothing like ScalarLong. How can one create an R-integer from a C long? TIA! kynn [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_parseVector and syntax error [was: error messages while parsing with rniParse]
Romain Francois wrote: Hello, [I'm redirecting this here from stats-rosuda-devel] When parsing R code through R_parseVector and the code generates an error (syntax error), is there a way to grab the error. It looks like yyerror populates the buffer "R_ParseErrorMsg", but then the variable is not part of the public api. Would it be possible to add yet another entry point to the parser that would basically wrap R_parseVector so that it would have an extra char* argument that would bring back the error message if there is an error? I would oppose that. Suggest ways to reduce the complexity of the parser interface and I'd be interested. It's a nightmare to make any changes there. You can always call the R function wrapped in try(), so it's not as though this would give you anything that you don't already have access to. Duncan Murdoch Romain Simon Urbanek wrote: On Jun 15, 2009, at 12:05 , Romain Francois wrote: Hello, In JRI, is there a way to get the error message that is generated by the parser through rniParse For example, if I have this : long y = re.rniParse( "rnorm( 10 ))", 1 ) ; this obviously generates a parse error, so y will be the same as (R_NilValue) : long null_id = re.rniEval( re.rniParse( "NULL", 1 ), 0 ) ; I guess the underlying question is : "Is R_ParseErrorMsg exposed to JRI". AFAICT R_ParseErrorMsg and friends are not exposed by the R API - they are not accessible outside, so they cannot be use by JRI. It would be nice if there was a way of accessing that info, but R doesn't currently support that. Cheers, Simon The reason is I would like to bring back the message as part of an exception generated when the code does not parse. Romain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_parseVector and syntax error [was: error messages while parsing with rniParse]
On Jun 18, 2009, at 17:02 , Duncan Murdoch wrote: Romain Francois wrote: Hello, [I'm redirecting this here from stats-rosuda-devel] When parsing R code through R_parseVector and the code generates an error (syntax error), is there a way to grab the error. It looks like yyerror populates the buffer "R_ParseErrorMsg", but then the variable is not part of the public api. Would it be possible to add yet another entry point to the parser that would basically wrap R_parseVector so that it would have an extra char* argument that would bring back the error message if there is an error? I would oppose that. Suggest ways to reduce the complexity of the parser interface and I'd be interested. It's a nightmare to make any changes there. You can always call the R function wrapped in try(), so it's not as though this would give you anything that you don't already have access to. I'm not quite following - we're talking about R_ParseVector in C code so the point is that the C code gets access to the error message so it can relay it to the user. There are no R-level functions involved here. The issue here for the moment is that this information is retrievable at R level but not (officially) at the C level. As for reducing complexity - technically, there is no complexity added since all this is already in place ... [adding extra char * argument to ParseVector may not be the best way but that's not what I'm arguing for]. Or am I missing something? Cheers, S Romain Simon Urbanek wrote: On Jun 15, 2009, at 12:05 , Romain Francois wrote: Hello, In JRI, is there a way to get the error message that is generated by the parser through rniParse For example, if I have this : long y = re.rniParse( "rnorm( 10 ))", 1 ) ; this obviously generates a parse error, so y will be the same as (R_NilValue) : long null_id = re.rniEval( re.rniParse( "NULL", 1 ), 0 ) ; I guess the underlying question is : "Is R_ParseErrorMsg exposed to JRI". AFAICT R_ParseErrorMsg and friends are not exposed by the R API - they are not accessible outside, so they cannot be use by JRI. It would be nice if there was a way of accessing that info, but R doesn't currently support that. Cheers, Simon The reason is I would like to bring back the message as part of an exception generated when the code does not parse. Romain __ 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] ScalarLong?
On Jun 18, 2009, at 16:34 , Kynn Jones wrote: I was surprised to see that there is a ScalarInteger function in Rinlinedfuns.h, but nothing like ScalarLong. How can one create an R-integer from a C long? There is no such thing as "long" in R (*), so one cannot make a "scalar long" vector in R. But to answer your question (how to create "R-integer" - interpreted as "integer vector of length one") it's simply ScalarInteger((int) myLong) (*) - on 32-bit systems long and int are equivalent, so the conversion is lossless, on 64-bit systems there is no way to store a "long" in R integer without loss of precision. The only lossless way on 64-bit systems is to store it in a raw vector of 8 bytes (but then there's not much you can do with it ...). For practical purposes it is usually sufficient to convert it to double (real vector in R) since you have at least guaranteed 52-bit precision (technically even more) and can perform the usual operations on it. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] validObject throws non-caught error when slot doesn't exist
I have been retooling an S4 class definition to include another slot and
have found that the methods::validObject function (defined in
methods/R/SClasses.R) in R-devel throws an error that isn't caught
internally (and thus not controllable by 'test' argument) when
retrieving a non-existent slot. The offending line of code is shown below:
> validObject
function (object, test = FALSE, complete = FALSE)
{
...
for (i in seq_along(slotTypes)) {
classi <- slotTypes[[i]]
sloti <- slot(object, slotNames[[i]]) # offending line of code
One potential patch is to substitute the offending line with
sloti <- try(slot(object, slotNames[[i]]), silent = TRUE)
if (class(sloti) == "try-error") {
errors <- c(errors, paste("missing slot \"", slotNames[[i]],
"\"", sep = ""))
next
}
Here is a reproduce and an example using vaildObject2 that substitutes
the offending line with the code given above:
> setClass("Foo", representation(bar = "character"))
[1] "Foo"
> a <- new("Foo", bar = letters)
> setClass("Foo", representation(bar = "character", star = "numeric"))
[1] "Foo"
> validObject(a, test = TRUE)
Error in slot(object, slotNames[[i]]) :
no slot of name "star" for this object of class "Foo"
> validObject2(a, test = TRUE)
[1] "missing slot \"star\""
> sessionInfo()
R version 2.10.0 Under development (unstable) (2009-06-12 r48755)
i386-apple-darwin9.6.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
Patrick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_parseVector and syntax error [was: error messages while parsing with rniParse]
Simon Urbanek wrote: On Jun 18, 2009, at 17:02 , Duncan Murdoch wrote: Romain Francois wrote: Hello, [I'm redirecting this here from stats-rosuda-devel] When parsing R code through R_parseVector and the code generates an error (syntax error), is there a way to grab the error. It looks like yyerror populates the buffer "R_ParseErrorMsg", but then the variable is not part of the public api. Would it be possible to add yet another entry point to the parser that would basically wrap R_parseVector so that it would have an extra char* argument that would bring back the error message if there is an error? I would oppose that. Suggest ways to reduce the complexity of the parser interface and I'd be interested. It's a nightmare to make any changes there. You can always call the R function wrapped in try(), so it's not as though this would give you anything that you don't already have access to. I'm not quite following - we're talking about R_ParseVector in C code so the point is that the C code gets access to the error message so it can relay it to the user. I understood that. But the C code can get the error message by evaluating an R expression and looking at the result. There are no R-level functions involved here. The issue here for the moment is that this information is retrievable at R level but not (officially) at the C level. I wouldn't mind exposing the underlying information in a clean way, but the string in R_ParseVector isn't all a front end should get. At the time of an R_ParseVector syntax error, the parser knows what token it couldn't handle, and it knows its classification, and the location in the file where it came from. Not all of that makes it through to the error message. As for reducing complexity - technically, there is no complexity added since all this is already in place ... [adding extra char * argument to ParseVector may not be the best way but that's not what I'm arguing for]. It was what I was arguing against. Duncan Murdoch Or am I missing something? Cheers, S Romain Simon Urbanek wrote: On Jun 15, 2009, at 12:05 , Romain Francois wrote: Hello, In JRI, is there a way to get the error message that is generated by the parser through rniParse For example, if I have this : long y = re.rniParse( "rnorm( 10 ))", 1 ) ; this obviously generates a parse error, so y will be the same as (R_NilValue) : long null_id = re.rniEval( re.rniParse( "NULL", 1 ), 0 ) ; I guess the underlying question is : "Is R_ParseErrorMsg exposed to JRI". AFAICT R_ParseErrorMsg and friends are not exposed by the R API - they are not accessible outside, so they cannot be use by JRI. It would be nice if there was a way of accessing that info, but R doesn't currently support that. Cheers, Simon The reason is I would like to bring back the message as part of an exception generated when the code does not parse. Romain __ 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_parseVector and syntax error [was: error messages while parsing with rniParse]
Duncan Murdoch wrote: Simon Urbanek wrote: On Jun 18, 2009, at 17:02 , Duncan Murdoch wrote: Romain Francois wrote: Hello, [I'm redirecting this here from stats-rosuda-devel] When parsing R code through R_parseVector and the code generates an error (syntax error), is there a way to grab the error. It looks like yyerror populates the buffer "R_ParseErrorMsg", but then the variable is not part of the public api. Would it be possible to add yet another entry point to the parser that would basically wrap R_parseVector so that it would have an extra char* argument that would bring back the error message if there is an error? I would oppose that. Suggest ways to reduce the complexity of the parser interface and I'd be interested. It's a nightmare to make any changes there. You can always call the R function wrapped in try(), so it's not as though this would give you anything that you don't already have access to. I'm not quite following - we're talking about R_ParseVector in C code so the point is that the C code gets access to the error message so it can relay it to the user. I understood that. But the C code can get the error message by evaluating an R expression and looking at the result. There are no R-level functions involved here. The issue here for the moment is that this information is retrievable at R level but not (officially) at the C level. I wouldn't mind exposing the underlying information in a clean way, but the string in R_ParseVector isn't all a front end should get. Great. Let's do that. Is a function that simply returns some of the static variables used by bison clean enough ? At the time of an R_ParseVector syntax error, the parser knows what token it couldn't handle, and it knows its classification, and the location in the file where it came from. Not all of that makes it through to the error message. As for reducing complexity - technically, there is no complexity added since all this is already in place ... [adding extra char * argument to ParseVector may not be the best way but that's not what I'm arguing for]. It was what I was arguing against. Duncan Murdoch Or am I missing something? Cheers, S Romain Simon Urbanek wrote: On Jun 15, 2009, at 12:05 , Romain Francois wrote: Hello, In JRI, is there a way to get the error message that is generated by the parser through rniParse For example, if I have this : long y = re.rniParse( "rnorm( 10 ))", 1 ) ; this obviously generates a parse error, so y will be the same as (R_NilValue) : long null_id = re.rniEval( re.rniParse( "NULL", 1 ), 0 ) ; I guess the underlying question is : "Is R_ParseErrorMsg exposed to JRI". AFAICT R_ParseErrorMsg and friends are not exposed by the R API - they are not accessible outside, so they cannot be use by JRI. It would be nice if there was a way of accessing that info, but R doesn't currently support that. Cheers, Simon The reason is I would like to bring back the message as part of an exception generated when the code does not parse. Romain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_parseVector and syntax error [was: error messages while parsing with rniParse]
Romain Francois wrote: Duncan Murdoch wrote: Simon Urbanek wrote: On Jun 18, 2009, at 17:02 , Duncan Murdoch wrote: Romain Francois wrote: Hello, [I'm redirecting this here from stats-rosuda-devel] When parsing R code through R_parseVector and the code generates an error (syntax error), is there a way to grab the error. It looks like yyerror populates the buffer "R_ParseErrorMsg", but then the variable is not part of the public api. Would it be possible to add yet another entry point to the parser that would basically wrap R_parseVector so that it would have an extra char* argument that would bring back the error message if there is an error? I would oppose that. Suggest ways to reduce the complexity of the parser interface and I'd be interested. It's a nightmare to make any changes there. You can always call the R function wrapped in try(), so it's not as though this would give you anything that you don't already have access to. I'm not quite following - we're talking about R_ParseVector in C code so the point is that the C code gets access to the error message so it can relay it to the user. I understood that. But the C code can get the error message by evaluating an R expression and looking at the result. There are no R-level functions involved here. The issue here for the moment is that this information is retrievable at R level but not (officially) at the C level. I wouldn't mind exposing the underlying information in a clean way, but the string in R_ParseVector isn't all a front end should get. Great. Let's do that. Is a function that simply returns some of the static variables used by bison clean enough ? It could be. I'd like a design that allows for the possibility of multiple syntax errors to be reported. I have parse_Rd doing that, though not committed yet. parse() is different because we have to be less tolerant of errors in R code than in Rd files. But we could still report multiple errors in one parse, not just stop at the first one. Duncan Murdoch At the time of an R_ParseVector syntax error, the parser knows what token it couldn't handle, and it knows its classification, and the location in the file where it came from. Not all of that makes it through to the error message. As for reducing complexity - technically, there is no complexity added since all this is already in place ... [adding extra char * argument to ParseVector may not be the best way but that's not what I'm arguing for]. It was what I was arguing against. Duncan Murdoch Or am I missing something? Cheers, S Romain Simon Urbanek wrote: On Jun 15, 2009, at 12:05 , Romain Francois wrote: Hello, In JRI, is there a way to get the error message that is generated by the parser through rniParse For example, if I have this : long y = re.rniParse( "rnorm( 10 ))", 1 ) ; this obviously generates a parse error, so y will be the same as (R_NilValue) : long null_id = re.rniEval( re.rniParse( "NULL", 1 ), 0 ) ; I guess the underlying question is : "Is R_ParseErrorMsg exposed to JRI". AFAICT R_ParseErrorMsg and friends are not exposed by the R API - they are not accessible outside, so they cannot be use by JRI. It would be nice if there was a way of accessing that info, but R doesn't currently support that. Cheers, Simon The reason is I would like to bring back the message as part of an exception generated when the code does not parse. Romain __ 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
