[Rd] Unexpected email address change - and maybe a missing manual patch
Please forgive the unorthodox posting, but some marketing genius here has decided I need a new corporate email address and has duly changed my outgoing email without adequate notice to amend listserve subscriptions. The result is a lot of unexpected bounces from R-help and R-devel. I'll try to fix that in time, but more importantly a couple of you have been corresponding with me re a proposed patch for a manual. I sent the patch a couple of days back, so if it hasn;t arrived, it's probably got stuck behind a spam trap. If so, please let me know, add the correct address to your spam filter and I'll try again ... In the mean time I'll try to sort out the resulting listserve subscription mess. Steve Ellison LGC *** This email and any attachments are confidential. Any use...{{dropped:8}} __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Class not found when search in .onLoad
Thank you John for your response. Things are a little bit more complicated though. The inheritance checks are not only made in .onLoad, they are part of a class validity method, which is called in .onLoad because some objects from this class are created at this stage. Such objects can also be created at any moment, not in a call from .onLoad. More or less briefly: class 'A' is in fact a virtual class defined in the package's namespace, with the purpose of defining a common interface. While the package does provide some derived classes (i.e. defined within the namespace), users too must be able to define derived classes from 'A' (i.e. not defined within the namespace). In another class from the namespace, the validity method checks that one of its character slot contains the name of a class that inherits from interface 'A'. I was just expecting `isClass` and `extends` to also work in .onLoad without specifying the argument `where` (i.e. searching everywhere, starting by the package's namespace if called within a namespace). The argument `where` being there to allow finer search. There is no argument pkgname to the validity method, to directly apply the work around. I guess I can always check the presence of the class in the some-how hard-coded namespace, and if it is not found there look for the class elsewhere: #... clref - getClass('A', .Force=TRUE, where=THE.NAMESPACE) cl - getClass(name, .Force=TRUE, where=THE.NAMESPACE) if( is.null(cl) ) cl - getClass(name, .Force=TRUE) if( !extends(cl, clref) ) return('invalid slot') #... I will use this, in last resort, although it feels strange as it will only be to deal with the case where objects are created within a call to .onLoad. I am really interested in understanding why all this: - what makes this call so different? In my sample package, if I add a call `check.classes()` directly in script.R, the classes are correctly found when the installation sources the script prepare the package for lazy loading. - why things seemed to work ok in R-2.12.1 at the installation loading check, but do not work when loading the package from an R session? Could you please briefly give some explanations or pointers? Thank you. Bests, Renaud On 23/06/2011 18:44, John Chambers wrote: The workaround is to use the package's namespace, as you did. That's one of the reasons why pkgname is an argument to .onLoad(). Depending on what you want to do, you can either use the namespace as an argument where= or get the class definition from the namespace and use it in place of the class name. A side advantage is that such checks work regardless of whether or not the classes, etc. are exported from the package. Also, on the remote chance there is another class of the same name, the check works unambiguously on your package's version. The relevant part of your script, modified accordingly, seems to work as desired. John # script.R setClass('A', representation(data='numeric')) setClass('B', contains='A') # the argument is contains= check.classes - function(where){ message(isClass('A', where = where): , methods::isClass('A', where = where)) message(isClass('B', where = where): , methods::isClass('B', where = where)) classA - getClass('A', where = where) classB - getClass('B', where = where) message(extends(classB, classA): , methods::extends(classB, classA)) } .onLoad - function(libname, pkgname=NULL){ cat(\n## .onLoad ##\n) check.classes(asNamespace(pkgname)) } .onAttach - function(libname, pkgname){ cat(\n## .onAttach ##\n) check.classes(asNamespace(pkgname)) } On 6/23/11 4:22 AM, Renaud Gaujoux wrote: Hi, I am facing with a strange behaviour of isClass and extends when these are called in .onLoad in both R 2.12.1 and R 2.13.0. This is preventing my package from doing some object initializations at a proper place (i.e. in .onLoad). Suppose one defines two S4 classes in a package, and that one needs to check the inheritance between these two when loading the package (e.g. to validate slots in objects). See package attached or code below (not sure attachments can go through). in R 2.13.0: At the loading check after installation, the classes are not found by `isClass` and `extends` when these are called in .onLoad, but are correctly found when called in .onAttach. However findClass correctly finds the class in both case, as well as isClass if it is called with the argument `where=asNamespace('THE.PACKAGE.NAME')`. When the package is loaded from an open R session, the behaviour is the same. in R 2.12.1: the classes are correctly found by isClass and extends when these are called in .onLoad or .onAttach, but only at installation (i.e. at the loading check after R CMD INSTALL). When the package is loaded from an open R session, one fails to find the classes only in .onLoad while in .onAttach they are correctly found. This is really an issue as up to now I was using .onAttach to do
Re: [Rd] Is there an implementation of loess with more than 3 parametric ...
Dear John, I suggest that you look at the abilities of the mgcv package. There are notes of mine at http://www.maths.anu.edu.au/%7Ejohnm/r-book/xtras/autosmooth.pdf that may help you get started. Thank you very much for the suggestion and the link to your write-up, it was indeed very helpful! I have experimented with this library for a while now and am really happy about its flexibility. For my immediate applied problem, I will now go with a gam fit (z~te(x,y)+fa-1). I note, however, that this is much, much slower than loess, and is thus limited to smaller numbers of data points. (I could not fit the full model to 50,000 data points in a reasonable time.) I am therefore wondering if you knew of a way of also fixing the implementation of loess in R? From the error message (recompile with larger d2MAX) it seems that the underlying Fortran library was perfectly happy to fit a larger number of parametric variables. So is there a way one could remove the restriction to 4 parameters in the R interface/compilation? I have not found an obvious place where d2MAX is defined or configured, I suspect it might be hard-coded... With best regards, David. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Class not found when search in .onLoad
On 6/24/11 12:53 AM, Renaud Gaujoux wrote: Thank you John for your response. Things are a little bit more complicated though. The inheritance checks are not only made in .onLoad, they are part of a class validity method, which is called in .onLoad because some objects from this class are created at this stage. Such objects can also be created at any moment, not in a call from .onLoad. More or less briefly: class 'A' is in fact a virtual class defined in the package's namespace, with the purpose of defining a common interface. While the package does provide some derived classes (i.e. defined within the namespace), users too must be able to define derived classes from 'A' (i.e. not defined within the namespace). In another class from the namespace, the validity method checks that one of its character slot contains the name of a class that inherits from interface 'A'. Strictly speaking, that is not meaningful. A class (like any R object) is uniquely referenced by a name *and an environment*. The name of a package can be used to construct the environment, but your character slot won't identify a class reliably unless the character string has a package attribute. Look at class(x), for example, from an object from one of these classes. It will have a package attribute identifying the package. The character string with the package attribute is what you should be storing in the slot (or else store the class definition---takes more space but is slightly more efficient). I was just expecting `isClass` and `extends` to also work in .onLoad without specifying the argument `where` (i.e. searching everywhere, starting by the package's namespace if called within a namespace). The argument `where` being there to allow finer search. There is no argument pkgname to the validity method, to directly apply the work around. I guess I can always check the presence of the class in the some-how hard-coded namespace, and if it is not found there look for the class elsewhere: #... clref - getClass('A', .Force=TRUE, where=THE.NAMESPACE) cl - getClass(name, .Force=TRUE, where=THE.NAMESPACE) if( is.null(cl) ) cl - getClass(name, .Force=TRUE) if( !extends(cl, clref) ) return('invalid slot') #... I will use this, in last resort, although it feels strange as it will only be to deal with the case where objects are created within a call to .onLoad. I am really interested in understanding why all this: - what makes this call so different? In my sample package, if I add a call `check.classes()` directly in script.R, the classes are correctly found when the installation sources the script prepare the package for lazy loading. - why things seemed to work ok in R-2.12.1 at the installation loading check, but do not work when loading the package from an R session? Could you please briefly give some explanations or pointers? Thank you. Bests, Renaud On 23/06/2011 18:44, John Chambers wrote: The workaround is to use the package's namespace, as you did. That's one of the reasons why pkgname is an argument to .onLoad(). Depending on what you want to do, you can either use the namespace as an argument where= or get the class definition from the namespace and use it in place of the class name. A side advantage is that such checks work regardless of whether or not the classes, etc. are exported from the package. Also, on the remote chance there is another class of the same name, the check works unambiguously on your package's version. The relevant part of your script, modified accordingly, seems to work as desired. John # script.R setClass('A', representation(data='numeric')) setClass('B', contains='A') # the argument is contains= check.classes - function(where){ message(isClass('A', where = where): , methods::isClass('A', where = where)) message(isClass('B', where = where): , methods::isClass('B', where = where)) classA - getClass('A', where = where) classB - getClass('B', where = where) message(extends(classB, classA): , methods::extends(classB, classA)) } .onLoad - function(libname, pkgname=NULL){ cat(\n## .onLoad ##\n) check.classes(asNamespace(pkgname)) } .onAttach - function(libname, pkgname){ cat(\n## .onAttach ##\n) check.classes(asNamespace(pkgname)) } On 6/23/11 4:22 AM, Renaud Gaujoux wrote: Hi, I am facing with a strange behaviour of isClass and extends when these are called in .onLoad in both R 2.12.1 and R 2.13.0. This is preventing my package from doing some object initializations at a proper place (i.e. in .onLoad). Suppose one defines two S4 classes in a package, and that one needs to check the inheritance between these two when loading the package (e.g. to validate slots in objects). See package attached or code below (not sure attachments can go through). in R 2.13.0: At the loading check after installation, the classes are not found by `isClass` and `extends` when these are called in .onLoad, but are correctly found when called in .onAttach. However
Re: [Rd] Is there an implementation of loess with more than 3 parametric ...
Dear John, With loess, I regret that I cannot help. I have not looked into the code. I'd not been aware that there was such a speed difference. Are you sure that you are comparing like with like? loess does not optimise the choice of 'span', whereas (unless you fix it), mgcv does optimise the smoothing parameter. I am aware that mgcv is the much more flexible package, so it is hard to do a fair comparison but I have run loess in a cross-validation loop to set the span parameter, and this runs in a few minutes on 50k data points, while I aborted the gam attempt after several hours. You might at some point resubmit your question re the loess limitation to 4 parameters to CRAN, now with more background information. Ok, what additional information can I provide that might be helpful? Many thanks again for your help and support, David. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel