Re: [Rd] checking whether the name space can be loaded with stated dependencies
Hadley sent me the package, and my guess *was* correct. The package is
not using lazy-loading, and early on it has (in aaa-top-level.r)
TopLevel <- proto(expr = {
...
That is 'a top-level computation'. To make this work, you need
require("proto") in that file. It also needs require("grid").
The Depends: packages are available when the package is installed, but not
when the namespace is loaded.
On Fri, 4 Jan 2008, Prof Brian Ripley wrote:
> On Fri, 4 Jan 2008, hadley wickham wrote:
>
>> On 1/4/08, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>>> What it is trying is
>>>
>>> % env R_DEFAULT_PACKAGES=NULL R
>>>
loadNamespace("ggplot2")
>>>
>>> The test is not new, so it would seem to be a change in ggplot2 since the
>>> version on CRAN. My guess is the your package is doing top-level
>>> computations, which `Writing R Extensions' warns against:
>>>
>>>The R code files should only create R objects and not call functions
>>>with side effects such as require and options.
>>
>> Thanks for the additional info. I've grepped for ^[^#\n ]+\( (which I
>> think should find any top-level function call) and didn't find
>> anything. I certainly can't think of any top level computations that
>> I'm doing apart from creating R functions and objects. Is there
>> anyway to get more details about what exactly I've done wrong?
>
> As I said, that was a guess: if it is not the cause then I am in the dark.
> If you can send me the version doing this I can try to dig further.
>
>> Calling traceback after loadNamespace isn't helpful.
>>
>>> If you must deviate from that, you need to arrange for the environment you
>>> need: when loading a name space the Depends: packages are not loaded.
>>
>> Is this a recent change to R?
>
> No: that wording is ancient, and the test is not recent.
>
>> The package appears to work fine after
>> installation so I presume this check is protecting me from some more
>> subtle danger.
>
> The danger is that if some other package (or a user) does
> ggplot2::some_function_in_ggplot2 that this will fail if the package is
> not attached, similarly if a package name space imports from ggplot2.
>
>> If it's helpful, my depends line is:
>> Depends: R (>= 2.6), grid, reshape (>= 0.8.0), proto, splines, MASS,
>> RColorBrewer, colorspace
>>
>> so only proto or RColorBrewer should be a problem.
>>
>> Hadley
>>
>>
>
>
--
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] Finding windows DLLs
On Tue, 8 Jan 2008, Duncan Temple Lang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Prof Brian Ripley wrote: >> On Tue, 8 Jan 2008, Duncan Temple Lang wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> While I don't disagree with the general need to provide an interface >>> to SetDllDirectory, etc., I think the discussion about 3rd party >>> libraries has slightly missed the more obvious solution. >>> Instead of using a DLL, such packages can link against a _static_ >>> version of the 3rd party and so not get into this dynamic search and >>> load but guarantee that the symbols are resolved to what they were >>> intended at build time. >> >> Only if there is one. > > I assume 'one' refers to DLLs. > Either way, of course you can link against static versions of all > libraries and not just one. It requires having static versions of each > library. It refers to 'a _static_ version': normal English rules -- the immediate antecedent -- apply. >> This has been my practice when building Windows >> binary packages, but as in the recent example of ncdf, the developers of >> the third-party (netcdf) set up their make system only to implement some >> Windows tweaks when a DLL was built. More commonly, the third-party has >> to be built under a different compiler (typically VC++), and the static >> library is not compatible with MinGW. (iconv and Tcl/Tk are two >> examples where at least at one time MinGW builds didn't work correctly.) > >> In the case of XML, we could revert to my practice before Uwe took over, >> as I did (after some struggle) build libxml2/zlib statically under older >> versions of MinGW and so would expect to be able to do so again. > > Well this is the issue - whether we want to build our own versions of > a static version of a DLL. It would be a lot better if Windows users > were aware of the work done to support them and realized that it reduced > the resources available for more creative work. > > > >>> There are lots of advantages to using DLLs, but in many cases >>> we are not exploiting these and a static link would make these >>> issues irrelevant and not require users to know about PATH settings, etc. >>> >>> D. >>> >>> >>> Prof Brian Ripley wrote: On Mon, 7 Jan 2008, Duncan Murdoch wrote: > On 1/7/2008 2:51 PM, Martin Morgan wrote: >> The XML package relies on libxml2.dll (e.g., bundled with the CRAN >> binary) installed in library/XML/libs. Unfortunately, >> c:/WINDOWS/system32/libxml2.dll will be found and loaded before >> this. >> >> Is there any programatic solution? > Search order for DLLs is version dependent on Windows. The best way to > be sure of what you're loading is to fully specify the path to the DLL, > and this generally requires you to use API calls LoadLibrary() and > GetProcAddress() rather than relying on automatic loading of > dependencies. > > I don't know how many entry points XML is importing from > libxml2.dll; if > there are a lot, LoadLibrary() will be a pain to use, and it might be > easiest to rename libxml2.dll and hope to avoid a collision. About 85. But it's worse than that, as libxml2.dll itself imports from zlib1.dll and iconv.dll, and there is one of the latter in the application directory in R >= 2.6.0. So even if you find the right libxml2.dll, you may not find the right zlib1.dll and iconv.dll (and I already knew that you found R's iconv.dll, which fortunately works). I think we do need to provide an interface to SetDllDirectory, probably as an additional argument to dyn.load. >> >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHgxrn9p/Jzwa2QP4RAnsVAJsEkOT7DEu3pIOkIiA23RZ9mACIfACeIqrG > L3YrWfoD916Vbzu1zy93KkU= > =6yOz > -END PGP SIGNATURE- > -- 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] Finding windows DLLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Prof Brian Ripley wrote: > On Tue, 8 Jan 2008, Duncan Temple Lang wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> While I don't disagree with the general need to provide an interface >> to SetDllDirectory, etc., I think the discussion about 3rd party >> libraries has slightly missed the more obvious solution. >> Instead of using a DLL, such packages can link against a _static_ >> version of the 3rd party and so not get into this dynamic search and >> load but guarantee that the symbols are resolved to what they were >> intended at build time. > > Only if there is one. I assume 'one' refers to DLLs. Either way, of course you can link against static versions of all libraries and not just one. It requires having static versions of each library. > This has been my practice when building Windows > binary packages, but as in the recent example of ncdf, the developers of > the third-party (netcdf) set up their make system only to implement some > Windows tweaks when a DLL was built. More commonly, the third-party has > to be built under a different compiler (typically VC++), and the static > library is not compatible with MinGW. (iconv and Tcl/Tk are two > examples where at least at one time MinGW builds didn't work correctly.) > > In the case of XML, we could revert to my practice before Uwe took over, > as I did (after some struggle) build libxml2/zlib statically under older > versions of MinGW and so would expect to be able to do so again. > Well this is the issue - whether we want to build our own versions of a static version of a DLL. It would be a lot better if Windows users were aware of the work done to support them and realized that it reduced the resources available for more creative work. >> There are lots of advantages to using DLLs, but in many cases >> we are not exploiting these and a static link would make these >> issues irrelevant and not require users to know about PATH settings, etc. >> >> D. >> >> >> Prof Brian Ripley wrote: >>> On Mon, 7 Jan 2008, Duncan Murdoch wrote: >>> On 1/7/2008 2:51 PM, Martin Morgan wrote: > The XML package relies on libxml2.dll (e.g., bundled with the CRAN > binary) installed in library/XML/libs. Unfortunately, > c:/WINDOWS/system32/libxml2.dll will be found and loaded before > this. > > Is there any programatic solution? Search order for DLLs is version dependent on Windows. The best way to be sure of what you're loading is to fully specify the path to the DLL, and this generally requires you to use API calls LoadLibrary() and GetProcAddress() rather than relying on automatic loading of dependencies. I don't know how many entry points XML is importing from libxml2.dll; if there are a lot, LoadLibrary() will be a pain to use, and it might be easiest to rename libxml2.dll and hope to avoid a collision. >>> >>> About 85. But it's worse than that, as libxml2.dll itself imports from >>> zlib1.dll and iconv.dll, and there is one of the latter in the >>> application >>> directory in R >= 2.6.0. So even if you find the right libxml2.dll, you >>> may not find the right zlib1.dll and iconv.dll (and I already knew that >>> you found R's iconv.dll, which fortunately works). >>> >>> I think we do need to provide an interface to SetDllDirectory, >>> probably as >>> an additional argument to dyn.load. > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgxrn9p/Jzwa2QP4RAnsVAJsEkOT7DEu3pIOkIiA23RZ9mACIfACeIqrG L3YrWfoD916Vbzu1zy93KkU= =6yOz -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding windows DLLs
On Tue, 8 Jan 2008, Duncan Temple Lang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > While I don't disagree with the general need to provide an interface > to SetDllDirectory, etc., I think the discussion about 3rd party > libraries has slightly missed the more obvious solution. > Instead of using a DLL, such packages can link against a _static_ > version of the 3rd party and so not get into this dynamic search and > load but guarantee that the symbols are resolved to what they were > intended at build time. Only if there is one. This has been my practice when building Windows binary packages, but as in the recent example of ncdf, the developers of the third-party (netcdf) set up their make system only to implement some Windows tweaks when a DLL was built. More commonly, the third-party has to be built under a different compiler (typically VC++), and the static library is not compatible with MinGW. (iconv and Tcl/Tk are two examples where at least at one time MinGW builds didn't work correctly.) In the case of XML, we could revert to my practice before Uwe took over, as I did (after some struggle) build libxml2/zlib statically under older versions of MinGW and so would expect to be able to do so again. > There are lots of advantages to using DLLs, but in many cases > we are not exploiting these and a static link would make these > issues irrelevant and not require users to know about PATH settings, etc. > > D. > > > Prof Brian Ripley wrote: >> On Mon, 7 Jan 2008, Duncan Murdoch wrote: >> >>> On 1/7/2008 2:51 PM, Martin Morgan wrote: The XML package relies on libxml2.dll (e.g., bundled with the CRAN binary) installed in library/XML/libs. Unfortunately, c:/WINDOWS/system32/libxml2.dll will be found and loaded before this. Is there any programatic solution? >>> Search order for DLLs is version dependent on Windows. The best way to >>> be sure of what you're loading is to fully specify the path to the DLL, >>> and this generally requires you to use API calls LoadLibrary() and >>> GetProcAddress() rather than relying on automatic loading of dependencies. >>> >>> I don't know how many entry points XML is importing from libxml2.dll; if >>> there are a lot, LoadLibrary() will be a pain to use, and it might be >>> easiest to rename libxml2.dll and hope to avoid a collision. >> >> About 85. But it's worse than that, as libxml2.dll itself imports from >> zlib1.dll and iconv.dll, and there is one of the latter in the application >> directory in R >= 2.6.0. So even if you find the right libxml2.dll, you >> may not find the right zlib1.dll and iconv.dll (and I already knew that >> you found R's iconv.dll, which fortunately works). >> >> I think we do need to provide an interface to SetDllDirectory, probably as >> an additional argument to dyn.load. -- 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] Finding windows DLLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While I don't disagree with the general need to provide an interface to SetDllDirectory, etc., I think the discussion about 3rd party libraries has slightly missed the more obvious solution. Instead of using a DLL, such packages can link against a _static_ version of the 3rd party and so not get into this dynamic search and load but guarantee that the symbols are resolved to what they were intended at build time. There are lots of advantages to using DLLs, but in many cases we are not exploiting these and a static link would make these issues irrelevant and not require users to know about PATH settings, etc. D. Prof Brian Ripley wrote: > On Mon, 7 Jan 2008, Duncan Murdoch wrote: > >> On 1/7/2008 2:51 PM, Martin Morgan wrote: >>> The XML package relies on libxml2.dll (e.g., bundled with the CRAN >>> binary) installed in library/XML/libs. Unfortunately, >>> c:/WINDOWS/system32/libxml2.dll will be found and loaded before >>> this. >>> >>> Is there any programatic solution? >> Search order for DLLs is version dependent on Windows. The best way to >> be sure of what you're loading is to fully specify the path to the DLL, >> and this generally requires you to use API calls LoadLibrary() and >> GetProcAddress() rather than relying on automatic loading of dependencies. >> >> I don't know how many entry points XML is importing from libxml2.dll; if >> there are a lot, LoadLibrary() will be a pain to use, and it might be >> easiest to rename libxml2.dll and hope to avoid a collision. > > About 85. But it's worse than that, as libxml2.dll itself imports from > zlib1.dll and iconv.dll, and there is one of the latter in the application > directory in R >= 2.6.0. So even if you find the right libxml2.dll, you > may not find the right zlib1.dll and iconv.dll (and I already knew that > you found R's iconv.dll, which fortunately works). > > I think we do need to provide an interface to SetDllDirectory, probably as > an additional argument to dyn.load. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgwIy9p/Jzwa2QP4RAr32AJ9tDRvunOM0RMeCnEPJIlY7s5NgGACfRmK5 yB/ZNnqkdqc2aeu4f6mxW1w= =kytC -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 vs S4 for a simple package
On Jan 7, 2008 2:34 PM, John Chambers <[EMAIL PROTECTED]> wrote:
> One thing you cannot do in S3 is to have methods that depend on anything
> but the first argument.
Actually, you can. Here are two examples.
> ### first example - Axis ###
> ### note that it can be dispatched on x or at
> Axis
function (x = NULL, at = NULL, ..., side, labels = NULL)
{
if (!is.null(x))
UseMethod("Axis", x)
else if (!is.null(at))
UseMethod("Axis", at)
else axis(side = side, at = at, labels = labels, ...)
}
> ### second example: +.Date
> methods("+") # note S3 Date method for +
[1] +.Date +.POSIXt
> debug("+.Date") # notify if +.Date invoked
> Sys.Date() + 1 # yup. its invoked.
debugging in: `+.Date`(Sys.Date(), 1)
debug: {
coerceTimeUnit <- function(x) {
round(switch(attr(x, "units"), secs = x/86400, mins = x/1440,
hours = x/24, days = x, weeks = 7 * x))
}
if (nargs() == 1)
return(e1)
if (inherits(e1, "Date") && inherits(e2, "Date"))
stop("binary + is not defined for Date objects")
if (inherits(e1, "difftime"))
e1 <- coerceTimeUnit(e1)
if (inherits(e2, "difftime"))
e2 <- coerceTimeUnit(e2)
structure(unclass(e1) + unclass(e2), class = "Date")
}
Browse[1]> Q
> 1 + Sys.Date() # its invoked on arg 2 as well
debugging in: `+.Date`(1, Sys.Date())
debug: {
coerceTimeUnit <- function(x) {
round(switch(attr(x, "units"), secs = x/86400, mins = x/1440,
hours = x/24, days = x, weeks = 7 * x))
}
if (nargs() == 1)
return(e1)
if (inherits(e1, "Date") && inherits(e2, "Date"))
stop("binary + is not defined for Date objects")
if (inherits(e1, "difftime"))
e1 <- coerceTimeUnit(e1)
if (inherits(e2, "difftime"))
e2 <- coerceTimeUnit(e2)
structure(unclass(e1) + unclass(e2), class = "Date")
}
Browse[1]> Q
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] course announcement
Hi, We will be holding an advanced course in R programming at the FHCRC (Seattle), Feb 13-15. There will be some emphasis on Bioinformatic applications, but not much. Sign up at: https://secure.bioconductor.org/SeattleFeb08/index.php please note space is very limited so make sure you have a registration before making any travel plans. Also, this is definitely not a course for beginners. Best wishes Robert -- Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding windows DLLs
Thanks Duncan for the hints.
libxml2.dll is not in my c:/WINDOWS/system32, but in that of a user of
a package of mine. I guess installed by some other application, though
I don't really know what it's doing there (or the consequences of
removing it).
The MSDN site seemed in the long term to point in the direction of
side-by-side assemblies, which would require cooperation /
infrastructure from R.
Martin
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> On Mon, 7 Jan 2008, Oleg Sklyar wrote:
>
>> Should adding PREFIX/library/XML/libs to PATH before system32 solve the
>> issue as Windows relies on PATH when searching for libs as well?
>
> The Windows code for package XML says
>
>> XML:::.onLoad
> function (libname, pkgname)
> {
> if (.Platform$OS.type == "windows") {
> temp <- Sys.getenv("PATH")
> Sys.setenv(PATH = paste(utils::normalizePath(file.path(libname,
> pkgname, "libs")), temp, sep = ";"))
> on.exit(Sys.setenv(PATH = temp))
> }
> library.dynam("XML", pkgname, libname)
> if (exists("setMethod")) {
> }
> .C("RSXML_setErrorHandlers")
> }
>
>
> so it does already do that.
>
> The order depends on the version of Windows *and* its settings: see
>
> http://msdn2.microsoft.com/en-us/library/ms682586(VS.85).aspx
>
> There is a way to change this:
>
> http://msdn2.microsoft.com/en-us/library/ms686203(VS.85).aspx
>
> but it would preclude Windows 2000.
>
> Perhaps Martin can explain how libxml2.dll got into c:/WINDOWS/system32/?
> My suggestion is that we rename the DLL when copied into
> library/XML/libs to something like libRxml2.dll.
>
>>
>> Dr Oleg Sklyar | EBI-EMBL, Cambridge CB10 1SD, UK | +44-1223-494466
>>
>>
>> Martin Morgan wrote:
>>> The XML package relies on libxml2.dll (e.g., bundled with the CRAN
>>> binary) installed in library/XML/libs. Unfortunately,
>>> c:/WINDOWS/system32/libxml2.dll will be found and loaded before
>>> this.
>>>
>>> Is there any programatic solution?
>>>
>>> Thanks,
>>>
>>> Martin
>
> --
> 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
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding windows DLLs
On Mon, 7 Jan 2008, Duncan Murdoch wrote: > On 1/7/2008 2:51 PM, Martin Morgan wrote: >> The XML package relies on libxml2.dll (e.g., bundled with the CRAN >> binary) installed in library/XML/libs. Unfortunately, >> c:/WINDOWS/system32/libxml2.dll will be found and loaded before >> this. >> >> Is there any programatic solution? > > Search order for DLLs is version dependent on Windows. The best way to > be sure of what you're loading is to fully specify the path to the DLL, > and this generally requires you to use API calls LoadLibrary() and > GetProcAddress() rather than relying on automatic loading of dependencies. > > I don't know how many entry points XML is importing from libxml2.dll; if > there are a lot, LoadLibrary() will be a pain to use, and it might be > easiest to rename libxml2.dll and hope to avoid a collision. About 85. But it's worse than that, as libxml2.dll itself imports from zlib1.dll and iconv.dll, and there is one of the latter in the application directory in R >= 2.6.0. So even if you find the right libxml2.dll, you may not find the right zlib1.dll and iconv.dll (and I already knew that you found R's iconv.dll, which fortunately works). I think we do need to provide an interface to SetDllDirectory, probably as an additional argument to dyn.load. -- 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] S3 vs S4 for a simple package
On Jan 7, 2008 1:34 PM, John Chambers <[EMAIL PROTECTED]> wrote: > Prof Brian Ripley wrote: > > On Mon, 7 Jan 2008, Robin Hankin wrote: > > > > > >> I am writing a package and need to decide whether to use S3 or S4. > >> > >> I have a single class, "multipol"; this needs methods for "[" and "[<-" > >> and I also need a print (or show) method and methods for arithmetic +- > >> */^. > >> > >> In S4, an object of class "multipol" has one slot that holds an array. > >> > >> Objects of class "multipol" require specific arithmetic operations; > >> a,b being > >> multipols means that a+b and a*b are defined in peculiar ways > >> that make sense in the context of the package. I can also add and > >> multiply > >> by scalars (vectors of length one). > >> > One thing you cannot do in S3 is to have methods that depend on anything > but the first argument. Do you want something sensible for 1 + a when > a is a "multipol"? The default call to the primitive version may or may > not give you what you want. I agree with John. If method dispatch on multiple arguments is potentially useful to you, and it sounds as if it is, then S4 is clearly the winner. In the Matrix package, for example, determining a good method for evaluating A %*% B or solve(A, B), where A and B are Matrix objects, or matrix objects would be extremely difficult if we were not using S4 classes and methods. > >> My impression is that S3 is perfectly adequate for this task, although > >> I've not yet finalized the coding. > >> > >> S4 seems to be "overkill" for such a simple system. > >> > >> Can anyone give me some motivation for persisting with S4? > >> > >> Or indeed reassure me that S3 is a good design decision? > >> > > > > Does performance matter?: S4 dispatch is many times slower than S3 > > dispatch for such functions. (It is several times slower in general, but > > the difference is particularly marked for primitives.) > > > Well, the question is whether performance of _method dispatch_ matters, > which it tends not to in many cases. And it would be good to have some > data to clarify "many times slower". Generally, looking up inherited > methods is likely to take a while, but only the first time does R code > need to work out the inheritance. On repeated calls with the same > signature, dispatch should be basically a lookup in an environment. I can imagine circumstances in which the time spent on method dispatch would be important but I haven't encountered them and we have been working with S4 classes and methods in the Matrix and lme4 packages for a long time now. Much more important to me is the amount of time that I spend designing and debugging code and that is where S4 is, for me, the clear winner. Because of the formal class definitions and the validation of objects I can write C code assuming that the contents of particular slots in an object have the desired class. When I end up dealing with S3 objects not S4 objects I find it very clunky because there is no formal class definition and, if I am to play it safe, I should always check for the existence of certain components in the object then check or coerce the type then check the length, etc. With S4 classes I only need to do that once in a validate method. With S4 I feel that I can use a single class system in my R code and in the underlying C code. I don't need to create exotic structs or C++ classes in the compiled code because the S4 class system in R is enforcing the class definition for me. I just read Tim Hesterberg's message from later in this thread and I agree with him that the formal definition of classes makes it awkward to revise the slots. Fortunately, I have a very understanding user base for the lme4 package and they tolerate my changing class definitions between releases because I manage to convince them somehow that the package is improved by the changes. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding windows DLLs
On Mon, 7 Jan 2008, Duncan Murdoch wrote: > On 1/7/2008 3:06 PM, Oleg Sklyar wrote: >> Should adding PREFIX/library/XML/libs to PATH before system32 solve the >> issue as Windows relies on PATH when searching for libs as well? > > No, system32 is searched before the PATH. See > > http://msdn2.microsoft.com/en-us/library/ms682586.aspx > > That page doesn't discuss Win9X, NT4, or Win2K; I don't recall for sure, > but I suspect there were earlier changes to the search order as well. R > currently supports all of these, and 2.7 will continue to support Win2k > or later. For the record, here is what the search order was at the time of VC++6 (1998): 1. The directory from which the application loaded. 2. The current directory. 3. Windows 95 and Windows 98: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory. Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32. 4. Windows NT: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM. 5. The Windows directory. Use theGetWindowsDirectory function to get the path of this directory. 6. The directories that are listed in the PATH environment variable. The differences have been what is meant by the 'system directories', and the position of the current directory. -- 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] S3 vs S4 for a simple package
Would you like existing functions such as mean, range, sum, colSums, dim, apply, length, and many more to operate on the array of numbers? If so use an S3 class. If you would like to effectively disable such functions, to prevent them from working on the object unless you write a method that specifies exactly how the function should operate on the class, then either use an S4 class, or an S3 class where the array is one component of a list. An S3 class also allows for flexibility - you can add attributes, or list components, without breaking things. As for reassurance - I use S3 classes for almost everything, happily. The one time I chose to use an S4 class I later regretted it. This was for objects containing multiple imputations, where I wanted to prevent functions like mean() from working on the original data, without filling in imputations. The regret was because we later realized that in some cases we wanted to add a "call" attribute or component/slot so that update() would work. If it had been an S3 object we could have done so, but as an S4 object we would have broken existing objects of the class. Tim Hesterberg Disclaimer - this is my personal opinion, not my employer's. >I am writing a package and need to decide whether to use S3 or S4. > >I have a single class, "multipol"; this needs methods for "[" and "[<-" >and I also need a print (or show) method and methods for arithmetic +- >*/^. > >In S4, an object of class "multipol" has one slot that holds an array. > >Objects of class "multipol" require specific arithmetic operations; >a,b being >multipols means that a+b and a*b are defined in peculiar ways >that make sense in the context of the package. I can also add and >multiply >by scalars (vectors of length one). > >My impression is that S3 is perfectly adequate for this task, although >I've not yet finalized the coding. > >S4 seems to be "overkill" for such a simple system. > >Can anyone give me some motivation for persisting with S4? > >Or indeed reassure me that S3 is a good design decision? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding windows DLLs
On Mon, 7 Jan 2008, Oleg Sklyar wrote:
> Should adding PREFIX/library/XML/libs to PATH before system32 solve the
> issue as Windows relies on PATH when searching for libs as well?
The Windows code for package XML says
> XML:::.onLoad
function (libname, pkgname)
{
if (.Platform$OS.type == "windows") {
temp <- Sys.getenv("PATH")
Sys.setenv(PATH = paste(utils::normalizePath(file.path(libname,
pkgname, "libs")), temp, sep = ";"))
on.exit(Sys.setenv(PATH = temp))
}
library.dynam("XML", pkgname, libname)
if (exists("setMethod")) {
}
.C("RSXML_setErrorHandlers")
}
so it does already do that.
The order depends on the version of Windows *and* its settings: see
http://msdn2.microsoft.com/en-us/library/ms682586(VS.85).aspx
There is a way to change this:
http://msdn2.microsoft.com/en-us/library/ms686203(VS.85).aspx
but it would preclude Windows 2000.
Perhaps Martin can explain how libxml2.dll got into c:/WINDOWS/system32/?
My suggestion is that we rename the DLL when copied into library/XML/libs
to something like libRxml2.dll.
>
> Dr Oleg Sklyar | EBI-EMBL, Cambridge CB10 1SD, UK | +44-1223-494466
>
>
> Martin Morgan wrote:
>> The XML package relies on libxml2.dll (e.g., bundled with the CRAN
>> binary) installed in library/XML/libs. Unfortunately,
>> c:/WINDOWS/system32/libxml2.dll will be found and loaded before
>> this.
>>
>> Is there any programatic solution?
>>
>> Thanks,
>>
>> Martin
--
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] Finding windows DLLs
On 1/7/2008 3:06 PM, Oleg Sklyar wrote: > Should adding PREFIX/library/XML/libs to PATH before system32 solve the > issue as Windows relies on PATH when searching for libs as well? No, system32 is searched before the PATH. See http://msdn2.microsoft.com/en-us/library/ms682586.aspx That page doesn't discuss Win9X, NT4, or Win2K; I don't recall for sure, but I suspect there were earlier changes to the search order as well. R currently supports all of these, and 2.7 will continue to support Win2k or later. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 vs S4 for a simple package
In EBImage I have a very similar situation (well, with more methods). It would be impossible to use S3 in my case as my data structures are images and I need at least two dimensions (but in fact use 3), thus 2 variables to dispatch on in [, which are defined for multiple configurations like integer,missing; integer,integer or logical,missing. To make things faster in S4, I however did not put data into a separate slot, rather derived the class with contains="array", so effectively giving the class all the functionality of array, and only changing the default behaviour for a couple of methods. Obviously one can access the data low level through the @.Data slot, both in C and R. This was a real performance boost compared to putting data into a separate slot, otherwise even working with many images and large sets I have not really noticed any performance issues that would be connected with the speed of method dispatch (although I would not argue that there are none). Regards, Oleg Dr Oleg Sklyar | EBI-EMBL, Cambridge CB10 1SD, UK | +44-1223-494466 John Chambers wrote: > Prof Brian Ripley wrote: >> On Mon, 7 Jan 2008, Robin Hankin wrote: >> >> >>> I am writing a package and need to decide whether to use S3 or S4. >>> >>> I have a single class, "multipol"; this needs methods for "[" and "[<-" >>> and I also need a print (or show) method and methods for arithmetic +- >>> */^. >>> >>> In S4, an object of class "multipol" has one slot that holds an array. >>> >>> Objects of class "multipol" require specific arithmetic operations; >>> a,b being >>> multipols means that a+b and a*b are defined in peculiar ways >>> that make sense in the context of the package. I can also add and >>> multiply >>> by scalars (vectors of length one). >>> > One thing you cannot do in S3 is to have methods that depend on anything > but the first argument. Do you want something sensible for 1 + a when > a is a "multipol"? The default call to the primitive version may or may > not give you what you want. >>> My impression is that S3 is perfectly adequate for this task, although >>> I've not yet finalized the coding. >>> >>> S4 seems to be "overkill" for such a simple system. >>> >>> Can anyone give me some motivation for persisting with S4? >>> >>> Or indeed reassure me that S3 is a good design decision? >>> >> Does performance matter?: S4 dispatch is many times slower than S3 >> dispatch for such functions. (It is several times slower in general, but >> the difference is particularly marked for primitives.) >> > Well, the question is whether performance of _method dispatch_ matters, > which it tends not to in many cases. And it would be good to have some > data to clarify "many times slower". Generally, looking up inherited > methods is likely to take a while, but only the first time does R code > need to work out the inheritance. On repeated calls with the same > signature, dispatch should be basically a lookup in an environment. > > [[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] Finding windows DLLs
On 1/7/2008 2:51 PM, Martin Morgan wrote: > The XML package relies on libxml2.dll (e.g., bundled with the CRAN > binary) installed in library/XML/libs. Unfortunately, > c:/WINDOWS/system32/libxml2.dll will be found and loaded before > this. > > Is there any programatic solution? Search order for DLLs is version dependent on Windows. The best way to be sure of what you're loading is to fully specify the path to the DLL, and this generally requires you to use API calls LoadLibrary() and GetProcAddress() rather than relying on automatic loading of dependencies. I don't know how many entry points XML is importing from libxml2.dll; if there are a lot, LoadLibrary() will be a pain to use, and it might be easiest to rename libxml2.dll and hope to avoid a collision. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding windows DLLs
Should adding PREFIX/library/XML/libs to PATH before system32 solve the issue as Windows relies on PATH when searching for libs as well? Dr Oleg Sklyar | EBI-EMBL, Cambridge CB10 1SD, UK | +44-1223-494466 Martin Morgan wrote: > The XML package relies on libxml2.dll (e.g., bundled with the CRAN > binary) installed in library/XML/libs. Unfortunately, > c:/WINDOWS/system32/libxml2.dll will be found and loaded before > this. > > Is there any programatic solution? > > Thanks, > > Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Finding windows DLLs
The XML package relies on libxml2.dll (e.g., bundled with the CRAN binary) installed in library/XML/libs. Unfortunately, c:/WINDOWS/system32/libxml2.dll will be found and loaded before this. Is there any programatic solution? Thanks, Martin -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] library(splines) is missing setOldClass(c("bs", "basis")) (PR#10554)
> library(splines)
> extends("bs", "basis")
[1] FALSE
> setOldClass(c("bs", "basis"))
> extends("bs", "basis")
[1] TRUE
Note that "bs" should inherit from "basis":
> temp <- bs(1:99, df=5)
> oldClass(temp)
[1] "bs""basis"
Similarly for "ns"
In contrast, in S+:
> extends("bs", "basis")
[1] T
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 6.1
year = 2007
month = 11
day = 26
svn rev = 43537
language = R
version.string = R version 2.6.1 (2007-11-26)
Windows XP (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
Search Path:
.GlobalEnv, package:splines, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, package:methods, Autoloads,
package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 vs S4 for a simple package
Prof Brian Ripley wrote: > On Mon, 7 Jan 2008, Robin Hankin wrote: > > >> I am writing a package and need to decide whether to use S3 or S4. >> >> I have a single class, "multipol"; this needs methods for "[" and "[<-" >> and I also need a print (or show) method and methods for arithmetic +- >> */^. >> >> In S4, an object of class "multipol" has one slot that holds an array. >> >> Objects of class "multipol" require specific arithmetic operations; >> a,b being >> multipols means that a+b and a*b are defined in peculiar ways >> that make sense in the context of the package. I can also add and >> multiply >> by scalars (vectors of length one). >> One thing you cannot do in S3 is to have methods that depend on anything but the first argument. Do you want something sensible for 1 + a when a is a "multipol"? The default call to the primitive version may or may not give you what you want. >> My impression is that S3 is perfectly adequate for this task, although >> I've not yet finalized the coding. >> >> S4 seems to be "overkill" for such a simple system. >> >> Can anyone give me some motivation for persisting with S4? >> >> Or indeed reassure me that S3 is a good design decision? >> > > Does performance matter?: S4 dispatch is many times slower than S3 > dispatch for such functions. (It is several times slower in general, but > the difference is particularly marked for primitives.) > Well, the question is whether performance of _method dispatch_ matters, which it tends not to in many cases. And it would be good to have some data to clarify "many times slower". Generally, looking up inherited methods is likely to take a while, but only the first time does R code need to work out the inheritance. On repeated calls with the same signature, dispatch should be basically a lookup in an environment. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is(x, "parent") returns FALSE when class(x) is c("child", "parent") (PR#10549)
In S-PLUS, is() does catch parent S3 classes. It does not require a setOldClass definition to do so. I would prefer that R work the same way, to make porting code easier. I use is() in S-PLUS for both S3 and S4 classes because it is faster than inherits(). I use inherits() only for testing a vector of classes, rather than a single class. To suggest that S3 has no class inheritance seems odd. We use inheritance of S3 classes all the time - "ordered" inheriting from "factor", many classes inheriting from "data.frame", etc. I see no problem in having inheritance without class definitions. >> "TimH" == timh <[EMAIL PROTECTED]> >> on Sat, 5 Jan 2008 02:05:08 +0100 (CET) writes: > >TimH> is() does not catch parent S3 classes: > >>> library(splines) >>> temp <- bs(1:99, df=5) >>> class(temp) >TimH> [1] "bs""basis" >>> is(temp, "basis") >TimH> [1] FALSE > >TimH> In contrast, is() does catch parent S4 classes: >... > >Yes, that's all correct, but where's the bug? > >S3 has *NO* class definitions, so how can there be class >inheritance? >There's many reasons to go from S3 to S4, and the lack of class >definitions in S3 is an important one... > >Now, still being curious: Are you implicitly saying that in S-plus, >is() behaves differently, namely >``as if S3 classes would exist?'' (:-) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is(x, "parent") returns FALSE when class(x) is c("child", "parent") (PR#10549)
In S-PLUS, is() does catch parent S3 classes. It does not require a setOldClass definition to do so. I would prefer that R work the same way, to make porting code easier. I use is() in S-PLUS for both S3 and S4 classes because it is faster than inherits(). I use inherits() only for testing a vector of classes, rather than a single class. To suggest that S3 has no class inheritance seems odd. We use inheritance of S3 classes all the time - "ordered" inheriting from "factor", many classes inheriting from "data.frame", etc. I see no problem in having inheritance without class definitions. >> "TimH" == timh <[EMAIL PROTECTED]> >> on Sat, 5 Jan 2008 02:05:08 +0100 (CET) writes: > >TimH> is() does not catch parent S3 classes: > >>> library(splines) >>> temp <- bs(1:99, df=5) >>> class(temp) >TimH> [1] "bs""basis" >>> is(temp, "basis") >TimH> [1] FALSE > >TimH> In contrast, is() does catch parent S4 classes: >... > >Yes, that's all correct, but where's the bug? > >S3 has *NO* class definitions, so how can there be class >inheritance? >There's many reasons to go from S3 to S4, and the lack of class >definitions in S3 is an important one... > >Now, still being curious: Are you implicitly saying that in S-plus, >is() behaves differently, namely >``as if S3 classes would exist?'' (:-) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unicode whitespace
On Sat, 5 Jan 2008, hadley wickham wrote:
> On Jan 5, 2008 1:40 AM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>> I presume you want this only in a UTF-8 locale?
>
> Yes, although my assumption is that this will become an increasing
> common locale as time goes by.
Probably, except on Windows. UTF-8 support in commercial Unixen is often
poor (i.e. it is nominally there but does not work well). The need for
other non-8-bit encodings is diminishing, e.g. the various shift encodings
for Japanese will likely die out but over a long time.
>> Currently this is done by
>>
>> static int SkipSpace(void)
>> {
>> int c;
>> while ((c = xxgetc()) == ' ' || c == '\t' || c == '\f')
>> /* nothing */;
>> return c;
>> }
>>
>> in gram.c. We could make use of isspace and its wide-char equivalent
>> iswspace. However:
>>
>>
>> - there is the perennial debate over whether \v is whitespace.
>>
>> R-lang says
>>
>>Although not strictly tokens, stretches of whitespace characters
>>(spaces and tabs) serve to delimit tokens in case of ambiguity,
>>
>> which suggests it has a minimal view of whitespace.
>>
>>
>> - iswspace is often rather unreliable. E.g. glibc says
>>
>> The wide character class "space" always contains at least the space
>> character and the control characters '\f', '\n', '\r', '\t', '\v'.
>>
>> and I think it usually does not contain other forms of spaces. More
>> seriously
>>
>> The behaviour of iswspace() depends on the LC_CTYPE category of the
>> current locale.
>>
>> so what is a space will depend on the encoding (hence my question about
>> UTF-8). And Ei-ji Makama was replaced iswspace on MacOS X, because
>> apparently it is wrongly implemented.
>>
>>
>> - it would complicate the parser as look-ahead would be needed (you would
>> need to read the next mbcs, check it it were whitespace and pushback if
>> needed). We do that elsewhere, though.
>
> I had assumed the parser would be unicode/mb aware already and so
> would be an easy fix.
It's not, because it has to work on non-Unicode platforms (e.g. Windows 9x
until R 2.7.0), and even platforms in which wchar_t is not Unicode. (More
precisely, we need to avoid making assumptions we can't verify on such
platforms.)
There's a problem with 'whitespace': \n is whitespace but is a command
terminator -- so what should Unicode line and para separators map to? I
decided to use only blanks (in the sense of iswblank) as whitespace, and
further only to use the table that Ei-ji Nakama provided for us in
rlocale_data.h (adding NBSP). So the new rules are that 'whitespace' in
parsing is
\t, \f (not \v, for historical reasons, I presume)
NBSP in 8-bit Windows locales
Unicode blanks in UTF-8 locales on internally Unicode machines (and I
doubt UTF-8 locales exist anywhere else).
> The locale issues are clearly important and
> can't easily be swept under the rug.
>
>> The only one of these 'spaces' I have much sympathy for is NBSP (which is
>> also fairly easy to generate in CP1252). It would be easy to add that.
>> Otherwise I am not convinced it is worth the work (and added uncertainty).
>
> That's reasonable. Another related request would be treating curly
> quotes (single and double) the same way as normal quotes, but I'd
> imagine similar caveats would apply there.
And a bit more: they are directional so you would (I presume) only want to
match \u2029 to \u2028 etc. That would be a lot of extra work.
> You could also imagine using unicode arrows in place of <- and ->, but
> that's probably heading too far down the apl/fortress road!
--
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] chi-squared with zero df (PR#10551)
> "MM" == Martin Maechler <[EMAIL PROTECTED]>
> on Mon, 7 Jan 2008 09:50:15 +0100 (CET) writes:
> "JL" == Jerry Lewis <[EMAIL PROTECTED]>
> on Mon, 7 Jan 2008 05:20:23 +0100 (CET) writes:
JL> Full_Name: Jerry W. Lewis
JL> Version: 2.6.1
JL> OS: Windows XP Professional
JL> Submission from: (NULL) (24.147.191.250)
JL> pchisq(0,0,ncp=lambda) returns 0 instead of exp(-lambda/2)
MM> Yes. As we know, chi-square(df=0, ncp=lambda) has a point mass of
MM> exp(-lambda/2) at 0.
MM> Hence pchisq() has a corresponding jump there; strictly, it's a
MM> matter of definition (left- / right- continuity, etc) what
MM> pchisq() should be there, but indeed, the usual definition --
MM> which we also follow for the discrete distributions --
MM> is "cadlag" (continue à droite, limite à gauche),
MM> and you are right.
MM> That's easily fixed.
JL> pchisq(x,0,ncp=lambda) returns NaN
JL> instead of exp(-lambda/2)*(1 + SUM_{r=0}^infty
JL> ((lambda/2)^r / r!) pchisq(x, df + 2r))
MM> Not on my Linux computers; e.g.,
>> pchisq(0:10, 0,1)
MM> [1] 0.000 0.7328798 0.8193100 0.8781745 0.9181077 0.9451020
0.9632911
MM> [8] 0.9755110 0.9836985 0.9891706 0.9928194
MM> but I can see the problem on Windows (Server 2003 R2, x64 edition),
MM> where I get
>> pchisq(0:10, 0,1)
MM> [1] 0 NaN NaN ... NaN
MM> aah, and I also see it on a 32-bit Linux computer.
and actually did see it on all computers; I was wrong above.
It's been a consequence of an "improvement" introduced for R 2.3.0;
unfortunately that made the (df=0, ncp < 80) wrongly return NaN.
Now fixed in both R-patched and R-devel.
Thank you once more for the bug report!
Martin
JL> qchisq(.7,0,ncp=1) returns 1.712252 instead of 0.701297103
MM> On my 64-bit Linux computer I get the correct result where as
MM> the above Windows and our 32-bit Linux give *different* (but
MM> wrong) results.
JL> qchisq(exp(-1/2),0,ncp=1) returns 1.238938 instead of 0
MM> Not on my 64-bit Linux where e.g.,
>> lam <- 1:10; qchisq(exp(-lam), 0, ncp=lam)
MM> [1] 2.225074e-308 2.225074e-308 2.225074e-308 2.225074e-308
2.225074e-308
MM> [6] 2.225074e-308 2.225074e-308 2.225074e-308 2.225074e-308
2.225074e-308
MM> i.e. "numerically 0"
MM> {Note that I've known about problems with our non-central chisq
MM> algorithms, but these were all of very extreme cases...}
MM> In summary, we seem to have an issue with our algorithms failing
MM> on some platforms.
MM> I'll investigate.
MM> Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xtable (PR#10553)
[EMAIL PROTECTED] wrote:
> Full_Name: Soren Feodor Nielsen
> Version: 2.5.0
> OS: linux-gnu
> Submission from: (NULL) (130.225.103.21)
>
>
> The print-out of xtable in the following example is wrong; instead of yielding
> the correct ci's for the second model it repeats the ci's from the first
> model.
>
>
> require(xtable)
> require(MASS)
> data(cats)
> b1<-lm(Hwt~Sex,cats)
> b2<-lm(Hwt~Sex+Bwt,cats)
> cbind(c(coef(b1),NA),rbind(confint(b1),c(NA,NA)),coef(b2),confint(b2))
> xtable(cbind(c(coef(b1),NA),rbind(confint(b1),c(NA,NA)),coef(b2),confint(b2)))
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
Not for me with a current(!) version of R et al.:
> cbind(c(coef(b1),NA),rbind(confint(b1),c(NA,NA)),coef(b2),confint(b2))
2.5 % 97.5 % 2.5 % 97.5 %
(Intercept) 9.202128 8.559519 9.844736 -0.41495263 -1.8528230 1.022918
SexM2.120553 1.337588 2.903517 -0.08209684 -0.6831776 0.518984
NA NA NA 4.07576892 3.4929923 4.658546
>
xtable(cbind(c(coef(b1),NA),rbind(confint(b1),c(NA,NA)),coef(b2),confint(b2)))
% latex table generated in R 2.6.1 by xtable 1.5-2 package
% Mon Jan 7 15:38:21 2008
\begin{table}[ht]
\begin{center}
\begin{tabular}{rrr}
\hline
& V1 & 2.5 \% & 97.5 \% & V4 & 2.5 \% & 97.5 \% \\
\hline
(Intercept) & 9.20 & 8.56 & 9.84 & $-$0.41 & $-$1.85 & 1.02 \\
SexM & 2.12 & 1.34 & 2.90 & $-$0.08 & $-$0.68 & 0.52 \\
& & & & 4.08 & 3.49 & 4.66 \\
\hline
\end{tabular}
\end{center}
\end{table}
--
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
[Rd] xtable (PR#10553)
Full_Name: Soren Feodor Nielsen Version: 2.5.0 OS: linux-gnu Submission from: (NULL) (130.225.103.21) The print-out of xtable in the following example is wrong; instead of yielding the correct ci's for the second model it repeats the ci's from the first model. require(xtable) require(MASS) data(cats) b1<-lm(Hwt~Sex,cats) b2<-lm(Hwt~Sex+Bwt,cats) cbind(c(coef(b1),NA),rbind(confint(b1),c(NA,NA)),coef(b2),confint(b2)) xtable(cbind(c(coef(b1),NA),rbind(confint(b1),c(NA,NA)),coef(b2),confint(b2))) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 vs S4 for a simple package
On Mon, 7 Jan 2008, Robin Hankin wrote: > I am writing a package and need to decide whether to use S3 or S4. > > I have a single class, "multipol"; this needs methods for "[" and "[<-" > and I also need a print (or show) method and methods for arithmetic +- > */^. > > In S4, an object of class "multipol" has one slot that holds an array. > > Objects of class "multipol" require specific arithmetic operations; > a,b being > multipols means that a+b and a*b are defined in peculiar ways > that make sense in the context of the package. I can also add and > multiply > by scalars (vectors of length one). > > My impression is that S3 is perfectly adequate for this task, although > I've not yet finalized the coding. > > S4 seems to be "overkill" for such a simple system. > > Can anyone give me some motivation for persisting with S4? > > Or indeed reassure me that S3 is a good design decision? Does performance matter?: S4 dispatch is many times slower than S3 dispatch for such functions. (It is several times slower in general, but the difference is particularly marked for primitives.) -- 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
[Rd] S3 vs S4 for a simple package
I am writing a package and need to decide whether to use S3 or S4. I have a single class, "multipol"; this needs methods for "[" and "[<-" and I also need a print (or show) method and methods for arithmetic +- */^. In S4, an object of class "multipol" has one slot that holds an array. Objects of class "multipol" require specific arithmetic operations; a,b being multipols means that a+b and a*b are defined in peculiar ways that make sense in the context of the package. I can also add and multiply by scalars (vectors of length one). My impression is that S3 is perfectly adequate for this task, although I've not yet finalized the coding. S4 seems to be "overkill" for such a simple system. Can anyone give me some motivation for persisting with S4? Or indeed reassure me that S3 is a good design decision? -- Robin Hankin Uncertainty Analyst and Neutral Theorist, 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] chi-squared with zero df (PR#10551)
> "JL" == Jerry Lewis <[EMAIL PROTECTED]>
> on Mon, 7 Jan 2008 05:20:23 +0100 (CET) writes:
JL> Full_Name: Jerry W. Lewis
JL> Version: 2.6.1
JL> OS: Windows XP Professional
JL> Submission from: (NULL) (24.147.191.250)
JL> pchisq(0,0,ncp=lambda) returns 0 instead of exp(-lambda/2)
Yes. As we know, chi-square(df=0, ncp=lambda) has a point mass of
exp(-lambda/2) at 0.
Hence pchisq() has a corresponding jump there; strictly, it's a
matter of definition (left- / right- continuity, etc) what
pchisq() should be there, but indeed, the usual definition --
which we also follow for the discrete distributions --
is "cadlag" (continue à droite, limite à gauche),
and you are right.
That's easily fixed.
JL> pchisq(x,0,ncp=lambda) returns NaN
JL> instead of exp(-lambda/2)*(1 + SUM_{r=0}^infty
JL> ((lambda/2)^r / r!) pchisq(x, df + 2r))
Not on my Linux computers; e.g.,
> pchisq(0:10, 0,1)
[1] 0.000 0.7328798 0.8193100 0.8781745 0.9181077 0.9451020 0.9632911
[8] 0.9755110 0.9836985 0.9891706 0.9928194
but I can see the problem on Windows (Server 2003 R2, x64 edition),
where I get
> pchisq(0:10, 0,1)
[1] 0 NaN NaN ... NaN
aah, and I also see it on a 32-bit Linux computer.
JL> qchisq(.7,0,ncp=1) returns 1.712252 instead of 0.701297103
On my 64-bit Linux computer I get the correct result where as
the above Windows and our 32-bit Linux give *different* (but
wrong) results.
JL> qchisq(exp(-1/2),0,ncp=1) returns 1.238938 instead of 0
Not on my 64-bit Linux where e.g.,
> lam <- 1:10; qchisq(exp(-lam), 0, ncp=lam)
[1] 2.225074e-308 2.225074e-308 2.225074e-308 2.225074e-308 2.225074e-308
[6] 2.225074e-308 2.225074e-308 2.225074e-308 2.225074e-308 2.225074e-308
i.e. "numerically 0"
{Note that I've known about problems with our non-central chisq
algorithms, but these were all of very extreme cases...}
In summary, we seem to have an issue with our algorithms failing
on some platforms.
I'll investigate.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
