5:15 p.m.
Hello,
I'm testing the feature from the section "Further use of the R library"
of the gretl guide (36.7), namely that I can define my own R functions
in a foreign block and call them later. (Which is great!) I'm struggling
with some limitations when I want to get matrices back, and I'm not sure
whether those are bugs or not. Sometimes I'm only getting the first
element of the return matrix, and sometimes there seems to be some
unwanted rounding going on.
Below are some examples (sorry a bit long, but just because it's
repetitive).
Thanks,
Sven
<hansl>
set R_functions on
# matrix in / matrix out (or scalar in /scalar out)
foreign language=R
check1 <- function(x) {
options(digits=10)
return(x)
}
end foreign
# scalar in / matrix out (or matrix in / matrix out)
foreign language=R
check2 <- function(x) {
options(digits=10)
z <- c(x, x)
return(z)
}
end foreign
# both scalar and matrix in / matrix out
foreign language=R
check3 <- function(x, y) {
options(digits=10)
z <- c(x, y)
return(z)
}
end foreign
### calls from hansl
scalar ins = 10
matrix inm = {123456.9, 0}
matrix heym = R.check1(inm) # works
eval heym
scalar heys = R.check1(ins) # works
eval heys
matrix hus = R.check2(ins) # fails
eval hus
matrix hum = R.check2(inm) # fails
eval hum
matrix ouf = R.check3(ins, inm) # fails
eval ouf
## for comparison:
foreign language=R
options(digits=10)
print(c( c(123456.9, 0), c(123456.9, 0) ))
end foreign
</hansl>
6 p.m.
On Thu, 20 Oct 2016, Sven Schreiber wrote:
Hello,
I'm testing the feature from the section "Further use of the R library" of
the gretl guide (36.7), namely that I can define my own R functions in a
foreign block and call them later. (Which is great!) I'm struggling with some
limitations when I want to get matrices back, and I'm not sure whether those
are bugs or not. Sometimes I'm only getting the first element of the return
matrix, and sometimes there seems to be some unwanted rounding going on.
Below are some examples (sorry a bit long, but just because it's repetitive).
Thanks,
Sven
<hansl>
set R_functions on
# matrix in / matrix out (or scalar in /scalar out)
foreign language=R
check1 <- function(x) {
options(digits=10)
return(x)
}
end foreign
# scalar in / matrix out (or matrix in / matrix out)
foreign language=R
check2 <- function(x) {
options(digits=10)
z <- c(x, x)
return(z)
}
end foreign
# both scalar and matrix in / matrix out
foreign language=R
check3 <- function(x, y) {
options(digits=10)
z <- c(x, y)
return(z)
}
end foreign
### calls from hansl
scalar ins = 10
matrix inm = {123456.9, 0}
matrix heym = R.check1(inm) # works
eval heym
scalar heys = R.check1(ins) # works
eval heys
matrix hus = R.check2(ins) # fails
eval hus
matrix hum = R.check2(inm) # fails
eval hum
matrix ouf = R.check3(ins, inm) # fails
eval ouf
The rounding is just a matter of the default number of digits shown
by gretl.
Besides that, you need to give gretl a little help with the return
types, using as.matrix() as required (an R "list" doesn't map onto a
gretl type). Here's an illustrative rewrite:
<hansl>
set R_functions on
# matrix in / matrix out (or scalar in /scalar out)
foreign language=R
check1 <- function(x) {
options(digits=10)
return(x)
}
end foreign
# scalar in / matrix out (or matrix in / matrix out)
foreign language=R
check2 <- function(x) {
options(digits=10)
z <- c(x, x)
return(as.matrix(z))
}
end foreign
# both scalar and matrix in / matrix out
foreign language=R
check3 <- function(x, y) {
options(digits=10)
z <- c(x, y)
return(as.matrix(z))
}
end foreign
set echo off
set messages off
### calls from hansl
scalar ins = 10
printf "ins = %.7g\n", ins
matrix inm = {123456.9, 0}
printf "inm:\n%13.7g\n", inm
matrix heym = R.check1(inm)
printf "heym = R.check1(inm):\n%13.7g\n", heym
scalar heys = R.check1(ins)
printf "heys = R.check1(ins) = %.7g\n", heys
matrix hus = R.check2(ins)
printf "hus = R.check2(ins):\n%13.7g\n", hus
matrix hum = R.check2(inm)
printf "hum = R.check2(inm):\n%13.7g\n", hum
matrix ouf = R.check3(ins, inm)
printf "ouf = R.check3(ins, inm):\n%13.7g\n", ouf
</hansl>
Allin
6:34 p.m.
Am 20.10.2016 um 20:00 schrieb Allin Cottrell:
Besides that, you need to give gretl a little help with the return
types, using as.matrix() as required (an R "list" doesn't map onto a
gretl type). Here's an illustrative rewrite:
Ah, excellent, thanks a lot.
In a more real-world case I immediately managed to crash gretl, though.
I'm sure it's because I'm doing foolish stuff on the R side before
giving gretl the result with "as.matrix()". One suspicion is that
perhaps R is giving me a sparse matrix which perhaps drives gretl crazy.
Anyway, as always, a crash should be avoided I guess...
thanks,
sven
7:09 p.m.
On Thu, 20 Oct 2016, Sven Schreiber wrote:
Am 20.10.2016 um 20:00 schrieb Allin Cottrell:
> Besides that, you need to give gretl a little help with the return
> types, using as.matrix() as required (an R "list" doesn't map onto a
> gretl type). Here's an illustrative rewrite:
>
Ah, excellent, thanks a lot.
In a more real-world case I immediately managed to crash gretl, though. I'm
sure it's because I'm doing foolish stuff on the R side before giving gretl
the result with "as.matrix()". One suspicion is that perhaps R is giving me a
sparse matrix which perhaps drives gretl crazy. Anyway, as always, a crash
should be avoided I guess...
Indeed. If you could send me a crasher case I'll investigate.
Allin
9:46 a.m.
Am 20.10.2016 um 21:09 schrieb Allin Cottrell:
On Thu, 20 Oct 2016, Sven Schreiber wrote:
>
> In a more real-world case I immediately managed to crash gretl,
> though. I'm sure it's because I'm doing foolish stuff on the R side
> before giving gretl the result with "as.matrix()". One suspicion is
> that perhaps R is giving me a sparse matrix which perhaps drives gretl
> crazy. Anyway, as always, a crash should be avoided I guess...
Indeed. If you could send me a crasher case I'll investigate.
Here you go (attention: crashes gretl for me on Windows in the sense of
the running gretl instance is gone):
<hansl-crash>
set R_functions on
foreign language=R
fcheck <- function() {
library(Matrix)
m3 <- sparseMatrix(c(1,2), c(2,3))
m2 <- matrix(rnorm(3))
return( as.matrix( c(m2, m3 ) ))
}
end foreign
matrix hey = R.fcheck()
</hansl-crash>
Apart from that I learned in the meantime that rbind() and cbind() in R
is a better way to glue matrices together.
Thanks,
sven
2:38 p.m.
On Fri, 21 Oct 2016, Sven Schreiber wrote:
Am 20.10.2016 um 21:09 schrieb Allin Cottrell:
> On Thu, 20 Oct 2016, Sven Schreiber wrote:
>> In a more real-world case I immediately managed to crash gretl,
>> though. I'm sure it's because I'm doing foolish stuff on the R side
>> before giving gretl the result with "as.matrix()". One suspicion is
>> that perhaps R is giving me a sparse matrix which perhaps drives gretl
>> crazy. Anyway, as always, a crash should be avoided I guess...
>
> Indeed. If you could send me a crasher case I'll investigate.
>
Here you go (attention: crashes gretl for me on Windows in the sense of the
running gretl instance is gone):
<hansl-crash>
set R_functions on
foreign language=R
fcheck <- function() {
library(Matrix)
m3 <- sparseMatrix(c(1,2), c(2,3))
m2 <- matrix(rnorm(3))
return( as.matrix( c(m2, m3 ) ))
}
end foreign
matrix hey = R.fcheck()
</hansl-crash>
Apart from that I learned in the meantime that rbind() and cbind()
in R is a better way to glue matrices together.
The crash is occurring in libR, when we try to extract "real" values
from the object returned by fcheck(). We've been assuming that if
the returned object satisfies Rf_isMatrix() -- which this object
does -- then it will be real-valued, but it seems that assumption is
not warranted. I've now put in a check for real-valuedness, and we
flag an error if that fails.
I don't know enough about R's sparse matrices to say exactly what
the 'matrix' returned by fcheck consists of, but it looks kinda
funny if you print it in R itself:
<R>
library(Matrix)
m3 <- sparseMatrix(c(1,2), c(2,3))
m2 <- matrix(rnorm(3))
m1 <- as.matrix( c(m2, m3 ) )
m1
[,1]
[1,] 0.8048351
[2,] -0.9528827
[3,] 1.42894
[4,] ?
</R>
Allin
2:52 p.m.
Am 21.10.2016 um 16:38 schrieb Allin Cottrell:
I don't know enough about R's sparse matrices to say exactly what the
'matrix' returned by fcheck consists of, but it looks kinda
funny if you print it in R itself:
m1
[,1]
[1,] 0.8048351
[2,] -0.9528827
[3,] 1.42894
[4,] ?
</R>
Well but that seems to stem from "glueing" together the two matrices
with non-matching dimensions. If you directly look at the initial sparse
matrix in R, here's what I get:
2 x 3 sparse Matrix of class "ngCMatrix"
[1,] . | .
[2,] . . |
The fact that there's missings in there is due to the incomplete
initialization, where only the locations of the non-zeros were
specified, not their values.
So if I use rbind() on a mixture of sparse and dense matrices in R, I get:
<R-sessionpart>
m3 <- sparseMatrix(c(1,2), c(2,3))
m4 <- matrix(rnorm(3), ncol=3)
rbind(m3, m4)
3 x 3 sparse Matrix of class "dgCMatrix"
[1,] . 1.0000000 .
[2,] . . 1.000000
[3,] -1.934421 -0.6477288 1.069744
</R-sessionpart>
Apparently R then automatically puts defaults (1.0) into the missing
places. The transfer to gretl then works fine.
thanks,
sven
3:03 p.m.
On Fri, 21 Oct 2016, Sven Schreiber wrote:
Am 21.10.2016 um 16:38 schrieb Allin Cottrell:
>
> I don't know enough about R's sparse matrices to say exactly what the
> 'matrix' returned by fcheck consists of, but it looks kinda
> funny if you print it in R itself:
> m1
> [,1]
> [1,] 0.8048351
> [2,] -0.9528827
> [3,] 1.42894
> [4,] ?
> </R>
Well but that seems to stem from "glueing" together the two matrices with
non-matching dimensions.
Yes: that doesn't provoke an error in R, but it's not clear to me
what the result really is.
If you directly look at the initial sparse matrix in
R, here's what I get:
2 x 3 sparse Matrix of class "ngCMatrix"
[1,] . | .
[2,] . . |
The fact that there's missings in there is due to the incomplete
initialization, where only the locations of the non-zeros were specified, not
their values.
So if I use rbind() on a mixture of sparse and dense matrices in R, I get:
<R-sessionpart>
> m3 <- sparseMatrix(c(1,2), c(2,3))
> m4 <- matrix(rnorm(3), ncol=3)
> rbind(m3, m4)
3 x 3 sparse Matrix of class "dgCMatrix"
[1,] . 1.0000000 .
[2,] . . 1.000000
[3,] -1.934421 -0.6477288 1.069744
</R-sessionpart>
Apparently R then automatically puts defaults (1.0) into the missing places.
The transfer to gretl then works fine.
Ok, that's good to know.
Allin
3:05 p.m.
Am 21.10.2016 um 17:03 schrieb Allin Cottrell:
On Fri, 21 Oct 2016, Sven Schreiber wrote:
>> m1
>> [,1]
>> [1,] 0.8048351
>> [2,] -0.9528827
>> [3,] 1.42894
>> [4,] ?
>> </R>
>
>
> Well but that seems to stem from "glueing" together the two matrices
> with non-matching dimensions.
Yes: that doesn't provoke an error in R, but it's not clear to me what
the result really is.
One of the reasons to stick with gretl!
Hehe,
Sven
4:10 p.m.
R have a native class of objects of class 'matrix':
they can only be squared
They are atomic vectors with 'dimension' attribute (2 coordinates)
Since R is an object-oriented language,
a user can specify as many new classes of data as she wants
Matrix package has many additional classes of "matrices"
It's unreal to have gretl native interface to much
classes defined in packages (about 10^4 packages in cran only)
It's more realistic to coerce some "matrix"
to a native (i. e. defined in r-base) class of objects
and only then export them
Oleh
21 жовтня 2016, 18:05:38, від "Sven Schreiber" < svetosch(a)gmx.net >:
Am 21.10.2016 um 17:03 schrieb Allin Cottrell:
On Fri, 21 Oct 2016, Sven Schreiber wrote:
>> m1
>> [,1]
>> [1,] 0.8048351
>> [2,] -0.9528827
>> [3,] 1.42894
>> [4,] ?
>> </R>
>
>
> Well but that seems to stem from "glueing" together the two matrices
> with non-matching dimensions.
Yes: that doesn't provoke an error in R, but it's not clear to me what
the result really is.
One of the reasons to stick with gretl!
Hehe,
Sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
4:53 p.m.
On Fri, 21 Oct 2016, oleg_komashko(a)ukr.net wrote:
R have a native class of objects of class 'matrix':
they can only be squared
Only rectangular, do you mean?
The matrix Sven constructed (at first) was nominally rectangular
(4 x 1), but element [4,1] (represented by "?" when printed) was
not a scalar value.
They are atomic vectors with 'dimension' attribute (2
coordinates)
Since R is an object-oriented language,
a user can specify as many new classes of data as she wants
Matrix package has many additional classes of "matrices"
It's unreal to have gretl native interface to much
classes defined in packages (about 10^4 packages in cran only)
It's more realistic to coerce some "matrix"
to a native (i. e. defined in r-base) class of objects
and only then export them
Our current test, applied before attempting to build a gretl matrix
from the SEXP (call it "res") we get from an R function is,
1) does Rf_isMatrix(res) return non-zero?
2) If so, does Rf_isReal(res) return non-zero?
where the second clause is newly added in response to Sven's
example. Only if both parts of the test pass do we try to get the
data out of the R object, using
gretl_matrix_set(m, i, j, REAL(res)[<index>]);
Do you think the above is adequate? Or if not, can you suggest a
better test?
The main goal here is not that we should be able to handle any old
object returned by an R function, but that we don't provoke an error
in libR that drags gretl down!
Allin
5:54 p.m.
Only rectangular, do you mean? -YES > The matrix Sven constructed
(at first) was nominally rectangular
(4 x 1), but element [4,1] (represented by "?" when printed) was
not a scalar value. Of 3 possibilities (scalar, vector, matrix) Gretl has 1-st and 3-rd
R has 2nd and 3rd
what looks as scalars are actually vector of length 1
There are 6 basic types of elements:
hex ->logical ->integer->double-> complex->character
Instead of error R uses types coercion:
c("a",1) will be c("a","1")
The elements coerced to the rightmost type in the chain above
Non-numerics looks like the result of types coercion
Run to see
<R
# From help to Matrix::sparseMatrix
i <- c(1,3:8); j <- c(2,9,6:10); x <- 7 * (1:7)
(A <- sparseMatrix(i, j, x = x)) ## 8 x 10 "dgCMatrix"
summary(A)
## my addition
typeof(A)
class(A)
Am = as.matrix(A)
Am
class(Am)
typeof(Am)
R>
So A is a S4-class object
My idea is coerce such objects to
usual matrices and only export
usual matrices
Am is ready to export
Our current test, applied before attempting to build a gretl matrix
from the SEXP (call it "res") we get from an R function is.
. . .
. . . .
It will take some time
I should study Rf_isMatrix() etc.
21 жовтня 2016, 19:53:30, від "Allin Cottrell" < cottrell(a)wfu.edu >:
On Fri, 21 Oct 2016, oleg_komashko(a)ukr.net wrote:
R have a native class of objects of class 'matrix':
they can only be squared
Only rectangular, do you mean?
The matrix Sven constructed (at first) was nominally rectangular
(4 x 1), but element [4,1] (represented by "?" when printed) was
not a scalar value.
They are atomic vectors with 'dimension' attribute (2
coordinates)
Since R is an object-oriented language,
a user can specify as many new classes of data as she wants
Matrix package has many additional classes of "matrices"
It's unreal to have gretl native interface to much
classes defined in packages (about 10^4 packages in cran only)
It's more realistic to coerce some "matrix"
to a native (i. e. defined in r-base) class of objects
and only then export them
Our current test, applied before attempting to build a gretl matrix
from the SEXP (call it "res") we get from an R function is,
1) does Rf_isMatrix(res) return non-zero?
2) If so, does Rf_isReal(res) return non-zero?
where the second clause is newly added in response to Sven's
example. Only if both parts of the test pass do we try to get the
data out of the R object, using
gretl_matrix_set(m, i, j, REAL(res)[<index>]);
Do you think the above is adequate? Or if not, can you suggest a
better test?
The main goal here is not that we should be able to handle any old
object returned by an R function, but that we don't provoke an error
in libR that drags gretl down!
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2737
days inactive
2738
days old
11 comments
3 participants
participants (3)
-
Allin Cottrell -
oleg_komashko＠ukr.net -
Sven Schreiber