Re: [Rd] limitations to random number generator in 64-bits machines
AFAICS, these are statistics, not R, issues, and are completely off
topic here. You should post on a statistics list, such as
stats.stackexchange.com, instead.
Cheers,
Bert
On Thu, Feb 21, 2013 at 5:20 AM, Mauricio Zambrano-Bigiarini
wrote:
> Dear List,
>
> Recently I got the comment that the implementation of the random number
> generator used by default in R (Mersenne-Twister) could not be "safe" for
> 64-bits machines, so I decided to put the question here because I do not
> have expertise in that topic, and because this question could be "too
> technical for R-help's audience". I apologise if this is not the case.
>
> The period 2^19937 - 1 mentioned in the help page of 'RNG' for the
> Mersenne-Twister generator, is it the same for 32-bits machines and 64-bits
> ones ?
>
> In addition:
>
> -) If I want to generate two consecutive sequences s_1 and s_2 of n
> pseudo-random numbers each, and knowing how the Random number generator is
> coded, can we estimate in advance the correlation coefficient rho between s1
> and s2?
>
> -) Let us say that we compute the correlation coefficient rho between s_1
> and s_2 and find it is not null. How small should it be so that we can
> reasonably use a statistical analysis that does suppose that the sequences
> are independent ?
>
>
> Thank in advance for any help you can provide,
>
> Mauricio Zambrano-Bigiarini
>
> --
> =
> Water Resources Unit
> Institute for Environment and Sustainability (IES)
> Joint Research Centre (JRC), European Commission
> TP 261, Via Enrico Fermi 2749, 21027 Ispra (VA), IT
> webinfo: http://floods.jrc.ec.europa.eu/
> =
> DISCLAIMER:\ "The views expressed are purely those of th...{{dropped:10}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Bert Gunter
Genentech Nonclinical Biostatistics
Internal Contact Info:
Phone: 467-7374
Website:
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] limitations to random number generator in 64-bits machines
On 22/02/2013 11:02, Bert Gunter wrote:
AFAICS, these are statistics, not R, issues, and are completely off
topic here. You should post on a statistics list, such as
stats.stackexchange.com, instead.
Except for the unattributed vague comment about 64-bit (sic) machines.
The RNG is the same (and gives the same results) on both 32- and 64-bit
machines. The size of the pointer has nothing to do with random-number
generation.
Cheers,
Bert
On Thu, Feb 21, 2013 at 5:20 AM, Mauricio Zambrano-Bigiarini
wrote:
Dear List,
Recently I got the comment that the implementation of the random number
generator used by default in R (Mersenne-Twister) could not be "safe" for
64-bits machines, so I decided to put the question here because I do not
have expertise in that topic, and because this question could be "too
technical for R-help's audience". I apologise if this is not the case.
The period 2^19937 - 1 mentioned in the help page of 'RNG' for the
Mersenne-Twister generator, is it the same for 32-bits machines and 64-bits
ones ?
In addition:
-) If I want to generate two consecutive sequences s_1 and s_2 of n
pseudo-random numbers each, and knowing how the Random number generator is
coded, can we estimate in advance the correlation coefficient rho between s1
and s2?
-) Let us say that we compute the correlation coefficient rho between s_1
and s_2 and find it is not null. How small should it be so that we can
reasonably use a statistical analysis that does suppose that the sequences
are independent ?
Thank in advance for any help you can provide,
Mauricio Zambrano-Bigiarini
--
=
Water Resources Unit
Institute for Environment and Sustainability (IES)
Joint Research Centre (JRC), European Commission
TP 261, Via Enrico Fermi 2749, 21027 Ispra (VA), IT
webinfo: http://floods.jrc.ec.europa.eu/
=
DISCLAIMER:\ "The views expressed are purely those of th...{{dropped:10}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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
Re: [Rd] limitations to random number generator in 64-bits machines
On 22/02/13 12:54, Prof Brian Ripley wrote: On 22/02/2013 11:02, Bert Gunter wrote: AFAICS, these are statistics, not R, issues, and are completely off topic here. You should post on a statistics list, such as stats.stackexchange.com, instead. Except for the unattributed vague comment about 64-bit (sic) machines. The RNG is the same (and gives the same results) on both 32- and 64-bit machines. The size of the pointer has nothing to do with random-number generation. Thank you very much for making this clear for me. Kind regards, Mauricio -- = Linux user #454569 -- Ubuntu user #17469 = "Where ambition ends happiness begins" (Source Unknown) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Registering native routines
I'm working on registering all the routines in the survival package, per a request from
R-core. Two questions:
1. In the coxph routine I have this type of structure:
if (survival has 2 columns) routines <- c("coxfit5_a", "coxfit5_b",
"coxfit5_c")
else routines <- c("agfit5_a", "agfit5_b",
"agfit5_c")
.
.C(routines[1], arg1, etc
I tried replacing "routines" with a vector of native symbol references, but it
doesn't work
Error in .C(routines[1], as.integer(n), as.integer(nvar), as.double(y), :
first argument must be a string (of length 1) or native symbol reference
I had fixed up all the other .C and .Call statements first (28 of them) and that worked,
so the problem is not with finding the set of symbol references.
2. In the R-exts manual it mentions another argument "style" for C calls to specify if an
argument is for input, output, or both. However, I can find no details on how to use it.
3. A few of my routines still had a COPY argument. I assume that is simply
ignored?
Terry T.
R Under development (unstable) (2013-02-11 r61902)
Platform: i686-pc-linux-gnu (32-bit)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Recommended way to call/import functions from a Suggested package
If in my package "Foo" I call a function from another package "Bar" if it's available, according to R-exts, this sounds like I should include "Suggests: Bar" in package Foo's description. But the manual is silent on how to treat Bar's namespace. Should I import it? If so, should this be conditional or unconditional? There is a thread from 2008 in which Duncan Murdoch suggests trying conditionally importing a package if it's installed, with the caveat "If this is allowed" (http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears to work in current release of R, 2.15.2, but I'm still not clear if it's officially allowed, much less recommended. The manual also says: > If a package only needs a few objects from another package it can use a fully > qualified variable reference in the code instead of a formal import. A fully > qualified reference to the function f in package foo is of the form foo::f. > This is slightly less efficient than a formal import and also loses the > advantage of recording all dependencies in the NAMESPACE file, so this > approach is usually not recommended. Evaluating foo::f will cause package foo > to be loaded, but not attached, if it was not loaded alreadythis can be an > advantage in delaying the loading of a rarely used package. > Would this be a better solution than importing when calling into a suggested package? Davor [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recommended way to call/import functions from a Suggested package
Hi Davor,
To the best of my knowledge, there's only one way to use functions
from a suggested package: with require:
if (require("suggested_package")) {
function_from_suggested_package()
} else {
stop("suggested package not installed")
}
Unfortunately I don't think there's any way to use a suggested package
without polluting the search path.
Hadley
On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic wrote:
> If in my package "Foo" I call a function from another package "Bar" if it's
> available, according to R-exts, this sounds like I should include "Suggests:
> Bar" in package Foo's description. But the manual is silent on how to treat
> Bar's namespace. Should I import it? If so, should this be conditional or
> unconditional? There is a thread from 2008 in which Duncan Murdoch suggests
> trying conditionally importing a package if it's installed, with the caveat
> "If this is allowed"
> (http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears to
> work in current release of R, 2.15.2, but I'm still not clear if it's
> officially allowed, much less recommended.
>
> The manual also says:
>
>> If a package only needs a few objects from another package it can use a
>> fully qualified variable reference in the code instead of a formal import. A
>> fully qualified reference to the function f in package foo is of the form
>> foo::f. This is slightly less efficient than a formal import and also loses
>> the advantage of recording all dependencies in the NAMESPACE file, so this
>> approach is usually not recommended. Evaluating foo::f will cause package
>> foo to be loaded, but not attached, if it was not loaded already—this can be
>> an advantage in delaying the loading of a rarely used package.
>>
>
>
> Would this be a better solution than importing when calling into a suggested
> package?
>
> Davor
>
>
> [[alternative HTML version deleted]]
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recommended way to call/import functions from a Suggested package
On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
> Hi Davor,
>
> To the best of my knowledge, there's only one way to use functions
> from a suggested package: with require:
>
> if (require("suggested_package")) {
> function_from_suggested_package()
> } else {
> stop("suggested package not installed")
> }
>
> Unfortunately I don't think there's any way to use a suggested package
> without polluting the search path.
I've always wondered: How does lattice manage to use grid functions without
putting them on the search path?
--
David
>
> Hadley
>
> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic wrote:
>> If in my package "Foo" I call a function from another package "Bar" if it's
>> available, according to R-exts, this sounds like I should include "Suggests:
>> Bar" in package Foo's description. But the manual is silent on how to treat
>> Bar's namespace. Should I import it? If so, should this be conditional or
>> unconditional? There is a thread from 2008 in which Duncan Murdoch suggests
>> trying conditionally importing a package if it's installed, with the caveat
>> "If this is allowed"
>> (http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears
>> to work in current release of R, 2.15.2, but I'm still not clear if it's
>> officially allowed, much less recommended.
>>
>> The manual also says:
>>
>>> If a package only needs a few objects from another package it can use a
>>> fully qualified variable reference in the code instead of a formal import.
>>> A fully qualified reference to the function f in package foo is of the form
>>> foo::f. This is slightly less efficient than a formal import and also loses
>>> the advantage of recording all dependencies in the NAMESPACE file, so this
>>> approach is usually not recommended. Evaluating foo::f will cause package
>>> foo to be loaded, but not attached, if it was not loaded already—this can
>>> be an advantage in delaying the loading of a rarely used package.
>>>
>>
>>
>> Would this be a better solution than importing when calling into a suggested
>> package?
>>
>> Davor
>>
>>
>>[[alternative HTML version deleted]]
>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Chief Scientist, RStudio
> http://had.co.nz/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recommended way to call/import functions from a Suggested package
On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:
>
> On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
>
>> Hi Davor,
>>
>> To the best of my knowledge, there's only one way to use functions
>> from a suggested package: with require:
>>
>> if (require("suggested_package")) {
>> function_from_suggested_package()
>> } else {
>> stop("suggested package not installed")
>> }
>>
>> Unfortunately I don't think there's any way to use a suggested package
>> without polluting the search path.
>
> I've always wondered: How does lattice manage to use grid functions without
> putting them on the search path?
Maybe I am using the wrong terminology, so here is the behavior I'm referring
to:
> sessionInfo()
snipped version an locale ino
attached base packages:
[1] grDevices datasets splines graphics utils stats methods base
other attached packages:
[1] rms_3.6-2 Hmisc_3.10-1survival_2.37-2 sos_1.3-5 brew_1.0-6
[6] lattice_0.20-10
loaded via a namespace (and not attached):
[1] cluster_1.14.3 grid_2.15.2
Notice that lattice is loaded from my profile
> require(ggplot2)
Loading required package: ggplot2
> sessionInfo()
snipped version an locale ino
attached base packages:
[1] grDevices datasets splines graphics utils stats methods base
other attached packages:
[1] ggplot2_0.9.3 rms_3.6-2 Hmisc_3.10-1survival_2.37-2 sos_1.3-5
[6] brew_1.0-6 lattice_0.20-10
loaded via a namespace (and not attached):
[1] cluster_1.14.3 colorspace_1.2-1 dichromat_2.0-0digest_0.6.0
[5] grid_2.15.2gtable_0.1.2 labeling_0.1 MASS_7.3-22
[9] munsell_0.4plyr_1.8 proto_0.3-10 RColorBrewer_1.0-5
[13] reshape2_1.2.2 scales_0.2.3 stringr_0.6.2
> ?grid.text
No documentation for ‘grid.text’ in specified packages and libraries:
you could try ‘??grid.text’
So at least the help system cannot find a grid function.
> ?grid::grid.text
starting httpd help server ... done
> grid.text
Error: object 'grid.text' not found
Neither can the R interpreter find it. But it's clearly available if you ask
nicely:
> grid::grid.text
function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"),
just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap =
FALSE,
default.units = "npc", name = NULL, gp = gpar(), draw = TRUE,
vp = NULL)
{
tg <- textGrob(label = label, x = x, y = y, just = just,
hjust = hjust, vjust = vjust, rot = rot, check.overlap = check.overlap,
default.units = default.units, name = name, gp = gp,
vp = vp)
if (draw)
grid.draw(tg)
invisible(tg)
}
--
David/
>
> --
> David
>>
>> Hadley
>>
>> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic wrote:
>>> If in my package "Foo" I call a function from another package "Bar" if it's
>>> available, according to R-exts, this sounds like I should include
>>> "Suggests: Bar" in package Foo's description. But the manual is silent on
>>> how to treat Bar's namespace. Should I import it? If so, should this be
>>> conditional or unconditional? There is a thread from 2008 in which Duncan
>>> Murdoch suggests trying conditionally importing a package if it's
>>> installed, with the caveat "If this is allowed"
>>> (http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears
>>> to work in current release of R, 2.15.2, but I'm still not clear if it's
>>> officially allowed, much less recommended.
>>>
>>> The manual also says:
>>>
If a package only needs a few objects from another package it can use a
fully qualified variable reference in the code instead of a formal import.
A fully qualified reference to the function f in package foo is of the
form foo::f. This is slightly less efficient than a formal import and also
loses the advantage of recording all dependencies in the NAMESPACE file,
so this approach is usually not recommended. Evaluating foo::f will cause
package foo to be loaded, but not attached, if it was not loaded
already—this can be an advantage in delaying the loading of a rarely used
package.
>>>
>>>
>>> Would this be a better solution than importing when calling into a
>>> suggested package?
>>>
>>> Davor
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>>
>> --
>> Chief Scientist, RStudio
>> http://had.co.nz/
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> David Winsemius
> Alameda, CA, USA
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
Re: [Rd] Recommended way to call/import functions from a Suggested package
Hi David: According to the description on cran, lattice imports grid.
I don't know if you've seen it but www.obeautifulcode.com has a very nice
topic in its archives called "How R Searches and Finds Stuff" which is
relatde to your question that I found it to be really helpful. A lot of
people on this list ( you know who they are as well as I do ) know it all
in their heads but, for me, sitting down and reading it was truly
enlightening. I think it should be required reading for anyone starting out
with R.
On Fri, Feb 22, 2013 at 9:50 PM, David Winsemius wrote:
>
> On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:
>
> >
> > On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
> >
> >> Hi Davor,
> >>
> >> To the best of my knowledge, there's only one way to use functions
> >> from a suggested package: with require:
> >>
> >> if (require("suggested_package")) {
> >> function_from_suggested_package()
> >> } else {
> >> stop("suggested package not installed")
> >> }
> >>
> >> Unfortunately I don't think there's any way to use a suggested package
> >> without polluting the search path.
> >
> > I've always wondered: How does lattice manage to use grid functions
> without putting them on the search path?
>
> Maybe I am using the wrong terminology, so here is the behavior I'm
> referring to:
>
> > sessionInfo()
> snipped version an locale ino
>
> attached base packages:
> [1] grDevices datasets splines graphics utils stats methods
> base
>
> other attached packages:
> [1] rms_3.6-2 Hmisc_3.10-1survival_2.37-2 sos_1.3-5
> brew_1.0-6
> [6] lattice_0.20-10
>
> loaded via a namespace (and not attached):
> [1] cluster_1.14.3 grid_2.15.2
>
> Notice that lattice is loaded from my profile
>
> > require(ggplot2)
> Loading required package: ggplot2
> > sessionInfo()
> snipped version an locale ino
> attached base packages:
> [1] grDevices datasets splines graphics utils stats methods
> base
>
> other attached packages:
> [1] ggplot2_0.9.3 rms_3.6-2 Hmisc_3.10-1survival_2.37-2
> sos_1.3-5
> [6] brew_1.0-6 lattice_0.20-10
>
> loaded via a namespace (and not attached):
> [1] cluster_1.14.3 colorspace_1.2-1 dichromat_2.0-0digest_0.6.0
> [5] grid_2.15.2gtable_0.1.2 labeling_0.1 MASS_7.3-22
> [9] munsell_0.4plyr_1.8 proto_0.3-10
> RColorBrewer_1.0-5
> [13] reshape2_1.2.2 scales_0.2.3 stringr_0.6.2
> > ?grid.text
> No documentation for grid.text in specified packages and libraries:
> you could try ??grid.text
>
> So at least the help system cannot find a grid function.
>
>
> > ?grid::grid.text
> starting httpd help server ... done
> > grid.text
> Error: object 'grid.text' not found
>
> Neither can the R interpreter find it. But it's clearly available if you
> ask nicely:
>
> > grid::grid.text
> function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"),
> just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap =
> FALSE,
> default.units = "npc", name = NULL, gp = gpar(), draw = TRUE,
> vp = NULL)
> {
> tg <- textGrob(label = label, x = x, y = y, just = just,
> hjust = hjust, vjust = vjust, rot = rot, check.overlap =
> check.overlap,
> default.units = default.units, name = name, gp = gp,
> vp = vp)
> if (draw)
> grid.draw(tg)
> invisible(tg)
> }
>
>
>
> --
> David/
>
> >
> > --
> > David
> >>
> >> Hadley
> >>
> >> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic
> wrote:
> >>> If in my package "Foo" I call a function from another package "Bar" if
> it's available, according to R-exts, this sounds like I should include
> "Suggests: Bar" in package Foo's description. But the manual is silent on
> how to treat Bar's namespace. Should I import it? If so, should this be
> conditional or unconditional? There is a thread from 2008 in which Duncan
> Murdoch suggests trying conditionally importing a package if it's
> installed, with the caveat "If this is allowed" (
> http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears
> to work in current release of R, 2.15.2, but I'm still not clear if it's
> officially allowed, much less recommended.
> >>>
> >>> The manual also says:
> >>>
> If a package only needs a few objects from another package it can use
> a fully qualified variable reference in the code instead of a formal
> import. A fully qualified reference to the function f in package foo is of
> the form foo::f. This is slightly less efficient than a formal import and
> also loses the advantage of recording all dependencies in the NAMESPACE
> file, so this approach is usually not recommended. Evaluating foo::f will
> cause package foo to be loaded, but not attached, if it was not loaded
> alreadythis can be an advantage in delaying the loading of a rarely used
> package.
>
> >>>
> >>>
> >>> Would this be a better solution than importing when calling into a
> suggested package?
> >>>
> >>> Davor
> >>>
> >>>
>
Re: [Rd] Recommended way to call/import functions from a Suggested package
david: I was slightly misleading about the usefulness of that link for your
question because it
doesn't explicitly talk about the case where base packages import packages.
But it talks about
the general case of importing so hopefully base handles importing just like
a package that would
be installed from cran.
On Fri, Feb 22, 2013 at 10:07 PM, Mark Leeds wrote:
> Hi David: According to the description on cran, lattice imports grid.
>
> I don't know if you've seen it but www.obeautifulcode.com has a very nice
> topic in its archives called "How R Searches and Finds Stuff" which is
> relatde to your question that I found it to be really helpful. A lot of
> people on this list ( you know who they are as well as I do ) know it all
> in their heads but, for me, sitting down and reading it was truly
> enlightening. I think it should be required reading for anyone starting out
> with R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Feb 22, 2013 at 9:50 PM, David Winsemius
> wrote:
>
>>
>> On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:
>>
>> >
>> > On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
>> >
>> >> Hi Davor,
>> >>
>> >> To the best of my knowledge, there's only one way to use functions
>> >> from a suggested package: with require:
>> >>
>> >> if (require("suggested_package")) {
>> >> function_from_suggested_package()
>> >> } else {
>> >> stop("suggested package not installed")
>> >> }
>> >>
>> >> Unfortunately I don't think there's any way to use a suggested package
>> >> without polluting the search path.
>> >
>> > I've always wondered: How does lattice manage to use grid functions
>> without putting them on the search path?
>>
>> Maybe I am using the wrong terminology, so here is the behavior I'm
>> referring to:
>>
>> > sessionInfo()
>> snipped version an locale ino
>>
>> attached base packages:
>> [1] grDevices datasets splines graphics utils stats methods
>> base
>>
>> other attached packages:
>> [1] rms_3.6-2 Hmisc_3.10-1survival_2.37-2 sos_1.3-5
>> brew_1.0-6
>> [6] lattice_0.20-10
>>
>> loaded via a namespace (and not attached):
>> [1] cluster_1.14.3 grid_2.15.2
>>
>> Notice that lattice is loaded from my profile
>>
>> > require(ggplot2)
>> Loading required package: ggplot2
>> > sessionInfo()
>> snipped version an locale ino
>> attached base packages:
>> [1] grDevices datasets splines graphics utils stats methods
>> base
>>
>> other attached packages:
>> [1] ggplot2_0.9.3 rms_3.6-2 Hmisc_3.10-1survival_2.37-2
>> sos_1.3-5
>> [6] brew_1.0-6 lattice_0.20-10
>>
>> loaded via a namespace (and not attached):
>> [1] cluster_1.14.3 colorspace_1.2-1 dichromat_2.0-0digest_0.6.0
>> [5] grid_2.15.2gtable_0.1.2 labeling_0.1 MASS_7.3-22
>> [9] munsell_0.4plyr_1.8 proto_0.3-10
>> RColorBrewer_1.0-5
>> [13] reshape2_1.2.2 scales_0.2.3 stringr_0.6.2
>> > ?grid.text
>> No documentation for grid.text in specified packages and libraries:
>> you could try ??grid.text
>>
>> So at least the help system cannot find a grid function.
>>
>>
>> > ?grid::grid.text
>> starting httpd help server ... done
>> > grid.text
>> Error: object 'grid.text' not found
>>
>> Neither can the R interpreter find it. But it's clearly available if you
>> ask nicely:
>>
>> > grid::grid.text
>> function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"),
>> just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap =
>> FALSE,
>> default.units = "npc", name = NULL, gp = gpar(), draw = TRUE,
>> vp = NULL)
>> {
>> tg <- textGrob(label = label, x = x, y = y, just = just,
>> hjust = hjust, vjust = vjust, rot = rot, check.overlap =
>> check.overlap,
>> default.units = default.units, name = name, gp = gp,
>> vp = vp)
>> if (draw)
>> grid.draw(tg)
>> invisible(tg)
>> }
>>
>>
>>
>> --
>> David/
>>
>> >
>> > --
>> > David
>> >>
>> >> Hadley
>> >>
>> >> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic
>> wrote:
>> >>> If in my package "Foo" I call a function from another package "Bar"
>> if it's available, according to R-exts, this sounds like I should include
>> "Suggests: Bar" in package Foo's description. But the manual is silent on
>> how to treat Bar's namespace. Should I import it? If so, should this be
>> conditional or unconditional? There is a thread from 2008 in which Duncan
>> Murdoch suggests trying conditionally importing a package if it's
>> installed, with the caveat "If this is allowed" (
>> http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This
>> appears to work in current release of R, 2.15.2, but I'm still not clear if
>> it's officially allowed, much less recommended.
>> >>>
>> >>> The manual also says:
>> >>>
>> If a package only needs a few objects from another package it can
>> use a fully qualified variable reference in the code instead of a formal
>> import. A fully qualified reference to the function f in package foo is of
Re: [Rd] Recommended way to call/import functions from a Suggested package
On Feb 22, 2013, at 9:13 PM, Hadley Wickham wrote:
> Hi Davor,
>
> To the best of my knowledge, there's only one way to use functions
> from a suggested package: with require:
>
> if (require("suggested_package")) {
> function_from_suggested_package()
> } else {
> stop("suggested package not installed")
> }
>
> Unfortunately I don't think there's any way to use a suggested package
> without polluting the search path.
>
Why -- wouldn't
if (is.function(try(foo::bar, silent=TRUE))) {
foo::bar(...)
}
do the job?
> Hadley
>
> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic wrote:
>> If in my package "Foo" I call a function from another package "Bar" if it's
>> available, according to R-exts, this sounds like I should include "Suggests:
>> Bar" in package Foo's description. But the manual is silent on how to treat
>> Bar's namespace. Should I import it? If so, should this be conditional or
>> unconditional? There is a thread from 2008 in which Duncan Murdoch suggests
>> trying conditionally importing a package if it's installed, with the caveat
>> "If this is allowed"
>> (http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears
>> to work in current release of R, 2.15.2, but I'm still not clear if it's
>> officially allowed, much less recommended.
>>
>> The manual also says:
>>
>>> If a package only needs a few objects from another package it can use a
>>> fully qualified variable reference in the code instead of a formal import.
>>> A fully qualified reference to the function f in package foo is of the form
>>> foo::f. This is slightly less efficient than a formal import and also loses
>>> the advantage of recording all dependencies in the NAMESPACE file, so this
>>> approach is usually not recommended. Evaluating foo::f will cause package
>>> foo to be loaded, but not attached, if it was not loaded already—this can
>>> be an advantage in delaying the loading of a rarely used package.
>>>
>>
>>
>> Would this be a better solution than importing when calling into a suggested
>> package?
>>
>> Davor
>>
>>
>>[[alternative HTML version deleted]]
>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Chief Scientist, RStudio
> http://had.co.nz/
>
> __
> 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] Recommended way to call/import functions from a Suggested package
On Friday, February 22, 2013, Simon Urbanek wrote:
>
> On Feb 22, 2013, at 9:13 PM, Hadley Wickham wrote:
>
> > Hi Davor,
> >
> > To the best of my knowledge, there's only one way to use functions
> > from a suggested package: with require:
> >
> > if (require("suggested_package")) {
> > function_from_suggested_package()
> > } else {
> > stop("suggested package not installed")
> > }
> >
> > Unfortunately I don't think there's any way to use a suggested package
> > without polluting the search path.
> >
>
> Why -- wouldn't
>
> if (is.function(try(foo::bar, silent=TRUE))) {
> foo::bar(...)
> }
>
> do the job?
>
>
I may be misremembering, but I think r cmd check complains about that.
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recommended way to call/import functions from a Suggested package
G'day David,
On Fri, 22 Feb 2013 18:50:07 -0800
David Winsemius wrote:
> On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:
[...]
> > I've always wondered: How does lattice manage to use grid functions
> > without putting them on the search path?
Because lattice imports the grid package and has a NAMESPACE (as have
all packages nowadays):
R> packageDescription("lattice")
Package: lattice
Version: 0.20-10
Date: 2012/08/21
[...]
Suggests: grid, KernSmooth, MASS
Imports: grid, grDevices, graphics, stats, utils, methods
[...]
And the relevant information is not in the "Writing R Extensions"
manual but in section 3.5.4 of the "R Language Definition" manual:
Packages which have a @emph{namespace} have a different search
path. When a search for an @R{} object is started from an
object in such a package, the package itself is searched first,
then its imports, then the base namespace and finally the
global environment and the rest of the regular search path.
The effect is that references to other objects in the same
package will be resolved to the package, and objects cannot be
masked by objects of the same name in the global environment or
in other packages.
Thus, as grid is imported by lattice, it is loaded but not attached
(i.e. does not appear in the search path). However, function in the
lattice package will find functions in the grid package as the imports
are searched.
> Neither can the R interpreter find it. But it's clearly available if
> you ask nicely:
>
> > grid::grid.text
This will always work, whether the grid package is loaded/attached or
not:
R> sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: x86_64-unknown-linux-gnu/64 (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils dataset methods base
loaded via a namespace (and not attached):
[1] tools_2.15.2
R> grid::grid.text
function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"),
just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap =
FALSE,
default.units = "npc", name = NULL, gp = gpar(), draw = TRUE,
vp = NULL)
{
tg <- textGrob(label = label, x = x, y = y, just = just,
hjust = hjust, vjust = vjust, rot = rot, check.overlap = check.overlap,
default.units = default.units, name = name, gp = gp,
vp = vp)
if (draw)
grid.draw(tg)
invisible(tg)
}
You specifically asked R to get object grid.text from the grid
package, so R obliges to do so. For the help system to find the help
pages on an object, the package that contains the help pages has to be
on the search path AFAIK.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
