Re: [Rd] [R] ouml in an .Rd
> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
> on Mon, 09 Jan 2006 15:27:12 -0500 writes:
PaulG> (moved from r-help) Ok, UTF-8 works on some of my
PaulG> machines and latin1 on others. If I use one I get
PaulG> failure or spurious characters when I build on the
PaulG> wrong machine. Are .Rd files suppose to work on
PaulG> different platforms when there are special
PaulG> characters,
yes, they are. That's why we have \encoding{} and \enc{}
nowadays, and the "Writing R Extensions" manual has been
documenting this for a while, currently [an excerpt:]
>> 2.10 Encoding
>> =
>>
>> `Rd' files are text files and so it is impossible to deduce the
>> encoding they are written in: ASCII, UTF-8, Latin-1, Latin-9 _etc_. So
>> the `\encoding{}' directive must be used to specify the
>> encoding: if not present the processing to HTML assumes that the file is
>> in Latin-1 (ISO-8859-1). This is used when creating the header of the
>> HTML conversion and to make a comment in the examples file. It is
>> also used to indicate to LaTeX how to process the file (see below).
>>
>>Wherever possible, avoid non-ASCII chars in `Rd' files.
>>
>>For convenience, encoding names `latin1' and `latin2' are always
>> recognized: these and `UTF-8' are likely to work fairly widely.
>>
>>
I'm a bit surprised that you haven't succeeded finding this
information in the extension manual.
After all, it's *the* R manual for package writers.
Martin
PaulG> or is this a known limitation?
(not at all)
PaulG> Paul
PaulG> Prof Brian Ripley wrote:
>> It means what it says: you need to put the actual
>> character in the file, and specify the encoding for the
>> file via \encoding. (For you, UTF-8 or latin1, I would
>> guess.)
>>
>> It's not a question of trying variations, rather of
>> following instructions.
>>
>> On Fri, 6 Jan 2006, Paul Gilbert wrote:
>>
>>> I am trying to put an ouml in an .Rd file with no
>>> success. Writing R Extensions suggests:
>>>
>>> Text which might need to be represented differently in
>>> different encodings should be marked by |\enc|,
>>> e.g. |\enc{Jöreskog}{Joreskog}| where the first argument
>>> will be used where encodings are allowed and the second
>>> should be ASCII (and is used for e.g. the text
>>> conversion).
>>>
>>> (Above may get mangled by the mail.) I have tried
>>> variations
>>>
>>> \enc{J"oreskog}{Joreskog} \enc{J\"oreskog}{Joreskog}
>>> \enc{Jo\"reskog}{Joreskog} \enc{Jo\"reskog}{Joreskog}
>>> \enc{J\"{o}reskog}{Joreskog}
>>> \enc{J\\"{o}reskog}{Joreskog}
>>> \enc{Jöoreskog}{Joreskog}
>>>
>>> all with no effect on the generated pdf file.
>>> Suggestions would be appreciated.
>>>
>>> Thanks, Paul Gilbert
>>>
>>> __
>>> R-help@stat.math.ethz.ch mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do
>>> read the posting guide!
>>> http://www.R-project.org/posting-guide.html
>>>
>>
PaulG> __
PaulG> R-devel@r-project.org mailing list
PaulG> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] eigen()
Hi I am having difficulty with eigen() on R-devel_2006-01-05.tar.gz Specifically, in R-2.2.0 I get expected behaviour: > eigen(matrix(1:100,10,10),FALSE,TRUE)$values [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i [3] -4.805412e-15+0.00e+00i 1.347691e-15+4.487511e-15i [5] 1.347691e-15-4.487511e-15i -4.269863e-16+0.00e+00i [7] 1.364748e-16+0.00e+00i -1.269735e-16+0.00e+00i [9] -1.878758e-18+5.031259e-17i -1.878758e-18-5.031259e-17i > The same command gives different results in the development version: > eigen(matrix(1:100,10,10),FALSE,TRUE)$values [1] 3.903094e-118 -3.903094e-118 -2.610848e-312 -2.995687e-313 -2.748516e-313 [6] -1.073138e-314 -1.061000e-314 -1.060998e-314 4.940656e-324 0.00e+00 > R.version() Error: attempt to apply non-function > R.version _ platform powerpc-apple-darwin8.3.0 arch powerpc os darwin8.3.0 system powerpc, darwin8.3.0 status Under development (unstable) major 2 minor 3.0 year 2006 month 01 day04 svn rev36984 language R version.string Version 2.3.0 Under development (unstable) (2006-01-04 r36984) > Note the strange magnitude of the output. [ I need this to work because one of my packages fails under R-devel ] -- Robin Hankin Uncertainty Analyst National Oceanography Centre, Southampton European Way, Southampton SO14 3ZH, UK tel 023-8059-7743 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen()
Robin Hankin <[EMAIL PROTECTED]> writes: > Hi > > I am having difficulty with eigen() on R-devel_2006-01-05.tar.gz > > Specifically, in R-2.2.0 I get expected behaviour: > > > > eigen(matrix(1:100,10,10),FALSE,TRUE)$values > [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i > [3] -4.805412e-15+0.00e+00i 1.347691e-15+4.487511e-15i > [5] 1.347691e-15-4.487511e-15i -4.269863e-16+0.00e+00i > [7] 1.364748e-16+0.00e+00i -1.269735e-16+0.00e+00i > [9] -1.878758e-18+5.031259e-17i -1.878758e-18-5.031259e-17i > > > > > The same command gives different results in the development version: > > > > eigen(matrix(1:100,10,10),FALSE,TRUE)$values > [1] 3.903094e-118 -3.903094e-118 -2.610848e-312 -2.995687e-313 > -2.748516e-313 > [6] -1.073138e-314 -1.061000e-314 -1.060998e-314 4.940656e-324 > 0.00e+00 > > R.version() > Error: attempt to apply non-function > > R.version Strange and semi-random results on SuSE 9.3 as well: > eigen(matrix(1:100,10,10))$values [1] -5.393552e+194 3.512001e-68 0.00e+00 0.00e+00 0.00e+00 [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > eigen(matrix(1:100,10,10))$values [1] 1.526259e-311 -1.041529e-311 1.181720e-313 0.00e+00 0.00e+00 [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > eigen(matrix(1:100,10,10))$values [1] -9.338774e+93 0.00e+00 0.00e+00 0.00e+00 0.00e+00 [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > eigen(matrix(1:100,10,10))$values [1] 5.4e-311+ 0.0e+00i -2.5e-311+3.7e-311i -2.5e-311-3.7e-311i [4] 2.5e-312+ 0.0e+00i -2.4e-312+ 0.0e+00i 3.2e-317+ 0.0e+00i [7] 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i [10] 0.0e+00+ 0.0e+00i -- 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 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] standardized residuals (rstandard & plot.lm) (PR#8468)
This bug is not quite fixed - the example from my original report now =
works using R-2.2.1, but
plot(Uniform, 6)
does not. The bug is due to
if (show[6]) {
ymx <- max(cook, na.rm =3D TRUE) * 1.025
g <- hatval/(1 - hatval) # Potential division by zero here #
plot(g, cook, xlim =3D c(0, max(g)), ylim =3D c(0, ymx),=20
main =3D main, xlab =3D "Leverage", ylab =3D "Cook's distance",=
=20
xaxt =3D "n", type =3D "n", ...)
...
All other values of 'which' seem to work fine. Sorry not to have checked =
this in the beta version,
Heather
>>> Prof Brian Ripley <[EMAIL PROTECTED]> 12/06/05 04:10pm >>>
Curiously, I was just looking at that, since I believe the answer =
should=20
be NaN, and some optimizing compilers/fast BLASes are not giving that.
(There's an example in reg-test-3.R.) So I think we need to return NaN=20
when hat is within rounding error of 1.
My take is that plot.lm should handle this: you will see most but not =
all=20
cases have na.rm=3DTRUE in calculating ylim, but as Inf is theoretically
impossible it has not been considered.
Note that plot.lm does not use rstandard and so needs a separate fix.
Thanks for the report
On Tue, 6 Dec 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Heather Turner
> Version: 2.2.0
> OS: Windows XP
> Submission from: (NULL) (137.205.240.44)
>
>
> Standardized residuals as calculated by rstandard.lm, rstandard.glm and =
plot.lm
> are Inf/NaN rather than zero when the un-standardized residuals are =
zero. This
> causes plot.lm to break when calculating 'ylim' for any of the plots of
> standardized residuals. Example:
>
> "occupationalStatus" <-
>structure(as.integer(c(50, 16, 12, 11, 2, 12, 0, 0, 19, 40, 35,
> 20, 8, 28, 6, 3, 26, 34, 65, 58, 12, 102, 19, =
14, 8,
> 18, 66, 110, 23, 162, 40, 32, 7, 11, 35, 40, =
25, 90,
> 21, 15, 11, 20, 88, 183, 46, 554, 158, 126, 6, =
8,
> 23,
> 64, 28, 230, 143, 91, 2, 3, 21, 32, 12, 177, =
71,
> 106)
> ), .Dim =3D as.integer(c(8, 8)), .Dimnames =3D
> structure(list(origin =3D c("1", "2", "3", "4", "5", "6", =
"7",
> "8"),
> destination =3D c("1", "2", "3", "4", "5", =
"6", "7",
> "8")), .Names =3D c("origin", "destination"))=
,
> class =3D "table")
> Diag <- as.factor(diag(1:8))
> Rscore <- scale(as.numeric(row(occupationalStatus)), scale =3D FALSE)
> Cscore <- scale(as.numeric(col(occupationalStatus)), scale =3D FALSE)
> Uniform <- glm(Freq ~ origin + destination + Diag +
> Rscore:Cscore, family =3D poisson, data =3D occupationalSta=
tus)
> residuals(Uniform)[as.logical(diag(8))] #zero/near-zero
> rstandard(Uniform)[as.logical(diag(8))] #mostly Inf/NaN
> plot(Uniform) #breaks on qqnorm plot (or any 'which' > 1)
>
> This could be fixed by replacing standardized residuals with zero where =
the hat
> value is one, e.g.
> rstandard.glm <- function (model,
>infl =3D lm.influence(model, do.coef =3D =
FALSE),
>...) {
> res <- infl$wt.res
> hat <- infl$hat
> ifelse(hat =3D=3D 1, 0, res/sqrt(summary(model)$dispersion * (1 -
> infl$hat)))
> }
> etc.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel=20
>
>
--=20
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/=20
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] eigen()
Peter Dalgaard <[EMAIL PROTECTED]> writes: > Robin Hankin <[EMAIL PROTECTED]> writes: > > > Hi > > > > I am having difficulty with eigen() on R-devel_2006-01-05.tar.gz > > > > Specifically, in R-2.2.0 I get expected behaviour: > > > > > > > eigen(matrix(1:100,10,10),FALSE,TRUE)$values > > [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i > > [3] -4.805412e-15+0.00e+00i 1.347691e-15+4.487511e-15i > > [5] 1.347691e-15-4.487511e-15i -4.269863e-16+0.00e+00i > > [7] 1.364748e-16+0.00e+00i -1.269735e-16+0.00e+00i > > [9] -1.878758e-18+5.031259e-17i -1.878758e-18-5.031259e-17i > > > > > > > > > The same command gives different results in the development version: > > > > > > > eigen(matrix(1:100,10,10),FALSE,TRUE)$values > > [1] 3.903094e-118 -3.903094e-118 -2.610848e-312 -2.995687e-313 > > -2.748516e-313 > > [6] -1.073138e-314 -1.061000e-314 -1.060998e-314 4.940656e-324 > > 0.00e+00 > > > R.version() > > Error: attempt to apply non-function > > > R.version > > Strange and semi-random results on SuSE 9.3 as well: > > > eigen(matrix(1:100,10,10))$values > [1] -5.393552e+194 3.512001e-68 0.00e+00 0.00e+00 > 0.00e+00 > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > 0.00e+00 > > eigen(matrix(1:100,10,10))$values > [1] 1.526259e-311 -1.041529e-311 1.181720e-313 0.00e+00 > 0.00e+00 > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > 0.00e+00 > > eigen(matrix(1:100,10,10))$values > [1] -9.338774e+93 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > > eigen(matrix(1:100,10,10))$values > [1] 5.4e-311+ 0.0e+00i -2.5e-311+3.7e-311i -2.5e-311-3.7e-311i > [4] 2.5e-312+ 0.0e+00i -2.4e-312+ 0.0e+00i 3.2e-317+ 0.0e+00i > [7] 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i > [10] 0.0e+00+ 0.0e+00i On closer inspection: > eigen(matrix(as.numeric(1:100),10),FALSE,TRUE) $values [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i [3] 9.895951e-15+3.370683e-15i 9.895951e-15-3.370683e-15i [5] -7.018984e-15+2.881924e-15i -7.018984e-15-2.881924e-15i [7] -7.978136e-16+2.629350e-15i -7.978136e-16-2.629350e-15i [9] 1.818143e-16+6.007106e-16i 1.818143e-16-6.007106e-16i $vectors NULL I.e. there's a bug in that eigen() doesn't check the storage mode, but there's also a simple workaround. -- 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 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen()
Peter Dalgaard wrote: > Robin Hankin <[EMAIL PROTECTED]> writes: > > >>Hi >> >>I am having difficulty with eigen() on R-devel_2006-01-05.tar.gz >> >>Specifically, in R-2.2.0 I get expected behaviour: >> >> >> > eigen(matrix(1:100,10,10),FALSE,TRUE)$values >>[1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i >>[3] -4.805412e-15+0.00e+00i 1.347691e-15+4.487511e-15i >>[5] 1.347691e-15-4.487511e-15i -4.269863e-16+0.00e+00i >>[7] 1.364748e-16+0.00e+00i -1.269735e-16+0.00e+00i >>[9] -1.878758e-18+5.031259e-17i -1.878758e-18-5.031259e-17i >> > >> >> >>The same command gives different results in the development version: >> >> >> > eigen(matrix(1:100,10,10),FALSE,TRUE)$values >>[1] 3.903094e-118 -3.903094e-118 -2.610848e-312 -2.995687e-313 >>-2.748516e-313 >>[6] -1.073138e-314 -1.061000e-314 -1.060998e-314 4.940656e-324 >>0.00e+00 >> > R.version() >>Error: attempt to apply non-function >> > R.version > > > Strange and semi-random results on SuSE 9.3 as well: > > >> eigen(matrix(1:100,10,10))$values > > [1] -5.393552e+194 3.512001e-68 0.00e+00 0.00e+00 > 0.00e+00 > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > 0.00e+00 > >> eigen(matrix(1:100,10,10))$values > > [1] 1.526259e-311 -1.041529e-311 1.181720e-313 0.00e+00 > 0.00e+00 > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > 0.00e+00 > >> eigen(matrix(1:100,10,10))$values > > [1] -9.338774e+93 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > >> eigen(matrix(1:100,10,10))$values > > [1] 5.4e-311+ 0.0e+00i -2.5e-311+3.7e-311i -2.5e-311-3.7e-311i > [4] 2.5e-312+ 0.0e+00i -2.4e-312+ 0.0e+00i 3.2e-317+ 0.0e+00i > [7] 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i > [10] 0.0e+00+ 0.0e+00i > > > Mine is closer to Robin's, but not the same (EL4 x86). > eigen(matrix(1:100,10,10))$values [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i [3] 6.292457e-16+2.785369e-15i 6.292457e-16-2.785369e-15i [5] -1.055022e-15+0.00e+00i 3.629676e-16+0.00e+00i [7] 1.356222e-16+2.682405e-16i 1.356222e-16-2.682405e-16i [9] 1.029077e-16+0.00e+00i -1.269181e-17+0.00e+00i > But surely, my matrix algebra is a bit rusty, I think this matrix is solveable analytically? Most of the eigenvalues shown are almost exactly zero, except the first two, actually, which is about 521 and -16 to the closest integer. I think the difference between mine and Robin's are rounding errors (the matrix is simple enough I expect the solution to be simple integers or easily expressible analystical expressions, so 8 e-values being zero is fine). Peter's number seems to be all 10 e-values are zero or one being a huge number! So Peter's is odd... and Peter's machine also seems to be of a different archtecture (64-bit machine)? HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen()
Hin-Tak Leung <[EMAIL PROTECTED]> writes: > Peter Dalgaard wrote: > > Robin Hankin <[EMAIL PROTECTED]> writes: > > > >>Hi > >> > >>I am having difficulty with eigen() on R-devel_2006-01-05.tar.gz > >> > >>Specifically, in R-2.2.0 I get expected behaviour: > >> > >> > >> > eigen(matrix(1:100,10,10),FALSE,TRUE)$values > >>[1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i > >>[3] -4.805412e-15+0.00e+00i 1.347691e-15+4.487511e-15i > >>[5] 1.347691e-15-4.487511e-15i -4.269863e-16+0.00e+00i > >>[7] 1.364748e-16+0.00e+00i -1.269735e-16+0.00e+00i > >>[9] -1.878758e-18+5.031259e-17i -1.878758e-18-5.031259e-17i > >> > > >> > >> > >>The same command gives different results in the development version: > >> > >> > >> > eigen(matrix(1:100,10,10),FALSE,TRUE)$values > >> [1] 3.903094e-118 -3.903094e-118 -2.610848e-312 -2.995687e-313 > >> -2.748516e-313 > >> [6] -1.073138e-314 -1.061000e-314 -1.060998e-314 4.940656e-324 > >> 0.00e+00 > >> > R.version() > >>Error: attempt to apply non-function > >> > R.version > > Strange and semi-random results on SuSE 9.3 as well: > > > >> eigen(matrix(1:100,10,10))$values > > [1] -5.393552e+194 3.512001e-68 0.00e+00 0.00e+00 > > 0.00e+00 > > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > > 0.00e+00 > > > >> eigen(matrix(1:100,10,10))$values > > [1] 1.526259e-311 -1.041529e-311 1.181720e-313 0.00e+00 > > 0.00e+00 > > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > > 0.00e+00 > > > >> eigen(matrix(1:100,10,10))$values > > [1] -9.338774e+93 0.00e+00 0.00e+00 0.00e+00 > > 0.00e+00 > > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > > > >> eigen(matrix(1:100,10,10))$values > > [1] 5.4e-311+ 0.0e+00i -2.5e-311+3.7e-311i -2.5e-311-3.7e-311i > > [4] 2.5e-312+ 0.0e+00i -2.4e-312+ 0.0e+00i 3.2e-317+ 0.0e+00i > > [7] 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i > > [10] 0.0e+00+ 0.0e+00i > > > > Mine is closer to Robin's, but not the same (EL4 x86). > > > eigen(matrix(1:100,10,10))$values > [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i > [3] 6.292457e-16+2.785369e-15i 6.292457e-16-2.785369e-15i > [5] -1.055022e-15+0.00e+00i 3.629676e-16+0.00e+00i > [7] 1.356222e-16+2.682405e-16i 1.356222e-16-2.682405e-16i > [9] 1.029077e-16+0.00e+00i -1.269181e-17+0.00e+00i > > > > But surely, my matrix algebra is a bit rusty, I think this matrix is > solveable analytically? Most of the eigenvalues shown are almost > exactly zero, except the first two, actually, which is about 521 > and -16 to the closest integer. > > I think the difference between mine and Robin's are rounding errors > (the matrix is simple enough I expect the solution to be simple integers > or easily expressible analystical expressions, so 8 e-values being zero > is fine). Peter's number seems to be all 10 e-values are zero or one > being a huge number! So Peter's is odd... and Peter's machine also > seems > to be of a different archtecture (64-bit machine)? > > HTL Notice that Robin got something completely different in _R-devel_ which is where I did my check too. In R 2.2.1 I get the expected two non-zero eigenvalues. I'm not sure whether (and how) you can work out the eigenvalues analytically, but since all columns are linear progressions, it is at least obvious that the matrix must have column rank two. -- 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 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen()
On 10 Jan 2006, at 14:14, Peter Dalgaard wrote: > >>> Strange and semi-random results on SuSE 9.3 as well: >>> >>> eigen(matrix(1:100,10,10))$values >>> [1] 5.4e-311+ 0.0e+00i -2.5e-311+3.7e-311i -2.5e-311-3.7e-311i >>> [4] 2.5e-312+ 0.0e+00i -2.4e-312+ 0.0e+00i 3.2e-317+ 0.0e+00i >>> [7] 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i >>> [10] 0.0e+00+ 0.0e+00i >>> >> >> Mine is closer to Robin's, but not the same (EL4 x86). >> >>> eigen(matrix(1:100,10,10))$values >> [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i >> [3] 6.292457e-16+2.785369e-15i 6.292457e-16-2.785369e-15i >> [5] -1.055022e-15+0.00e+00i 3.629676e-16+0.00e+00i >> [7] 1.356222e-16+2.682405e-16i 1.356222e-16-2.682405e-16i >> [9] 1.029077e-16+0.00e+00i -1.269181e-17+0.00e+00i >>> >> >> But surely, my matrix algebra is a bit rusty, I think this matrix is >> solveable analytically? Most of the eigenvalues shown are almost >> exactly zero, except the first two, actually, which is about 521 >> and -16 to the closest integer. >> >> I think the difference between mine and Robin's are rounding errors >> (the matrix is simple enough I expect the solution to be simple >> integers >> or easily expressible analystical expressions, so 8 e-values being >> zero >> is fine). Peter's number seems to be all 10 e-values are zero or one >> being a huge number! So Peter's is odd... and Peter's machine also >> seems >> to be of a different archtecture (64-bit machine)? >> >> HTL > > Notice that Robin got something completely different in _R-devel_ > which is where I did my check too. In R 2.2.1 I get the expected two > non-zero eigenvalues. > > I'm not sure whether (and how) you can work out the eigenvalues > analytically, but since all columns are linear progressions, it is > at least obvious that the matrix must have column rank two. > For everyone's entertainment, here's an example where the analytic solution is known. fact 1: the first eigenvalue of a magic square is equal to its constant fact 2: the sum of the other eigenvalues of a magic square is zero fact 3: the constant of a magic square of order 10 is 505. R-2.2.0: > library(magic) > round(Re(eigen(magic(10),F,T)$values)) [1] 505 170 -170 -105 105 -33000 > answers as expected. R-devel: > a <- structure(c(68, 66, 92, 90, 16, 14, 37, 38, 41, 43, 65, 67, 89, 91, 13, 15, 40, 39, 44, 42, 96, 94, 20, 18, 24, 22, 45, 46, 69, 71, 93, 95, 17, 19, 21, 23, 48, 47, 72, 70, 4, 2, 28, 26, 49, 50, 76, 74, 97, 99, 1, 3, 25, 27, 52, 51, 73, 75, 100, 98, 32, 30, 56, 54, 80, 78, 81, 82, 5, 7, 29, 31, 53, 55, 77, 79, 84, 83, 8, 6, 60, 58, 64, 62, 88, 86, 9, 10, 33, 35, 57, 59, 61, 63, 85, 87, 12, 11, 36, 34), .Dim = c(10, 10)) [no magic package! it fails R CMD check !] > round(Re(eigen(magic(10),F,T)$values)) [1] 7.544456e+165 0.00e+00 0.00e+00 0.00e+00 0.00e +00 [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e +00 > not as expected. -- Robin Hankin Uncertainty Analyst National Oceanography Centre, Southampton European Way, Southampton SO14 3ZH, UK tel 023-8059-7743 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] standardized residuals (rstandard & plot.lm) (PR#8468)
> "Heather" == Heather Turner <[EMAIL PROTECTED]> > on Tue, 10 Jan 2006 14:30:23 +0100 (CET) writes: Heather> This bug is not quite fixed - the example from my Heather> original report now = works using R-2.2.1, but Heather> plot(Uniform, 6) Heather> does not. The bug is due . g <- hatval/(1 - hatval) # Potential division by zero here plot(g, cook, xlim = c(0, max(g)), ylim = c(0, ymx), .. Heather> All other values of 'which' seem to work Heather> fine. Sorry not to have checked this in the beta Heather> version, (indeed; that would have been useful) Hmm, it's not clear what *should* be drawn in such a case. Leaving away all the observations with h_ii = 1 seems a particularly bad idea, since these are the ones that you'd definitely should remark. OTOH, for h_ii = 1, the cook distance is 'NaN' (or should that be changed; to "very large" instead ???) and plot number 6 doesn't seem to make any sense to me When 'which = 6' was proposed [ on R-devel as well, last April, http://tolstoy.newcastle.edu.au/R/devel/05/04/0595.html ah, I see, by David Firth, from your place, so, Heather, can you make sure he sees this e-mail ? ] I actually had wondered a bit about it's general usefulness,.. --- But the example is useful anyway; I think that also plot number 5, (R_i vs h_ii) does the wrong thing currently by just leaving away all points for which h_ii = 1. These really should be shown one or the other way! Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen()
I haven't seen most of this thread, but this is a classic case of passing
integers instead of doubles. And indeed
else if(is.numeric(x)) {
storage.mode(x) <- "double"
has been removed from eigen.R in R-devel in r36952. So that's the
culprit.
[BTW, x86 is not 64-bit, which is x86_64. I'd take x86 to be ix86, what
Intel calls ia32 (and AMD does call x86, given what 'i' stands for here).]
On Tue, 10 Jan 2006, Robin Hankin wrote:
>
>
> On 10 Jan 2006, at 14:14, Peter Dalgaard wrote:
>>
>
>
Strange and semi-random results on SuSE 9.3 as well:
> eigen(matrix(1:100,10,10))$values
[1] 5.4e-311+ 0.0e+00i -2.5e-311+3.7e-311i -2.5e-311-3.7e-311i
[4] 2.5e-312+ 0.0e+00i -2.4e-312+ 0.0e+00i 3.2e-317+ 0.0e+00i
[7] 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i
[10] 0.0e+00+ 0.0e+00i
>>>
>>> Mine is closer to Robin's, but not the same (EL4 x86).
>>>
eigen(matrix(1:100,10,10))$values
>>> [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i
>>> [3] 6.292457e-16+2.785369e-15i 6.292457e-16-2.785369e-15i
>>> [5] -1.055022e-15+0.00e+00i 3.629676e-16+0.00e+00i
>>> [7] 1.356222e-16+2.682405e-16i 1.356222e-16-2.682405e-16i
>>> [9] 1.029077e-16+0.00e+00i -1.269181e-17+0.00e+00i
>>>
>>> But surely, my matrix algebra is a bit rusty, I think this matrix is
>>> solveable analytically? Most of the eigenvalues shown are almost
>>> exactly zero, except the first two, actually, which is about 521
>>> and -16 to the closest integer.
>>>
>>> I think the difference between mine and Robin's are rounding errors
>>> (the matrix is simple enough I expect the solution to be simple
>>> integers
>>> or easily expressible analystical expressions, so 8 e-values being
>>> zero
>>> is fine). Peter's number seems to be all 10 e-values are zero or one
>>> being a huge number! So Peter's is odd... and Peter's machine also
>>> seems
>>> to be of a different archtecture (64-bit machine)?
>>>
>>> HTL
>>
>> Notice that Robin got something completely different in _R-devel_
>> which is where I did my check too. In R 2.2.1 I get the expected two
>> non-zero eigenvalues.
>>
>> I'm not sure whether (and how) you can work out the eigenvalues
>> analytically, but since all columns are linear progressions, it is
>> at least obvious that the matrix must have column rank two.
>>
>
>
>
>
> For everyone's entertainment, here's an example where the analytic
> solution
> is known.
>
> fact 1: the first eigenvalue of a magic square is equal to its constant
> fact 2: the sum of the other eigenvalues of a magic square is zero
> fact 3: the constant of a magic square of order 10 is 505.
>
> R-2.2.0:
>
> > library(magic)
> > round(Re(eigen(magic(10),F,T)$values))
> [1] 505 170 -170 -105 105 -33000
> >
>
> answers as expected.
>
>
> R-devel:
>
>
>
> > a <- structure(c(68, 66, 92, 90, 16, 14, 37, 38, 41, 43, 65, 67, 89,
> 91, 13, 15, 40, 39, 44, 42, 96, 94, 20, 18, 24, 22, 45, 46, 69,
> 71, 93, 95, 17, 19, 21, 23, 48, 47, 72, 70, 4, 2, 28, 26, 49,
> 50, 76, 74, 97, 99, 1, 3, 25, 27, 52, 51, 73, 75, 100, 98, 32,
> 30, 56, 54, 80, 78, 81, 82, 5, 7, 29, 31, 53, 55, 77, 79, 84,
> 83, 8, 6, 60, 58, 64, 62, 88, 86, 9, 10, 33, 35, 57, 59, 61,
> 63, 85, 87, 12, 11, 36, 34), .Dim = c(10, 10))
>
> [no magic package! it fails R CMD check !]
>
> > round(Re(eigen(magic(10),F,T)$values))
> [1] 7.544456e+165 0.00e+00 0.00e+00 0.00e+00 0.00e
> +00
> [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e
> +00
> >
>
>
> not as expected.
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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] eigen()
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> I haven't seen most of this thread, but this is a classic case of
> passing integers instead of doubles. And indeed
>
> else if(is.numeric(x)) {
> storage.mode(x) <- "double"
>
> has been removed from eigen.R in R-devel in r36952. So that's the
> culprit.
Thought as much...
> [BTW, x86 is not 64-bit, which is x86_64. I'd take x86 to be ix86,
> what Intel calls ia32 (and AMD does call x86, given what 'i' stands
> for here).]
Actually, I have
> version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status Under development (unstable)
major 2
minor 3.0
year 2006
month 01
day10
svn rev37041
language R
version.string Version 2.3.0 Under development (unstable) (2006-01-10 r37041)
Which is in fact Pentium 4 EMT (not to be confused with ia64 which is
Itanium, AFAIR).
I don't see how anyone could figure that out from the information
given, though...
-p
> On Tue, 10 Jan 2006, Robin Hankin wrote:
>
> >
> >
> > On 10 Jan 2006, at 14:14, Peter Dalgaard wrote:
> >>
> >
> >
> Strange and semi-random results on SuSE 9.3 as well:
>
>
> > eigen(matrix(1:100,10,10))$values
> [1] 5.4e-311+ 0.0e+00i -2.5e-311+3.7e-311i -2.5e-311-3.7e-311i
> [4] 2.5e-312+ 0.0e+00i -2.4e-312+ 0.0e+00i 3.2e-317+ 0.0e+00i
> [7] 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i
> [10] 0.0e+00+ 0.0e+00i
>
> >>>
> >>> Mine is closer to Robin's, but not the same (EL4 x86).
> >>>
> eigen(matrix(1:100,10,10))$values
> >>> [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i
> >>> [3] 6.292457e-16+2.785369e-15i 6.292457e-16-2.785369e-15i
> >>> [5] -1.055022e-15+0.00e+00i 3.629676e-16+0.00e+00i
> >>> [7] 1.356222e-16+2.682405e-16i 1.356222e-16-2.682405e-16i
> >>> [9] 1.029077e-16+0.00e+00i -1.269181e-17+0.00e+00i
>
> >>>
> >>> But surely, my matrix algebra is a bit rusty, I think this matrix is
> >>> solveable analytically? Most of the eigenvalues shown are almost
> >>> exactly zero, except the first two, actually, which is about 521
> >>> and -16 to the closest integer.
> >>>
> >>> I think the difference between mine and Robin's are rounding errors
> >>> (the matrix is simple enough I expect the solution to be simple
> >>> integers
> >>> or easily expressible analystical expressions, so 8 e-values being
> >>> zero
> >>> is fine). Peter's number seems to be all 10 e-values are zero or one
> >>> being a huge number! So Peter's is odd... and Peter's machine also
> >>> seems
> >>> to be of a different archtecture (64-bit machine)?
> >>>
> >>> HTL
> >>
> >> Notice that Robin got something completely different in _R-devel_
> >> which is where I did my check too. In R 2.2.1 I get the expected two
> >> non-zero eigenvalues.
> >>
> >> I'm not sure whether (and how) you can work out the eigenvalues
> >> analytically, but since all columns are linear progressions, it is
> >> at least obvious that the matrix must have column rank two.
> >>
> >
> >
> >
> >
> > For everyone's entertainment, here's an example where the analytic
> > solution
> > is known.
> >
> > fact 1: the first eigenvalue of a magic square is equal to its constant
> > fact 2: the sum of the other eigenvalues of a magic square is zero
> > fact 3: the constant of a magic square of order 10 is 505.
> >
> > R-2.2.0:
> >
> > > library(magic)
> > > round(Re(eigen(magic(10),F,T)$values))
> > [1] 505 170 -170 -105 105 -33000
> > >
> >
> > answers as expected.
> >
> >
> > R-devel:
> >
> >
> >
> > > a <- structure(c(68, 66, 92, 90, 16, 14, 37, 38, 41, 43, 65, 67, 89,
> > 91, 13, 15, 40, 39, 44, 42, 96, 94, 20, 18, 24, 22, 45, 46, 69,
> > 71, 93, 95, 17, 19, 21, 23, 48, 47, 72, 70, 4, 2, 28, 26, 49,
> > 50, 76, 74, 97, 99, 1, 3, 25, 27, 52, 51, 73, 75, 100, 98, 32,
> > 30, 56, 54, 80, 78, 81, 82, 5, 7, 29, 31, 53, 55, 77, 79, 84,
> > 83, 8, 6, 60, 58, 64, 62, 88, 86, 9, 10, 33, 35, 57, 59, 61,
> > 63, 85, 87, 12, 11, 36, 34), .Dim = c(10, 10))
> >
> > [no magic package! it fails R CMD check !]
> >
> > > round(Re(eigen(magic(10),F,T)$values))
> > [1] 7.544456e+165 0.00e+00 0.00e+00 0.00e+00 0.00e
> > +00
> > [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e
> > +00
> > >
> >
> >
> > not as expected.
> >
> >
> >
> > --
> > Robin Hankin
> > Uncertainty Analyst
> > National Oceanography Centre, Southampton
> > European Way, Southampton SO14 3ZH, UK
> > tel 023-8059-7743
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 18
Re: [Rd] standardized residuals (rstandard & plot.lm) (PR#8468)
Martin, I tend to think that points with hii = 1 are best omitted, as in almost all cases you already know about them. I've yet to hear of a better compromise. Incidentally, this is neither a case of the subject nor of 8367 which that subject line refers to. So 8367 was fixed. Brian On Tue, 10 Jan 2006 [EMAIL PROTECTED] wrote: >> "Heather" == Heather Turner <[EMAIL PROTECTED]> >> on Tue, 10 Jan 2006 14:30:23 +0100 (CET) writes: > >Heather> This bug is not quite fixed - the example from my >Heather> original report now = works using R-2.2.1, but > >Heather> plot(Uniform, 6) > >Heather> does not. The bug is due > >. > g <- hatval/(1 - hatval) # Potential division by zero here > > plot(g, cook, xlim = c(0, max(g)), ylim = c(0, ymx), > .. > >Heather> All other values of 'which' seem to work >Heather> fine. Sorry not to have checked this in the beta >Heather> version, > > (indeed; that would have been useful) > > > Hmm, it's not clear what *should* be drawn in such a > case. Leaving away all the observations with h_ii = 1 > seems a particularly bad idea, since these are the ones that > you'd definitely should remark. > OTOH, for h_ii = 1, the cook distance is 'NaN' > (or should that be changed; to "very large" instead ???) > and plot number 6 doesn't seem to make any sense to me > > When 'which = 6' was proposed > [ on R-devel as well, last April, > http://tolstoy.newcastle.edu.au/R/devel/05/04/0595.html > ah, I see, by David Firth, from your place, so, Heather, can you > make sure he sees this e-mail ? > ] > I actually had wondered a bit about it's general usefulness,.. > > --- > > But the example is useful anyway; I think that also plot > number 5, (R_i vs h_ii) does the wrong thing currently by just > leaving away all points for which h_ii = 1. > These really should be shown one or the other way! > > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] 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] eigen()
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Tue, 10 Jan 2006 15:01:00 + (GMT) writes:
BDR> I haven't seen most of this thread, but this is a classic case of
passing
BDR> integers instead of doubles. And indeed
BDR> else if(is.numeric(x)) {
BDR> storage.mode(x) <- "double"
BDR> has been removed from eigen.R in R-devel in r36952. So that's the
BDR> culprit.
and I am the culprit of that revision. I'll fix this ASAP.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Issue with c++ .C call
I am still having some difficulties with connecting R to a C++ function. I
am able to call the function as expected after compiling the shared library
and such. However, the call to the function is via .C; parameters from the
.C call are not being passed correctly to the function. As an example, I
have attached a GDB run of the code. I set a breakpoint on entry to the
function I am calling from R. What is bothering me (and probably causing
the segmentation faults I am seeing) is that the parameter
prm=as.double(c(3.2,1.1)) is not 3.2,1.1 IMMEDIATELY after the call to .C.
I am sure I am missing something very basic.
Thanks,
Sean
> sessionInfo()
R version 2.2.0, 2005-08-11, powerpc-apple-darwin7.9.0
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
holmes:~/Mercury/projects/R/StepGram sdavis$ R -d gdb
GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for
shared libraries ... done
(gdb) r
Starting program:
/Users/sdavis/R-devel2/R.framework/Versions/2.2.0/Resources/bin/exec/R
Reading symbols for shared libraries ...+ done
R : Copyright 2005, The R Foundation for Statistical Computing
Version 2.2.0 Under development (unstable) (2005-08-11 r35256)
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for a HTML browser interface to help.
Type 'q()' to quit R.
Reading symbols for shared libraries
. done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
> dyn.load('StepGram/src/Stepgram.so')
Reading symbols for shared libraries .. done
> mySG <- function(dat1,thresh,noise) {
vec <- c(thresh,noise)
.C('calcStepgram',
data=as.double(dat1),
prm=as.double(vec),
intervals=double(1*3+1),
max=as.integer(1),
n=as.integer(length(dat1)),
plot=double(length(dat1)))}
> dat <- c(0.01,0.1,-0.2, 0.1,-0.1,-1000,3.2,3.5,-1.3,3.1,
3.2,3.1,-0.1,0.2,0.15,-0.05,-0.1,0.2,0.1,-0.1)
>
Program received signal SIGINT, Interrupt.
0x9001f208 in select ()
(gdb) break calcStepgram
Breakpoint 1 at 0x10bb418: file Stepgram.cpp, line 22.
(gdb) c
Continuing.
> mySG(dat1=dat,thresh=3.2,noise=1.1)
Breakpoint 1, calcStepgram (data=0x1137048, prm=0x1c81eb0,
intervals=0xbfffd7e0, max=0x2954840, n=0xbfffd6c0, plot=0x180d574) at
Stepgram.cpp:22
(gdb) print prm[0]
$1 = 1.7716149411915527e-303<--This should be 3.2!
Current language: auto; currently c++
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with c++ .C call
Sean,
prm in your function calcStepgram is NOT a vector of doubles, it is of type
SEXP, and you need to use R macros to fetch the value(s). This is done
automatically in the Rcpp package, and if you want to see how this is
done look at the definition of the class RcppVector in Rcpp.cpp
Dominick
Sean Davis wrote:
> I am still having some difficulties with connecting R to a C++ function. I
> am able to call the function as expected after compiling the shared library
> and such. However, the call to the function is via .C; parameters from the
> .C call are not being passed correctly to the function. As an example, I
> have attached a GDB run of the code. I set a breakpoint on entry to the
> function I am calling from R. What is bothering me (and probably causing
> the segmentation faults I am seeing) is that the parameter
> prm=as.double(c(3.2,1.1)) is not 3.2,1.1 IMMEDIATELY after the call to .C.
> I am sure I am missing something very basic.
>
> Thanks,
> Sean
>
>
>
>> sessionInfo()
>>
> R version 2.2.0, 2005-08-11, powerpc-apple-darwin7.9.0
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
>
>
>
> holmes:~/Mercury/projects/R/StepGram sdavis$ R -d gdb
> GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "powerpc-apple-darwin"...Reading symbols for
> shared libraries ... done
>
> (gdb) r
> Starting program:
> /Users/sdavis/R-devel2/R.framework/Versions/2.2.0/Resources/bin/exec/R
> Reading symbols for shared libraries ...+ done
>
> R : Copyright 2005, The R Foundation for Statistical Computing
> Version 2.2.0 Under development (unstable) (2005-08-11 r35256)
> ISBN 3-900051-07-0
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for a HTML browser interface to help.
> Type 'q()' to quit R.
>
> Reading symbols for shared libraries
> . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
>
>> dyn.load('StepGram/src/Stepgram.so')
>>
> Reading symbols for shared libraries .. done
>
>> mySG <- function(dat1,thresh,noise) {
>>
> vec <- c(thresh,noise)
> .C('calcStepgram',
> data=as.double(dat1),
> prm=as.double(vec),
> intervals=double(1*3+1),
> max=as.integer(1),
> n=as.integer(length(dat1)),
> plot=double(length(dat1)))}
>
>> dat <- c(0.01,0.1,-0.2, 0.1,-0.1,-1000,3.2,3.5,-1.3,3.1,
>>
> 3.2,3.1,-0.1,0.2,0.15,-0.05,-0.1,0.2,0.1,-0.1)
>
> Program received signal SIGINT, Interrupt.
> 0x9001f208 in select ()
> (gdb) break calcStepgram
> Breakpoint 1 at 0x10bb418: file Stepgram.cpp, line 22.
> (gdb) c
> Continuing.
>
>> mySG(dat1=dat,thresh=3.2,noise=1.1)
>>
>
> Breakpoint 1, calcStepgram (data=0x1137048, prm=0x1c81eb0,
> intervals=0xbfffd7e0, max=0x2954840, n=0xbfffd6c0, plot=0x180d574) at
> Stepgram.cpp:22
> (gdb) print prm[0]
> $1 = 1.7716149411915527e-303<--This should be 3.2!
> Current language: auto; currently c++
>
> __
> 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] Issue with c++ .C call
On 1/10/06 1:33 PM, "Prof Brian Ripley" <[EMAIL PROTECTED]> wrote:
> Looks like a type mismatch in the call: you have not shown us the C++
> code.
extern "C" void calcStepgram(double *data, double *prm, double *intervals,
int *max, int *n,double *plot) {
}
> On Tue, 10 Jan 2006, Sean Davis wrote:
>
>> I am still having some difficulties with connecting R to a C++ function. I
>> am able to call the function as expected after compiling the shared library
>> and such. However, the call to the function is via .C; parameters from the
>> .C call are not being passed correctly to the function. As an example, I
>> have attached a GDB run of the code. I set a breakpoint on entry to the
>> function I am calling from R. What is bothering me (and probably causing
>> the segmentation faults I am seeing) is that the parameter
>> prm=as.double(c(3.2,1.1)) is not 3.2,1.1 IMMEDIATELY after the call to .C.
>> I am sure I am missing something very basic.
>>
>> Thanks,
>> Sean
>>
>>
>>> sessionInfo()
>> R version 2.2.0, 2005-08-11, powerpc-apple-darwin7.9.0
>>
>> attached base packages:
>> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
>> [7] "base"
>>
>>
>>
>>
>> holmes:~/Mercury/projects/R/StepGram sdavis$ R -d gdb
>> GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005)
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "powerpc-apple-darwin"...Reading symbols for
>> shared libraries ... done
>>
>> (gdb) r
>> Starting program:
>> /Users/sdavis/R-devel2/R.framework/Versions/2.2.0/Resources/bin/exec/R
>> Reading symbols for shared libraries ...+ done
>>
>> R : Copyright 2005, The R Foundation for Statistical Computing
>> Version 2.2.0 Under development (unstable) (2005-08-11 r35256)
>> ISBN 3-900051-07-0
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for a HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>> Reading symbols for shared libraries
>> . done
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries . done
>>> dyn.load('StepGram/src/Stepgram.so')
>> Reading symbols for shared libraries .. done
>>> mySG <- function(dat1,thresh,noise) {
>> vec <- c(thresh,noise)
>> .C('calcStepgram',
>> data=as.double(dat1),
>> prm=as.double(vec),
>> intervals=double(1*3+1),
>> max=as.integer(1),
>> n=as.integer(length(dat1)),
>> plot=double(length(dat1)))}
>>> dat <- c(0.01,0.1,-0.2, 0.1,-0.1,-1000,3.2,3.5,-1.3,3.1,
>> 3.2,3.1,-0.1,0.2,0.15,-0.05,-0.1,0.2,0.1,-0.1)
>>>
>> Program received signal SIGINT, Interrupt.
>> 0x9001f208 in select ()
>> (gdb) break calcStepgram
>> Breakpoint 1 at 0x10bb418: file Stepgram.cpp, line 22.
>> (gdb) c
>> Continuing.
>>> mySG(dat1=dat,thresh=3.2,noise=1.1)
>>
>> Breakpoint 1, calcStepgram (data=0x1137048, prm=0x1c81eb0,
>> intervals=0xbfffd7e0, max=0x2954840, n=0xbfffd6c0, plot=0x180d574) at
>> Stepgram.cpp:22
>> (gdb) print prm[0]
>> $1 = 1.7716149411915527e-303<--This should be 3.2!
>> Current language: auto; currently c++
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with c++ .C call
On Tue, 10 Jan 2006, Dominick Samperi wrote:
> Sean,
>
> prm in your function calcStepgram is NOT a vector of doubles, it is of type
> SEXP, and you need to use R macros to fetch the value(s). This is done
> automatically in the Rcpp package, and if you want to see how this is
> done look at the definition of the class RcppVector in Rcpp.cpp
Not at all. He is using .C, which passes a double * to the C function.
You may be thinking of .Call
-thomas
> Dominick
>
> Sean Davis wrote:
>> I am still having some difficulties with connecting R to a C++ function. I
>> am able to call the function as expected after compiling the shared library
>> and such. However, the call to the function is via .C; parameters from the
>> .C call are not being passed correctly to the function. As an example, I
>> have attached a GDB run of the code. I set a breakpoint on entry to the
>> function I am calling from R. What is bothering me (and probably causing
>> the segmentation faults I am seeing) is that the parameter
>> prm=as.double(c(3.2,1.1)) is not 3.2,1.1 IMMEDIATELY after the call to .C.
>> I am sure I am missing something very basic.
>>
>> Thanks,
>> Sean
>>
>>
>>
>>> sessionInfo()
>>>
>> R version 2.2.0, 2005-08-11, powerpc-apple-darwin7.9.0
>>
>> attached base packages:
>> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
>> [7] "base"
>>
>>
>>
>>
>> holmes:~/Mercury/projects/R/StepGram sdavis$ R -d gdb
>> GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005)
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "powerpc-apple-darwin"...Reading symbols for
>> shared libraries ... done
>>
>> (gdb) r
>> Starting program:
>> /Users/sdavis/R-devel2/R.framework/Versions/2.2.0/Resources/bin/exec/R
>> Reading symbols for shared libraries ...+ done
>>
>> R : Copyright 2005, The R Foundation for Statistical Computing
>> Version 2.2.0 Under development (unstable) (2005-08-11 r35256)
>> ISBN 3-900051-07-0
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for a HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>> Reading symbols for shared libraries
>> . done
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries . done
>>
>>> dyn.load('StepGram/src/Stepgram.so')
>>>
>> Reading symbols for shared libraries .. done
>>
>>> mySG <- function(dat1,thresh,noise) {
>>>
>> vec <- c(thresh,noise)
>> .C('calcStepgram',
>> data=as.double(dat1),
>> prm=as.double(vec),
>> intervals=double(1*3+1),
>> max=as.integer(1),
>> n=as.integer(length(dat1)),
>> plot=double(length(dat1)))}
>>
>>> dat <- c(0.01,0.1,-0.2, 0.1,-0.1,-1000,3.2,3.5,-1.3,3.1,
>>>
>> 3.2,3.1,-0.1,0.2,0.15,-0.05,-0.1,0.2,0.1,-0.1)
>>
>> Program received signal SIGINT, Interrupt.
>> 0x9001f208 in select ()
>> (gdb) break calcStepgram
>> Breakpoint 1 at 0x10bb418: file Stepgram.cpp, line 22.
>> (gdb) c
>> Continuing.
>>
>>> mySG(dat1=dat,thresh=3.2,noise=1.1)
>>>
>>
>> Breakpoint 1, calcStepgram (data=0x1137048, prm=0x1c81eb0,
>> intervals=0xbfffd7e0, max=0x2954840, n=0xbfffd6c0, plot=0x180d574) at
>> Stepgram.cpp:22
>> (gdb) print prm[0]
>> $1 = 1.7716149411915527e-303<--This should be 3.2!
>> Current language: auto; currently c++
>>
>> __
>> 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
>
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with c++ .C call
On 1/10/06 1:41 PM, "Dominick Samperi" <[EMAIL PROTECTED]> wrote:
> Sean,
>
> prm in your function calcStepgram is NOT a vector of doubles, it is of type
> SEXP, and you need to use R macros to fetch the value(s). This is done
> automatically in the Rcpp package, and if you want to see how this is
> done look at the definition of the class RcppVector in Rcpp.cpp
I'm not sure why the prm parameter is not a vector; I thought this was the
standard way to create a vector of doubles So to confuse myself even
more, I have added a simple C function that looks simply calls my C++
function like this:
extern "C" {
void mymain(double *data,double *prm, double* intervals, int* max, int *n,
double *plot) {
calcStepgram(data,prm,intervals,max,n,plot);
}
}
Then, I call this function using .C('mymain',...) as before. Note the
change in parameter memory locations from the call to mymain and the call to
calcStepgram. Why does this happen?
> dyn.load('StepGram/src/Stepgram.so')
> mySG <- function(dat1,thresh,noise) {
vec <- c(thresh,noise)
.C('mymain',
data=as.double(dat1),
prm=as.double(vec),
intervals=double(1*3+1),
max=as.integer(1),
n=as.integer(length(dat1)),
plot=double(length(dat1)))}
> dat <- c(0.01,0.1,-0.2,0.1,-0.1,-1000,3.2,3.5,-1.3,
3.1,3.2,3.1,-0.1,0.2,0.15,-0.05,-0.1,0.2,0.1,-0.1)
(gdb) break mymain
Breakpoint 1 at 0x10c13f0: file Stepgram.cpp, line 23.
(gdb) c
Continuing.
> mySG(dat1=dat,thresh=3,noise=1)
Breakpoint 1, mymain (data=0x1137148, prm=0x195cd30, intervals=0x1386018,
max=0x1b208e0, n=0x1b20900, plot=0x1137208) at Stepgram.cpp:23
23 calcStepgram(data,prm,intervals,max,n,plot);
(gdb) print prm[0]
$1 = 3
Current language: auto; currently c++
(gdb) print prm[1]
$2 = 1
(gdb) print max[0]
$3 = 1
(gdb) s
calcStepgram (data=0x1137148, prm=0x180da24, intervals=0x195cd68,
max=0x1999d6c, n=0xbfffd6e0, plot=0x0) at Stepgram.cpp:29
29 Stepgram* sg=new Stepgram(data, *n);
(gdb) print prm[0]
$4 = 2.0002441518028817
(gdb)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with c++ .C call
On Tue, 10 Jan 2006, Sean Davis wrote:
> and such. However, the call to the function is via .C; parameters from the
> .C call are not being passed correctly to the function. As an example, I
> have attached a GDB run of the code. I set a breakpoint on entry to the
> function I am calling from R. What is bothering me (and probably causing
> the segmentation faults I am seeing) is that the parameter
> prm=as.double(c(3.2,1.1)) is not 3.2,1.1 IMMEDIATELY after the call to .C.
Is this compiled with optimization? If so, you can't conclude much from
the gdb info as the code can be executed in a different order from how
it's written.
When I use this example
extern "C" void calcStepgram(double *data, double *prm, double *intervals,
int *max, int *n,double *plot) {
prm[0]=data[0];
return;
}
if I compile with -g -02 (the default) it looks as though there are
problems with initialization like the ones you report, but in fact the
function works correctly. If I compile without optimization the
initialization looks fine.
-thomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with c++ .C call
On 1/10/06 2:27 PM, "Thomas Lumley" <[EMAIL PROTECTED]> wrote:
> On Tue, 10 Jan 2006, Sean Davis wrote:
>> and such. However, the call to the function is via .C; parameters from the
>> .C call are not being passed correctly to the function. As an example, I
>> have attached a GDB run of the code. I set a breakpoint on entry to the
>> function I am calling from R. What is bothering me (and probably causing
>> the segmentation faults I am seeing) is that the parameter
>> prm=as.double(c(3.2,1.1)) is not 3.2,1.1 IMMEDIATELY after the call to .C.
>
> Is this compiled with optimization? If so, you can't conclude much from
> the gdb info as the code can be executed in a different order from how
> it's written.
>
> When I use this example
>
> extern "C" void calcStepgram(double *data, double *prm, double *intervals,
> int *max, int *n,double *plot) {
>
> prm[0]=data[0];
> return;
> }
>
> if I compile with -g -02 (the default) it looks as though there are
> problems with initialization like the ones you report, but in fact the
> function works correctly. If I compile without optimization the
> initialization looks fine.
Thanks, Thomas. That did fix the initialization issue (or apparent one).
Unfortunately, the reason that I started debugging was for segmentation
faults, which have not gone away. However, it now looks like the problem is
internal to the C++ code and not with the way the arguments were being
passed.
Back to gdb
Sean
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Interfacing with user in R
Good day everyone, I am new in R programming (my question may sound trivial to you): is there any way to ask the user to enter a string within an R process, say a filename, make R to recognise it and open the given file? It is a simple exercise in other languages. I am using R2.1.1 in a LINUX machine. Thanks for your help. Augusto Augusto Sanabria. MSc, PhD. Mathematical Modeller Risk Research Group Geospatial & Earth Monitoring Division Geoscience Australia (www.ga.gov.au) Cnr. Jerrabomberra Av. & Hindmarsh Dr. Symonston ACT 2609 Ph. (02) 6249-9155 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interfacing with user in R
On Jan 10, 2006, at 4:34 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: > I am new in R programming (my question may sound trivial to you): > is there any way to ask the user to enter a string within an R > process, say a filename, make R to recognise it and open the given > file? Sure, for reading you can use readLines. I have no idea what you mean by "recognise", but let's say if you wanted to use read.table, it would be read.table(readLines(n=1)) Of course, in R there is an even more convenient method far that ;) read.table(file.choose()) Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with c++ .C call
On Tue, 10 Jan 2006, Sean Davis wrote: > > Thanks, Thomas. That did fix the initialization issue (or apparent one). > Unfortunately, the reason that I started debugging was for segmentation > faults, which have not gone away. However, it now looks like the problem is > internal to the C++ code and not with the way the arguments were being > passed. If you can get access to a Linux machine then it's worth trying Valgrind, which is very helpful for this sort of thing. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
