Re: [Rd] problem with vignettes when S4 classes in packages overlap
On Tue, 18 Sep 2012, Paul Gilbert wrote:
( A similar problem is also reported by Sebastian P. Luque with
library(maptools)
library(trip)
in the vignette as below ).
Thanks for bringing this up. This is caused by maptools avoiding: Depends:
spatstat, which might create circularities. maptools and spatstat (which
defines the classes that maptools and trip augment by adding coercion to
and from their own or sp classes) mutually Suggest: each other. trip
Depends: spatstat, but out of the box has no NAMESPACE - I haven't
investigated whether adding one helps.
Adding maptools to trip::Depends removes the warnings; check passes as
before, so no side-effects I can see. The auto-generated NAMESPACE is
then:
# Default NAMESPACE created by R
# Remove the previous line if you edit this file
# Export all names
exportPattern(".")
# Import all packages listed as Imports or Depends
import(
methods,
sp,
spatstat,
maptools
)
Since trip was last updated in May 2011, it is missing both a NAMESPACE
file, and suggestion of the correct adehabitat?? package(s) - adehabitat
is deprecated. I don't think that this is an S4 problem, I think it is
about keeping packages in sync with the R engine, especially with regard
to NAMESPACE, etc., and with packages named in DESCRIPTION. This may carry
over to the main case here, but I haven't checked.
Roger
I am writing a vignette which loads RMySQL and RPostgreSQL. This produces the
warning:
Loading required package: DBI
Warning in .simpleDuplicateClass(def, prev) :
A specification for class “dbObjectId” in package ‘RPostgreSQL’ seems
equivalent to one from package ‘RMySQL’ and is not turning on duplicate class
definitions for this class
This can be reproduced by running
R CMD Sweave --pdf Atest.Stex
where the file Atest.Stex has the lines
\documentclass{article}
\usepackage{Sweave}
\begin{document}
\begin{Scode}
library("RMySQL")
library("RPostgreSQL")
\end{Scode}
\end{document}
These warnings only happen in a vignette. They are not produced if the lines
are entered in an R session.
(Using R version 2.15.1 (2012-06-22) -- "Roasted Marshmallows" on Ubuntu)
Paul
--
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: roger.biv...@nhh.no
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rcmd check problem
Hi, all. I was trying to build my R package with R 2.15.1 32bit and win7. I basically follow the routine in Steven Mosher's blog http://stevemosher.wordpress.com/step-10-build/ After I fixed the path, and built the skeleton of the package, I started command prompt and used the following commands in building my package Rcmd check myPackageName Rcmd build myPackageName Rcmd check myPackageName.tar.gz Rcmd INSTALL --build myPackageName.tar.gz Rcmd check myPackageName.zip The last check command return me an error Rcmd check myPackageName.zip Error in rawToChar(block[seq_len(ns)]) : embedded nul in string: 'PK\003\004\n\0\0\0\0\0}?1A\0\0\0\0\0\0\0\0\0\0\0\0\f\ 0\0\0myPackageName/PK\003\004\n\0\0\0\0\0y?1A\0\0\0\0\0\0\0\0\0\0\0\0\021\0\0\0myPackageName/demo/PK\003\004\024\0\002\0\b\0y' Execution halted I do not know what it means. On the other hand, we I load myPackageName.zip as a package from the local zip file, it works. I did not get any error from my other two Rcmd check commands neither. I am wondering whether the returned error of Rcmd check means anything, and whether my package can be uploaded to CRAN without much trouble. Thanks. Best, Qi [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmd check problem
On 18/09/2012 8:55 PM, Qi Zhang wrote: Hi, all. I was trying to build my R package with R 2.15.1 32bit and win7. I basically follow the routine in Steven Mosher's blog http://stevemosher.wordpress.com/step-10-build/ After I fixed the path, and built the skeleton of the package, I started command prompt and used the following commands in building my package Rcmd check myPackageName Rcmd build myPackageName Rcmd check myPackageName.tar.gz Rcmd INSTALL --build myPackageName.tar.gz Rcmd check myPackageName.zip The check process is designed to work on source tar files, but also works (sometimes with some extra warnings) on package directories. It won't work on binary packages at all. I recommend reading the documentation. Blogs are often out of date or wrong for other reasons. (If you were following instructions there, this is an example of the latter. It has never been correct to run check on a .zip file.) Duncan Murdoch The last check command return me an error Rcmd check myPackageName.zip Error in rawToChar(block[seq_len(ns)]) : embedded nul in string: 'PK\003\004\n\0\0\0\0\0}?1A\0\0\0\0\0\0\0\0\0\0\0\0\f\ 0\0\0myPackageName/PK\003\004\n\0\0\0\0\0y?1A\0\0\0\0\0\0\0\0\0\0\0\0\021\0\0\0myPackageName/demo/PK\003\004\024\0\002\0\b\0y' Execution halted I do not know what it means. On the other hand, we I load myPackageName.zip as a package from the local zip file, it works. I did not get any error from my other two Rcmd check commands neither. I am wondering whether the returned error of Rcmd check means anything, and whether my package can be uploaded to CRAN without much trouble. Thanks. Best, Qi [[alternative HTML version deleted]] __ 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] Rcmd check problem
On 19.09.2012 02:55, Qi Zhang wrote: Hi, all. I was trying to build my R package with R 2.15.1 32bit and win7. I basically follow the routine in Steven Mosher's blog http://stevemosher.wordpress.com/step-10-build/ After I fixed the path, and built the skeleton of the package, I started command prompt and used the following commands in building my package Rcmd check myPackageName Rcmd build myPackageName Rcmd check myPackageName.tar.gz Rcmd INSTALL --build myPackageName.tar.gz Rcmd check myPackageName.zip The last check command return me an error Rcmd check myPackageName.zip You cannot run R CMD check on a binary package. Just run it on the source package. Uwe Ligges Error in rawToChar(block[seq_len(ns)]) : embedded nul in string: 'PK\003\004\n\0\0\0\0\0}?1A\0\0\0\0\0\0\0\0\0\0\0\0\f\ 0\0\0myPackageName/PK\003\004\n\0\0\0\0\0y?1A\0\0\0\0\0\0\0\0\0\0\0\0\021\0\0\0myPackageName/demo/PK\003\004\024\0\002\0\b\0y' Execution halted I do not know what it means. On the other hand, we I load myPackageName.zip as a package from the local zip file, it works. I did not get any error from my other two Rcmd check commands neither. I am wondering whether the returned error of Rcmd check means anything, and whether my package can be uploaded to CRAN without much trouble. Thanks. Best, Qi [[alternative HTML version deleted]] __ 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
[Rd] problem with vignettes when S4 classes in packages overlap
Sorry about out of date trip, I appreciate the detailed discussion here and
will fix it soon once I catch up
On Wednesday, September 19, 2012, Roger Bivand wrote:
> On Tue, 18 Sep 2012, Paul Gilbert wrote:
>
>
>> ( A similar problem is also reported by Sebastian P. Luque with
>> library(maptools)
>> library(trip)
>> in the vignette as below ).
>>
>
> Thanks for bringing this up. This is caused by maptools avoiding: Depends:
> spatstat, which might create circularities. maptools and spatstat (which
> defines the classes that maptools and trip augment by adding coercion to
> and from their own or sp classes) mutually Suggest: each other. trip
> Depends: spatstat, but out of the box has no NAMESPACE - I haven't
> investigated whether adding one helps.
>
> Adding maptools to trip::Depends removes the warnings; check passes as
> before, so no side-effects I can see. The auto-generated NAMESPACE is then:
>
> # Default NAMESPACE created by R
> # Remove the previous line if you edit this file
>
> # Export all names
> exportPattern(".")
>
> # Import all packages listed as Imports or Depends
> import(
> methods,
> sp,
> spatstat,
> maptools
> )
>
> Since trip was last updated in May 2011, it is missing both a NAMESPACE
> file, and suggestion of the correct adehabitat?? package(s) - adehabitat is
> deprecated. I don't think that this is an S4 problem, I think it is about
> keeping packages in sync with the R engine, especially with regard to
> NAMESPACE, etc., and with packages named in DESCRIPTION. This may carry
> over to the main case here, but I haven't checked.
>
> Roger
>
>
>> I am writing a vignette which loads RMySQL and RPostgreSQL. This produces
>> the warning:
>>
>> Loading required package: DBI
>> Warning in .simpleDuplicateClass(def, prev) :
>> A specification for class âdbObjectIdâ in package âRPostgreSQLâ
>> seems
>> equivalent to one from package âRMySQLâ and is not turning on duplicate
>> class definitions for this class
>>
>> This can be reproduced by running
>> R CMD Sweave --pdf Atest.Stex
>>
>> where the file Atest.Stex has the lines
>>
>> \documentclass{article}
>> \usepackage{Sweave}
>> \begin{document}
>> \begin{Scode}
>> library("RMySQL")
>> library("RPostgreSQL")
>> \end{Scode}
>> \end{document}
>>
>> These warnings only happen in a vignette. They are not produced if the
>> lines are entered in an R session.
>>
>> (Using R version 2.15.1 (2012-06-22) -- "Roasted Marshmallows" on Ubuntu)
>>
>> Paul
>>
>>
> --
> Roger Bivand
> Department of Economics, NHH Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; fax +47 55 95 95 43
> e-mail: roger.biv...@nhh.no
>
--
Michael Sumner
Hobart, Australia
e-mail: mdsum...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 115, Issue 18
In general, as a package user, I don't want people to be able to suppress checks on CRAN. I want things fixed. So I am pretty sure there won't ever be a reliable "CRAN-detector" put into R. It would devalue the brand. Duncan Murdoch My problem is that CRAN demands that I suppress a large fraction of my checks, in order to fit within time constraints. This leaves me with 3 choices. 1. Add lines to my code that tries to guess if CRAN is invoker. A cat and mouse game per your desire above. 2. Remove large portions of my test suite. I consider the survival package to be one of the pre-eminent current code sets in the world precisely because of the extensive validations, this action would change it to a second class citizen. 3. Add a magic environment variable to my local world, only do the full tests if it is present, and make the dumbed down version the default. Others who want to run the full set are then SOL, which I very much don't like. I agree that CRAN avoidence, other than the time constraint, should be verboten. But I don't think that security through obscurity is the answer. And note that under scenario 3, which is essentially what is currently being forced on us, I can do such micshief as easily as under number 1. Terry Therneau __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 115, Issue 18
On 19/09/2012 10:08 AM, Terry Therneau wrote: > In general, as a package user, I don't want people to be able to > suppress checks on CRAN. I want things fixed. > > So I am pretty sure there won't ever be a reliable "CRAN-detector" put > into R. It would devalue the brand. > > Duncan Murdoch My problem is that CRAN demands that I suppress a large fraction of my checks, in order to fit within time constraints. This leaves me with 3 choices. 1. Add lines to my code that tries to guess if CRAN is invoker. A cat and mouse game per your desire above. 2. Remove large portions of my test suite. I consider the survival package to be one of the pre-eminent current code sets in the world precisely because of the extensive validations, this action would change it to a second class citizen. 3. Add a magic environment variable to my local world, only do the full tests if it is present, and make the dumbed down version the default. Others who want to run the full set are then SOL, which I very much don't like. I agree that CRAN avoidence, other than the time constraint, should be verboten. But I don't think that security through obscurity is the answer. And note that under scenario 3, which is essentially what is currently being forced on us, I can do such micshief as easily as under number 1. Terry Therneau I understand the issue with time constraints on checks, and I think there are discussions in progress about that. My suggestion has been to put in place a way for a tester to say that checks need to be run within a tight time limit, and CRAN as tester will do that in cases where it cares about the timing. But even with the current (or past, it may have changed already) behaviour of tight limits for CRAN testing, you can put in code in your package that allows for longer tests in certain conditions. You'll run them, and if you advertise them, others will run them too. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CRAN test / avoidance
( subject changed from Re: [Rd] R-devel Digest, Vol 115, Issue 18 ) I have the impression from this, and previous discussions on the subject, that package developers and CRAN maintainers are talking at cross-purposes. Many package maintainers are thinking that they should be responsible for choosing which tests are run and which are not run by CRAN, whereas CRAN maintainers may want to run all possible tests sometimes, or a trimmed down set when time constraints demand this. With good reason, CRAN may want to run all possible tests sometimes. There are too many packages on CRAN that remain there because they don't have any testing or vignettes, and very few examples. Encouraging more of that is a bad thing. If I understand correctly, the --as-cran option was introduced to help developers specify options that CRAN uses, so they would find problems that CRAN would notice, and correct before submitting. The Rd discussions of this have morphed into a discussion of how package developers can use --as-cran to control which tests are run by CRAN. I tend to be more sympathetic with what I call the CRAN maintainer view above, even though I am a package developer. I think packages should have extensive testing and that all the tests should go in the source package on CRAN, so the testing is available for CRAN and everyone else. (Although, it is sometimes not clear if CRAN maintainers like me doing this, because they are torn between time demands and maintaining quality - that is part of the confusion.) The question becomes: how does information get passed along to indicate things that may take a long time to run. The discussion so far has focused on developers setting, or using, some flags to indicate tests and examples that take a long time. Another option would be to have the check/build process generate a file with information about the time it took to run tests, vignettes, and examples, probably with some information about the speed of the machine it was run on. Then CRAN and anyone else that wants to run tests can take this information into consideration. Paul On 12-09-19 10:08 AM, Terry Therneau wrote: In general, as a package user, I don't want people to be able to suppress checks on CRAN. I want things fixed. So I am pretty sure there won't ever be a reliable "CRAN-detector" put into R. It would devalue the brand. Duncan Murdoch My problem is that CRAN demands that I suppress a large fraction of my checks, in order to fit within time constraints. This leaves me with 3 choices. 1. Add lines to my code that tries to guess if CRAN is invoker. A cat and mouse game per your desire above. 2. Remove large portions of my test suite. I consider the survival package to be one of the pre-eminent current code sets in the world precisely because of the extensive validations, this action would change it to a second class citizen. 3. Add a magic environment variable to my local world, only do the full tests if it is present, and make the dumbed down version the default. Others who want to run the full set are then SOL, which I very much don't like. I agree that CRAN avoidence, other than the time constraint, should be verboten. But I don't think that security through obscurity is the answer. And note that under scenario 3, which is essentially what is currently being forced on us, I can do such micshief as easily as under number 1. Terry Therneau __ 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-devel Digest, Vol 115, Issue 18
On 09/19/2012 09:22 AM, Duncan Murdoch wrote: I understand the issue with time constraints on checks, and I think there are discussions in progress about that. My suggestion has been to put in place a way for a tester to say that checks need to be run within a tight time limit, and CRAN as tester will do that in cases where it cares about the timing. Sounds good. But even with the current (or past, it may have changed already) behaviour of tight limits for CRAN testing, you can put in code in your package that allows for longer tests in certain conditions. You'll run them, and if you advertise them, others will run them too. For me this applies to certain vignettes. Thanks to a pointer from K Hansen, I'm told I can handle this by putting the long one in inst/doc and the short ones in vignettes. I'll be trying this out soon. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN test / avoidance
> The question becomes: how does information get passed along to indicate > things that may take a long time to run. The discussion so far has focused > on developers setting, or using, some flags to indicate tests and examples > that take a long time. Another option would be to have the check/build > process generate a file with information about the time it took to run > tests, vignettes, and examples, probably with some information about the > speed of the machine it was run on. Then CRAN and anyone else that wants to > run tests can take this information into consideration. To paraphrase Uwe (fortunes::fortune(192)): computing is cheap and thinking hurts. I don't understand why we are spending so much time discussing what probably amounts (at most) to a couple of thousand of dollars of compute time. Hadley -- RStudio / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN test / avoidance
On 9/19/2012 11:51 AM, Hadley Wickham wrote: The question becomes: how does information get passed along to indicate things that may take a long time to run. The discussion so far has focused on developers setting, or using, some flags to indicate tests and examples that take a long time. Another option would be to have the check/build process generate a file with information about the time it took to run tests, vignettes, and examples, probably with some information about the speed of the machine it was run on. Then CRAN and anyone else that wants to run tests can take this information into consideration. To paraphrase Uwe (fortunes::fortune(192)): computing is cheap and thinking hurts. I don't understand why we are spending so much time discussing what probably amounts (at most) to a couple of thousand of dollars of compute time. I raised the question, because CRAN maintainers rejected the latest version of "fda" because some of the examples took too long to run on their computers. Spencer Hadley -- Spencer Graves, PE, PhD President and Chief Technology Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 web: www.structuremonitoring.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] example(smooth.spline) fails when function is NOT byte-compiled
Hi, example(smooth.spline) fails with the non byte-compiled version of the smooth.spline function: > example(smooth.spline) smth.s> require(graphics) smth.s> attach(cars) smth.s> plot(speed, dist, main = "data(cars) & smoothing splines") [... more output deleted...] smth.s> lines(smooth.spline(speed, dist, df=10), lty=2, col = "red") Error in smooth.spline(speed, dist, df = 10) : smoothing parameter value too small More precisely, here is what happens on a fresh R session (R-2.15.1 configured with --disable-byte-compiled-packages): ** Checking that smooth.spline() is not compiled: > smooth.spline [... output deleted...] ** 1st call works: > res <- smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) ** 2nd call fails: > res <- smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) Error in smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) : smoothing parameter value too small ** 3rd call (but now with the compiled version of the function) still fails: > library(compiler) > smooth.spline2 <- cmpfun(smooth.spline) > smooth.spline2 [... output deleted...] > res2 <- smooth.spline2(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) Error in smooth.spline2(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) : smoothing parameter value too small Thanks, H. My session info: > sessionInfo() R version 2.15.1 (2012-06-22) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] compiler stats graphics grDevices utils datasets methods [8] base loaded via a namespace (and not attached): [1] tools_2.15.1 -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] different behavior accessing type-specific as.data.frame inside a function vs inside R shell
hello
we are developing an R package called ANTsR for which we have some special
types.
one of these types is an " antsMatrix " type.
we implemented a "as.data.frame" function that casts an antsMatrix to a
data.frame
this works fine in a basic shell script. for instance:
# install
R CMD INSTALL ANTsR
# open
R
# in R do
library(ANTsR)
a <- new( "antsMatrix", "float" )
b <- as.data.frame( a )
this all works fine and i am pleased.
fyi, the implementation of as.data.frame is:
setMethod( f = "as.data.frame" ,
signature( x = "antsMatrix" ) ,
definition = function( x )
{
lst = .Call( "antsMatrix_asList" , x )
names(lst)[ 1 : (length(lst)) ] <- lst[[ length(lst) ]]
lst[[ length(lst) ]] <- NULL
as.data.frame(lst)
}
)
now the problem comes when i try to access the same functionality in a
function that is within my package R source.
i.e. the function is defined in ANTsR/R/test.R which reads
test <- function(...)
{
a <- new( "antsMatrix", "float" )
b <- as.data.frame( a )
}
this should produce the same behavior as above, i would think.
but somehow , i get different behavior:
library(ANTsR)
test()
produces :
Error in as.data.frame.default(a) :
cannot coerce class 'structure("antsMatrix", package = "ANTsR")' into a
data.frame
it is clear to me what's happening - R is trying to use the default
implementation of as.data.frame
which clearly won't work on an antsMatrix type.
the issue is --- i do not know why R is not using the correct type-specific
implementation when
this function is called as opposed to when the same operations are called
within the shell.
certainly there must be some simple error on our part in implementation but
i cannot find
what it is --- i am the 3rd person who has looked into this. it's true
that we are all novice R
developers am hoping someone on the list can provide some insight.
many thanks for your time,
brian
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] different behavior accessing type-specific as.data.frame inside a function vs inside R shell
Hi Brian --
On 9/19/2012 1:06 PM, brian avants wrote:
hello
we are developing an R package called ANTsR for which we have some special
types.
one of these types is an " antsMatrix " type.
we implemented a "as.data.frame" function that casts an antsMatrix to a
data.frame
this works fine in a basic shell script. for instance:
# install
R CMD INSTALL ANTsR
# open
R
# in R do
library(ANTsR)
a <- new( "antsMatrix", "float" )
b <- as.data.frame( a )
this all works fine and i am pleased.
fyi, the implementation of as.data.frame is:
setMethod( f = "as.data.frame" ,
signature( x = "antsMatrix" ) ,
definition = function( x )
{
lst = .Call( "antsMatrix_asList" , x )
names(lst)[ 1 : (length(lst)) ] <- lst[[ length(lst) ]]
lst[[ length(lst) ]] <- NULL
as.data.frame(lst)
}
)
S4 uses setAs() to establish coercion between types. "Methods for S3
Generic Functions" of the help page ?Methods recommends defining both an
S3 and an S4 version of the coerce method. So for this toy
implementation of your class
setClass("antsMatrix",
representation=representation(values="numeric"))
I defined an S3 and an S4 coercion, reusing the S3 function as much as
possible.
as.data.frame.antsMatrix <-
function(x, row.names=NULL, optional = FALSE, ...)
{
## lst = .Call( "antsMatrix_asList" , x )
## names(lst)[ 1 : (length(lst)) ] <- lst[[ length(lst) ]]
## lst[[ length(lst) ]] <- NULL
## as.data.frame(lst)
data.frame(values=x@values)
}
setAs("antsMatrix", "data.frame", function(from) {
as.data.frame.antsMatrix(from)
})
in the NAMESPACE file you would export both methods
S3method(as.data.frame, antsMatrix)
exportMethods(coerce)
This supports both forms of coercion
> m <- new("antsMatrix", values=1:5)
> as.data.frame(m)
values
1 1
2 2
3 3
4 4
5 5
> as(m, "data.frame")
values
1 1
2 2
3 3
4 4
5 5
now the problem comes when i try to access the same functionality in a
function that is within my package R source.
i.e. the function is defined in ANTsR/R/test.R which reads
test <- function(...)
{
a <- new( "antsMatrix", "float" )
b <- as.data.frame( a )
}
this should produce the same behavior as above, i would think.
but somehow , i get different behavior:
library(ANTsR)
test()
produces :
Error in as.data.frame.default(a) :
cannot coerce class 'structure("antsMatrix", package = "ANTsR")' into a
data.frame
it is clear to me what's happening - R is trying to use the default
implementation of as.data.frame
which clearly won't work on an antsMatrix type.
the issue is --- i do not know why R is not using the correct type-specific
implementation when
this function is called as opposed to when the same operations are called
within the shell.
certainly there must be some simple error on our part in implementation but
i cannot find
what it is --- i am the 3rd person who has looked into this. it's true
that we are all novice R
developers am hoping someone on the list can provide some insight.
many thanks for your time,
brian
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Martin Morgan, PhD
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] example(smooth.spline) fails when function is NOT byte-compiled
As the posting guide asked of you, try R-patched or R-devel before posting, and check the bug repository. • smooth.spline() used DUP = FALSE which allowed its compiled C code to change the function: this was masked by the default byte-compilation. (PR#14965.) On 19/09/2012 21:41, Hervé Pagès wrote: Hi, example(smooth.spline) fails with the non byte-compiled version of the smooth.spline function: > example(smooth.spline) smth.s> require(graphics) smth.s> attach(cars) smth.s> plot(speed, dist, main = "data(cars) & smoothing splines") [... more output deleted...] smth.s> lines(smooth.spline(speed, dist, df=10), lty=2, col = "red") Error in smooth.spline(speed, dist, df = 10) : smoothing parameter value too small More precisely, here is what happens on a fresh R session (R-2.15.1 configured with --disable-byte-compiled-packages): ** Checking that smooth.spline() is not compiled: > smooth.spline [... output deleted...] ** 1st call works: > res <- smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) ** 2nd call fails: > res <- smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) Error in smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) : smoothing parameter value too small ** 3rd call (but now with the compiled version of the function) still fails: > library(compiler) > smooth.spline2 <- cmpfun(smooth.spline) > smooth.spline2 [... output deleted...] > res2 <- smooth.spline2(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) Error in smooth.spline2(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) : smoothing parameter value too small Thanks, H. My session info: > sessionInfo() R version 2.15.1 (2012-06-22) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] compiler stats graphics grDevices utils datasets methods [8] base loaded via a namespace (and not attached): [1] tools_2.15.1 -- 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
