Re: [Rd] Possible tweak to R intro - was RE: [R] Subseting a data.frame -
Thank you. I stand corrected. Cheers, Bert On Mon, Oct 21, 2013 at 1:17 AM, Prof Brian Ripley wrote: > On 18/10/2013 15:12, S Ellison wrote: >> >> Transferred from R-help: >>>> >>>> From: S Ellison >>>> Subsetting using subset() is perhaps the most natural way of >>>> subsetting data frames; perhaps a line or two and an example could >>>> usefully be included in the 'Working with data frames' section of the R >>>> Intro? >>> >>> >>> From: Bert Gunter [mailto:gunter.ber...@gene.com] >>> The R Intro Manual was largely or entirely the work of Bill Venables >>> some years ago. So it is not really a part of R's maintained document >>> system and has thus not been kept up to date with changes like the >>> convenience function, subset(), which is basically a wrapper for "[]" >>> . >>> >>> This is not to say that your suggestion is not worthwhile, only to >>> explain why it probably won't be acted upon. > > > No, this is deliberate and R-intro is kept up-to-date (although it remains > an introduction, not a full manual). > > Some of us think convenience functions such as subset() and transform() were > mistakes, not least as we see the problems they cause when people try to use > them in functions and packages. Sooner or later you will need to learn to > use indexing, and knowing about two systems with different scoping rules is > too confusing for quite a few R users. > >> >> It's trivial enough that I could offer a 3-line patch if someone has time >> and inclination to add it... >> >> S Ellison > > > -- > 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 -- Bert Gunter Genentech Nonclinical Biostatistics (650) 467-7374 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Determining files opened by an R session
I am not sure R can do what you want (others may), but have a look at ?history for R's history mechanism, which keeps a record of all commands that you have entered and so might satisfy your needs. Note that there are various 3rd party GUI's/IDE's (e.g. RStudio) that might be more to your liking. The CRAN web site should contain information on at least some of them. Cheers, Bert On Mon, Nov 4, 2013 at 1:32 PM, Martin Gregory wrote: > I'm using R in a regulated environment and one of the requirements is to be > able to trace how a result is arrived at. I would like to be able to > determine which files are opened in read or write mode by an R session, for > example when a program uses source, sink, file, open, read.table, > write.table or any of the other functions which can be used to read or write > files. I'm also interested in output to graphics devices. > > I've looked in the documentation but only found information relating to > profiling. Looking through the source code it seems that much file i/o is > done via the C functions *_open in main/connections.c but don't see anything > there that looks like logging. > > Could someone let me know if it is possible to log which files are opened? > > Regards, > Martin Gregory > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Bert Gunter Genentech Nonclinical Biostatistics (650) 467-7374 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Define 'in' for new class
See the 'iterators' package on CRAN. -- Bert Bert Gunter Genentech Nonclinical Biostatistics (650) 467-7374 "Data is not information. Information is not knowledge. And knowledge is certainly not wisdom." Clifford Stoll On Tue, Aug 12, 2014 at 12:28 AM, peter dalgaard wrote: > > On 12 Aug 2014, at 08:29 , Simon Knapp wrote: > >> Hi List, >> >> Is it possible to define how 'in' works for an object of a specific class >> (to achieve a similar result to implementing the iterator protocol in a >> class Python)? >> > > No, because 'in' doesn't really exist, it is "syntactic sugar" to sweeten a > call to the "for" function with its three arguments. E.g. > >> `for`(i,1:2,print(i)) > [1] 1 > [1] 2 > > So what you're really asking for is something like a `for` with class > dispatch or the two first arguments replaced by an iterator mechanism. That's > not in the cards, at least at the moment, but I suppose it isn't completely > out of the question either -- ideas of this sort get bandied around > occasionally. It would require changes to R's internals; it is not something > you can do in (say) a package. > > >> Cheers, >> Simon Knapp >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > > __ > 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] Re R CMD check checking in development version of R
This is a nice explanation of the Imports/Depends distinction. It ought to go into the Extensions ref manual imho. Cheers, Bert Bert Gunter Genentech Nonclinical Biostatistics (650) 467-7374 "Data is not information. Information is not knowledge. And knowledge is certainly not wisdom." Clifford Stoll On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek wrote: > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: > >> On 27 August 2014 15:24, Hadley Wickham wrote: >> >>>> Is that the cause of these NOTEs? Is the expectation that if I am using a >>>> function from a package, even a package that I have in Depends:, that I >>>> have to explicitly declare these imports in NAMESPACE? >>> >>> Yes. >>> >>> (Otherwise your package won't work if it's only attached and not >>> loaded. i.e. if someone does analogue::foo() only the imported >>> functions are available, not the functions in packages you depend on) >>> >> >> Cheers Hadley. Thanks for the confirmation, but... >> >> ...I don't get this; what is the point of Depends? I thought it was "my >> package needs these other packages to work, i.e. be loaded". Hence it is >> user error (IMHO ;-) to do `analogue::foo()` without having the >> dependencies loaded too. >> > > No. The point of Depends is that if your package is attached, it also > attaches the other packages to make them available for the user. Essentially > you're saying "if you want to use my package interactively, you will also > want to use those other packages interactively". You still need to use > import() to define what exactly is used by your package - as opposed to what > you want to be available to the user in case it is attached. > > Cheers, > Simon > > > >> This check (whilst having found some things I should have imported and >> didn't - which is a good thing!) seems to be circumventing the intention of >> having something in Depends. Is Depends going to go away? >> >> >>> (And really you shouldn't have any packages in depends, they should >>> all be in imports) >> >> >> I disagree with *any*; having say vegan loaded when one is using analogue >> is a design decision as the latter borrows heavily from and builds upon >> vegan. In general I have moved packages that didn't need to be in Depends >> into Imports; in the version I am currently doing final tweaks on before it >> goes to CRAN I have remove all but vegan from Depends. >> >> Or am I thinking about this in the wrong way? >> >> Thanks again >> >> Gavin >> >> >>> >>> Hadley >>> >>> >>> -- >>> http://had.co.nz/ >>> >> >> >> >> -- >> Gavin Simpson, PhD >> >> [[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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Language Definition: Subsetting matrices with negative indices is *not* an error
Ah, the woes of English word order -- even this native English speaker frequently gets messed up! (but maybe I'm just a bear of little brain). Best, Bert Bert Gunter Genentech Nonclinical Biostatistics (650) 467-7374 "Data is not information. Information is not knowledge. And knowledge is certainly not wisdom." Clifford Stoll On Sat, May 9, 2015 at 1:33 PM, Henrik Bengtsson wrote: > On Sat, May 9, 2015 at 12:55 AM, peter dalgaard wrote: >> >>> On 09 May 2015, at 02:53 , Henrik Bengtsson >>> wrote: >>> >>> Hi, >>> >>> I spotted what looks like another(*) mistake in 'R Language >>> Definition' on how subsetting should work. In Section 'Indexing >>> matrices and arrays' >>> [http://cran.r-project.org/doc/manuals/r-release/R-lang.html#Indexing-matrices-and-arrays] >>> one can read >>> >>> "Negative indices are not allowed in indexing matrices." >> >> Parse error: I believe that this is intended to mean >> >> "Indexing matrices may not contain negative indices" >> >> not >> >> "You cannot use negative indices when indexing matrices". >> >> This is consistent with the help page: >> >> " >> A third form of indexing is via a numeric matrix with the one >> column for each dimension: each row of the index matrix then >> selects a single element of the array, and the result is a vector. >> Negative indices are not allowed in the index matrix. >> " >> >> Rephrasing would seem to be in order > > Ah... definitely a "parse error" (I read it as a new paragraph). I > second rephrasing this; your ""Indexing matrices may not contain > negative indices" is non-ambiguous. > > Thanks Peter > > /Henrik > >> >> -pd >> >>> >>> but this is not true, e.g. >>> >>>> x <- matrix(1:12, nrow=4) >>>> x >>> [,1] [,2] [,3] >>> [1,]159 >>> [2,]26 10 >>> [3,]37 11 >>> [4,]48 12 >>> >>>> x[c(-2,-4),] >>> [,1] [,2] [,3] >>> [1,]159 >>> [2,]37 11 >>> >>> /Henrik >>> >>> (*) https://stat.ethz.ch/pipermail/r-devel/2015-May/071091.html [docs >>> have been fixed] >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> -- >> Peter Dalgaard, Professor, >> Center for Statistics, Copenhagen Business School >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark >> Phone: (+45)38153501 >> Email: pd@cbs.dk Priv: pda...@gmail.com >> >> >> >> >> >> >> >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build/check on Windows 7
Folks: sessionInfo() R version 2.15.0 (2012-03-30) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] datasets splines grid tcltk stats graphics grDevices [8] utils methods base other attached packages: [1] svSocket_0.9-51 lattice_0.19-26 MASS_7.3-17 loaded via a namespace (and not attached): [1] cluster_1.14.2 Hmisc_3.9-3R2HTML_2.2 svMisc_0.9-65 TinnR_1.0-5 [6] tools_2.15.0 According to section 1.3 of the WRITING R EXTENSIONS manual, both R CMD build and R CMD check run R with the '--vanilla' option so no user startup files are read. However, 1. If I have an Rprofile.site in my etc startup directory, if I am in the ...\top directory and try to check or build the top\mypackage source package, I can only do so by giving (in the Windows shell, of course) the full path name to R CMD build/check, e.g. R CMD build pathtoTop\top\mypackage . R CMD build mypackage yields the error: ERROR cannot change to directory 'test' 2. However, if I remove (e.g. change the name) of Rprofile.site, then R CMD build/check mypackage works fine. Note that my Rprofile.site file DOES contain a setwd() statement to some other directory; if I comment out this statement, then I also do not need to use the full path name even with the Rprofile.site file there. So my question is: Is the documentation wrong? -- Is there an environmental variable or option I need to set/change? -- Is this a Windows "feature" subtlety? Many thanks. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Convenience function to get unevaluated ... function arguments
Folks:
Herein is a suggestion for a little R convenience function mainly to
obtain unevaluated ... function arguments. It arose from a query on
R-help on how to get these arguments. The standard (I think) idiom to
do this is via
match.call(expand.dots=FALSE)$...
However, Bill Dunlap pointed out that this repeats the argument
matching of the function call and suggested a couple of alternatives
that do not, one of which I've adapted as the following function,fun
(I'll comment on naming in a second):
fun <- as.list(substitute((...), env = parent.frame()))[-1]
Typical usage would be:
f <- function(x, ...,y)fun()
e.g.
> f(x = 5,z=sin(a),y=3,stop("oh"),w=warning("Yikes"))
$z
sin(a)
[[2]]
stop("oh")
$w
warning("Yikes")
It turns out that (surprisingly to me) the substitute idiom is faster
than the match.call idiom, although the difference appears
unimportant, since both are so fast. And it is a little slower when
wrapped into a function, anyway -- I wasn't able to figure out a
convenient way to wrap the match.call version into a function.
The question is where -- if anywhere -- should this little one-liner
go? Seems to me that there are 3 possibilities:
1. Nowhere. Unnecessary and trivial. An entirely reasonable response,
imho; I leave it to guRus to make this judgment.
2. In with match.call(); in which case a name like match.dots would
seem appropriate.
3. In with substitute(); in which case something like substituteDots
to make the relationship clear might be appropriate.
If R core or others do want to use this, I would be happy to write the
line or two of additional documentation required (if no one else wants
to).
And to repeat... I know this is trivial, so no explanation or response
is needed if it is decided to ignore it.
Best,
Bert
--
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] Convenience function to get unevaluated ... function arguments
Indeed!
-- Bert
On Wed, Jul 25, 2012 at 3:59 PM, David Winsemius wrote:
>
> On Jul 24, 2012, at 4:39 PM, Bert Gunter wrote:
>
>> Folks:
>>
>> Herein is a suggestion for a little R convenience function mainly to
>> obtain unevaluated ... function arguments. It arose from a query on
>> R-help on how to get these arguments. The standard (I think) idiom to
>> do this is via
>>
>> match.call(expand.dots=FALSE)$...
>>
>> However, Bill Dunlap pointed out that this repeats the argument
>> matching of the function call and suggested a couple of alternatives
>> that do not, one of which I've adapted as the following function,fun
>> (I'll comment on naming in a second):
>>
>> fun <- as.list(substitute((...), env = parent.frame()))[-1]
>
>
> I think instead:
>
> fun <- function() as.list(substitute((...), env = parent.frame()))[-1]
>
> --
> David.
>>
>>
>> Typical usage would be:
>>
>> f <- function(x, ...,y)fun()
>>
>> e.g.
>>
>>> f(x = 5,z=sin(a),y=3,stop("oh"),w=warning("Yikes"))
>>
>> $z
>> sin(a)
>>
>> [[2]]
>> stop("oh")
>>
>> $w
>> warning("Yikes")
>>
>> It turns out that (surprisingly to me) the substitute idiom is faster
>> than the match.call idiom, although the difference appears
>> unimportant, since both are so fast. And it is a little slower when
>> wrapped into a function, anyway -- I wasn't able to figure out a
>> convenient way to wrap the match.call version into a function.
>>
>> The question is where -- if anywhere -- should this little one-liner
>> go? Seems to me that there are 3 possibilities:
>> 1. Nowhere. Unnecessary and trivial. An entirely reasonable response,
>> imho; I leave it to guRus to make this judgment.
>>
>> 2. In with match.call(); in which case a name like match.dots would
>> seem appropriate.
>>
>> 3. In with substitute(); in which case something like substituteDots
>> to make the relationship clear might be appropriate.
>>
>> If R core or others do want to use this, I would be happy to write the
>> line or two of additional documentation required (if no one else wants
>> to).
>>
>> And to repeat... I know this is trivial, so no explanation or response
>> is needed if it is decided to ignore it.
>>
>> Best,
>> Bert
>>
>>
>>
>>
>> --
>>
>> 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
>
>
> David Winsemius, MD
> Heritage Laboratories
> West Hartford, CT
>
--
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] Convenience function to get unevaluated ... function arguments
Feel free.
-- Bert
On Thu, Jul 26, 2012 at 7:52 AM, Warnes, Gregory
wrote:
> I'll be glad to add it to the gtools package if it doesn't (immediately) go
> into one of the core packages.
>
> Sent from my iPhone
>
> On Jul 26, 2012, at 7:35 AM, "Bert Gunter" wrote:
>
>> Indeed!
>>
>> -- Bert
>>
>> On Wed, Jul 25, 2012 at 3:59 PM, David Winsemius
>> wrote:
>>>
>>> On Jul 24, 2012, at 4:39 PM, Bert Gunter wrote:
>>>
>>>> Folks:
>>>>
>>>> Herein is a suggestion for a little R convenience function mainly to
>>>> obtain unevaluated ... function arguments. It arose from a query on
>>>> R-help on how to get these arguments. The standard (I think) idiom to
>>>> do this is via
>>>>
>>>> match.call(expand.dots=FALSE)$...
>>>>
>>>> However, Bill Dunlap pointed out that this repeats the argument
>>>> matching of the function call and suggested a couple of alternatives
>>>> that do not, one of which I've adapted as the following function,fun
>>>> (I'll comment on naming in a second):
>>>>
>>>> fun <- as.list(substitute((...), env = parent.frame()))[-1]
>>>
>>>
>>> I think instead:
>>>
>>> fun <- function() as.list(substitute((...), env = parent.frame()))[-1]
>>>
>>> --
>>> David.
>>>>
>>>>
>>>> Typical usage would be:
>>>>
>>>> f <- function(x, ...,y)fun()
>>>>
>>>> e.g.
>>>>
>>>>> f(x = 5,z=sin(a),y=3,stop("oh"),w=warning("Yikes"))
>>>>
>>>> $z
>>>> sin(a)
>>>>
>>>> [[2]]
>>>> stop("oh")
>>>>
>>>> $w
>>>> warning("Yikes")
>>>>
>>>> It turns out that (surprisingly to me) the substitute idiom is faster
>>>> than the match.call idiom, although the difference appears
>>>> unimportant, since both are so fast. And it is a little slower when
>>>> wrapped into a function, anyway -- I wasn't able to figure out a
>>>> convenient way to wrap the match.call version into a function.
>>>>
>>>> The question is where -- if anywhere -- should this little one-liner
>>>> go? Seems to me that there are 3 possibilities:
>>>> 1. Nowhere. Unnecessary and trivial. An entirely reasonable response,
>>>> imho; I leave it to guRus to make this judgment.
>>>>
>>>> 2. In with match.call(); in which case a name like match.dots would
>>>> seem appropriate.
>>>>
>>>> 3. In with substitute(); in which case something like substituteDots
>>>> to make the relationship clear might be appropriate.
>>>>
>>>> If R core or others do want to use this, I would be happy to write the
>>>> line or two of additional documentation required (if no one else wants
>>>> to).
>>>>
>>>> And to repeat... I know this is trivial, so no explanation or response
>>>> is needed if it is decided to ignore it.
>>>>
>>>> Best,
>>>> Bert
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> 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
>>>
>>>
>>> David Winsemius, MD
>>> Heritage Laboratories
>>> West Hartford, CT
>>>
>>
>>
>>
>> --
>>
>> 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
--
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] Numerics behind splineDesign
Well, I would first check the references given in the Help file!. That's what they're for, no? Hastie's book is likely to more complete on the algebra, I think. You might also be interested in the relevant chapters of Friedman, Hastie, et. al "The Elements of Statistical Learning Theory," which might be a gentler exposition of the math. Of course, the code (or a suitable exposition of it, which may not exist) is the ultimate reference. -- Bert On Tue, Jul 31, 2012 at 6:25 AM, Ben Bolker wrote: > Nathaniel Smith pobox.com> writes: > >> I find myself needing to be able to reproduce the spline bases that R >> computes when using ns() and bs() -- but without using R. Before I go >> diving headfirst into the C code in >> ./src/library/splines/src/splines.c, are there any simpler references >> anyone might recommend? > > [snip] > > Some of this stuff *might* be in the "White Book" (Statistical > Models in S, ed Chambers & Hastie (esp. chapter 7?) > > Ben Bolker > > ______ > 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] Numerics behind splineDesign
Inline... On Wed, Aug 1, 2012 at 8:36 AM, Nathaniel Smith wrote: > Thanks everyone for the suggestions. > > On Wed, Aug 1, 2012 at 2:39 PM, peter dalgaard wrote: >> >> On Jul 31, 2012, at 15:46 , Bert Gunter wrote: >> >>> Well, I would first check the references given in the Help file!. >>> That's what they're for, no? Hastie's book is likely to more complete >>> on the algebra, I think. > > How embarrassing... the help files do cite the white book (only), and > I did check it of course, but it has no more details on how the basis > functions are computed than does the help file itself, and so I must > have forgotten about it when writing my email. Still, my apologies for > the confusion. > > I'm not sure what you mean by "Hastie's book", though? Ummm... The following appears in the ?bs man page. Why do you not see it? Are you perhaps being too "hasty" in your reading (heh-heh)? References Hastie, T. J. (1992) Generalized additive models. Chapter 7 of Statistical Models in S eds J. M. Chambers and T. J. Hastie, Wadsworth & Brooks/Cole. -- Bert > >>> You might also be interested in the relevant chapters of Friedman, >>> Hastie, et. al "The Elements of Statistical Learning Theory," which >>> might be a gentler exposition of the math. >>> >>> Of course, the code (or a suitable exposition of it, which may not >>> exist) is the ultimate reference. >> >> Also check out the various web resources (Google for basis spline or >> B-spline). I don't recall the white book chapter, but it might be a little >> short on the algebraic details. Another Google point is "de Boor". > > And indeed, it looks like the appendix to chapter 5 of Hastie, > Tibshirani, and Friedman (2008) has a short description of the de Boor > algorithm. Excellent. For the archives, this seems to be enough to > exactly implement spline.des/splineDesign, and if anyone else is > working in Python then it turns out that there is a more-or-less > undocumented implementation of this algorithm in > scipy.interpolate.splev. > > Now I just have to grovel over the R code in ns() and bs() to figure > out how exactly they pick knots and handle boundary conditions, plus > there is some code that I don't understand in ns() that uses qr() to > postprocess the output from spline.des. I assume this is involved > somehow in imposing the boundary conditions... > > Thanks again everyone for your help, > -- Nathaniel -- 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] Numerics behind splineDesign
Thanks Peter. So it was I who was being too "hasty." (heh-heh).* -- Bert *Yes, it was bad once. So twice makes it ... what, pathetic? On Wed, Aug 1, 2012 at 9:17 AM, peter dalgaard wrote: > > On Aug 1, 2012, at 18:03 , Bert Gunter wrote: > >> Inline... >> >> On Wed, Aug 1, 2012 at 8:36 AM, Nathaniel Smith wrote: >>> Thanks everyone for the suggestions. >>> >>> On Wed, Aug 1, 2012 at 2:39 PM, peter dalgaard wrote: >>>> >>>> On Jul 31, 2012, at 15:46 , Bert Gunter wrote: >>>> >>>>> Well, I would first check the references given in the Help file!. >>>>> That's what they're for, no? Hastie's book is likely to more complete >>>>> on the algebra, I think. >>> >>> How embarrassing... the help files do cite the white book (only), and >>> I did check it of course, but it has no more details on how the basis >>> functions are computed than does the help file itself, and so I must >>> have forgotten about it when writing my email. Still, my apologies for >>> the confusion. >>> >>> I'm not sure what you mean by "Hastie's book", though? >> >> Ummm... The following appears in the ?bs man page. Why do you not >> see it? Are you perhaps being too "hasty" in your reading (heh-heh)? >> >> References >> >> Hastie, T. J. (1992) Generalized additive models. Chapter 7 of >> Statistical Models in S eds J. M. Chambers and T. J. Hastie, Wadsworth >> & Brooks/Cole. > > It's not Hastie's book, though It's his chapter in a book edited by > Chambers and Hastie. > > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > > > > > > > > -- 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] virus and malicious code
... and note additionally, as per section 1.5.3, "Windows External Software" of the "Writing R Extensions" manual: "Note that CRAN does not accept submissions of precompiled binaries due to security concerns,and does not allow binary executables in source packages." -- Cheers, Bert On Mon, Aug 6, 2012 at 6:39 AM, Uwe Ligges wrote: > > > On 06.08.2012 15:09, David L Lorenz wrote: >> >> Hi, >>A question has come up within a user group about the possibility of >> viruses or other malicious code being embedded within any package served >> from CRAN. How much checking is done to guard against this? > > > Of course, CRAN cannot guarantee that packages are free of malicious code, > otherwise manual inspection of the code of almost 4000 packages with dozens > of updates and new submissions a day would be necessary. > > CRAN does some checks on the precompiled binaries for viruses, but again > cannot give guarantees. Please use the normal precautions with downloaded > executables. > > > Best, > Uwe Ligges > > > >> I do not >> expect any kind of response about picking up R code from any other source, >> like gitHub. Thanks. > > > >> Dave >> [[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 -- 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] Quiz: How to get a "named column" from a data frame
Yes, but either drop(t(df[,1,drop=TRUE])) or t(df[,1,drop=TRUE])[1,] does work. My minimal effort to check timings found that the first version was a hair faster. -- Bert On Sat, Aug 18, 2012 at 9:01 AM, Rui Barradas wrote: > Hello, > > A bit more general > > nv <- c(a=1, d=17, e=101); nv > nv2 <- c(a="a", d="d", e="e") > df2 <- data.frame(VAR = nv, CHAR = nv2); df2 > > identical( nv, drop(t( df2[1] )) ) # TRUE > identical( nv, drop(t( df2[[1]] )) ) # FALSE > > Rui Barradas > > Em 18-08-2012 16:16, Joshua Ulrich escreveu: >> >> I don't know if this is better, but it's the most obvious/shortest I >> could come up with. Transpose the data.frame column to a 'row' vector >> and drop the dimensions. >> >> R> identical(nv, drop(t(df))) >> [1] TRUE >> >> Best, >> -- >> Joshua Ulrich | about.me/joshuaulrich >> FOSS Trading | www.fosstrading.com >> >> >> On Sat, Aug 18, 2012 at 10:03 AM, Martin Maechler >> wrote: >>> >>> Today, I was looking for an elegant (and efficient) way >>> to get a named (atomic) vector by selecting one column of a data frame. >>> Of course, the vector names must be the rownames of the data frame. >>> >>> Ok, here is the quiz, I know one quite "cute"/"slick" answer, but was >>> wondering if there are obvious better ones, and >>> also if this should not become more idiomatic (hence "R-devel"): >>> >>> Consider this toy example, where the dataframe already has only >>> one column : >>> >>>> nv <- c(a=1, d=17, e=101); nv >>> >>>a d e >>>1 17 101 >>> >>>> df <- as.data.frame(cbind(VAR = nv)); df >>> >>>VAR >>> a 1 >>> d 17 >>> e 101 >>> >>> Now how, can I get 'nv' back from 'df' ? I.e., how to get >>> >>>> identical(nv, ...) >>> >>> [1] TRUE >>> >>> where .. only uses 'df' (and no non-standard R packages)? >>> >>> As said, I know a simple solution (*), but I'm sure it is not >>> obvious to most R users and probably not even to the majority of >>> R-devel readers... OTOH, people like Bill Dunlap will not take >>> long to provide it or a better one. >>> >>> (*) In my solution, the above '...' consists of 17 letters. >>> I'll post it later today (CEST time) ... or confirm >>> that someone else has done so. >>> >>> Martin >>> >>> __ >>> 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 > > > __ > 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] Quiz: How to get a "named column" from a data frame
Or to expand just a hair on Joshua's suggestion, is the following what you want: > x <- 1:10 > names(x) <- letters[1:10] > x a b c d e f g h i j 1 2 3 4 5 6 7 8 9 10 > df <- data.frame(x=x,y=LETTERS[1:10],row.names=names(x)) > df x y a 1 A b 2 B c 3 C d 4 D e 5 E f 6 F g 7 G h 8 H i 9 I j 10 J > y <- t(df[,1,drop=FALSE])[1,] > y a b c d e f g h i j 1 2 3 4 5 6 7 8 9 10 > identical(x,y) [1] TRUE Cheers, Bert On Sat, Aug 18, 2012 at 8:16 AM, Joshua Ulrich wrote: > I don't know if this is better, but it's the most obvious/shortest I > could come up with. Transpose the data.frame column to a 'row' vector > and drop the dimensions. > > R> identical(nv, drop(t(df))) > [1] TRUE > > Best, > -- > Joshua Ulrich | about.me/joshuaulrich > FOSS Trading | www.fosstrading.com > > > On Sat, Aug 18, 2012 at 10:03 AM, Martin Maechler > wrote: >> Today, I was looking for an elegant (and efficient) way >> to get a named (atomic) vector by selecting one column of a data frame. >> Of course, the vector names must be the rownames of the data frame. >> >> Ok, here is the quiz, I know one quite "cute"/"slick" answer, but was >> wondering if there are obvious better ones, and >> also if this should not become more idiomatic (hence "R-devel"): >> >> Consider this toy example, where the dataframe already has only >> one column : >> >>> nv <- c(a=1, d=17, e=101); nv >> a d e >> 1 17 101 >> >>> df <- as.data.frame(cbind(VAR = nv)); df >> VAR >> a 1 >> d 17 >> e 101 >> >> Now how, can I get 'nv' back from 'df' ? I.e., how to get >> >>> identical(nv, ...) >> [1] TRUE >> >> where .. only uses 'df' (and no non-standard R packages)? >> >> As said, I know a simple solution (*), but I'm sure it is not >> obvious to most R users and probably not even to the majority of >> R-devel readers... OTOH, people like Bill Dunlap will not take >> long to provide it or a better one. >> >> (*) In my solution, the above '...' consists of 17 letters. >> I'll post it later today (CEST time) ... or confirm >> that someone else has done so. >> >> Martin >> >> __ >> 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 -- 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] Quiz: How to get a "named column" from a data frame
Sorry! -- Change that to drop = FALSE ! drop(t(df[,1,drop=FALSE])) t(df[,1,drop=FALSE])[1,] -- Bert On Sat, Aug 18, 2012 at 9:37 AM, Bert Gunter wrote: > Yes, but either > > drop(t(df[,1,drop=TRUE])) > > or > > t(df[,1,drop=TRUE])[1,] > > does work. My minimal effort to check timings found that the first > version was a hair faster. > > -- Bert > > On Sat, Aug 18, 2012 at 9:01 AM, Rui Barradas wrote: >> Hello, >> >> A bit more general >> >> nv <- c(a=1, d=17, e=101); nv >> nv2 <- c(a="a", d="d", e="e") >> df2 <- data.frame(VAR = nv, CHAR = nv2); df2 >> >> identical( nv, drop(t( df2[1] )) ) # TRUE >> identical( nv, drop(t( df2[[1]] )) ) # FALSE >> >> Rui Barradas >> >> Em 18-08-2012 16:16, Joshua Ulrich escreveu: >>> >>> I don't know if this is better, but it's the most obvious/shortest I >>> could come up with. Transpose the data.frame column to a 'row' vector >>> and drop the dimensions. >>> >>> R> identical(nv, drop(t(df))) >>> [1] TRUE >>> >>> Best, >>> -- >>> Joshua Ulrich | about.me/joshuaulrich >>> FOSS Trading | www.fosstrading.com >>> >>> >>> On Sat, Aug 18, 2012 at 10:03 AM, Martin Maechler >>> wrote: >>>> >>>> Today, I was looking for an elegant (and efficient) way >>>> to get a named (atomic) vector by selecting one column of a data frame. >>>> Of course, the vector names must be the rownames of the data frame. >>>> >>>> Ok, here is the quiz, I know one quite "cute"/"slick" answer, but was >>>> wondering if there are obvious better ones, and >>>> also if this should not become more idiomatic (hence "R-devel"): >>>> >>>> Consider this toy example, where the dataframe already has only >>>> one column : >>>> >>>>> nv <- c(a=1, d=17, e=101); nv >>>> >>>>a d e >>>>1 17 101 >>>> >>>>> df <- as.data.frame(cbind(VAR = nv)); df >>>> >>>>VAR >>>> a 1 >>>> d 17 >>>> e 101 >>>> >>>> Now how, can I get 'nv' back from 'df' ? I.e., how to get >>>> >>>>> identical(nv, ...) >>>> >>>> [1] TRUE >>>> >>>> where .. only uses 'df' (and no non-standard R packages)? >>>> >>>> As said, I know a simple solution (*), but I'm sure it is not >>>> obvious to most R users and probably not even to the majority of >>>> R-devel readers... OTOH, people like Bill Dunlap will not take >>>> long to provide it or a better one. >>>> >>>> (*) In my solution, the above '...' consists of 17 letters. >>>> I'll post it later today (CEST time) ... or confirm >>>> that someone else has done so. >>>> >>>> Martin >>>> >>>> __ >>>> 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 >> >> >> __ >> 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 -- 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] Arrays Partial unserialization
1. I believe this is an R-Help, not an R-devel topic. Post there. 2. It is not clear to me from your post how the arrays are stored -- as .Rdata files or in some original tabular or database format. I believe the answer would depend on clarifying that point -- or on others understanding what I do not. -- Bert On Fri, Aug 31, 2012 at 6:47 AM, Damien Georges wrote: > Hi all, > > I'm working with some huge array in R and I need to load several ones to > apply some functions that requires to have all my arrays values for each > cell... > > To make it possible, I would like to load only a part (for example 100 > cells) of all my arrays, apply my function, delete all cells loaded, loaded > following cells and so on. > > Is it possible to unserialize (or load) only a defined part of an R array ? > Do you know some tools that might help me? > > Finally, I did lot of research to find the way array (and all other R > object) are serialized into binary object, but I found nothing explaining > really algorithms involved. If someone has some information on this topic, > I'm interesting in. > > Hoping my request is understandable, > > All the best, > > Damien.G > > __** > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/**listinfo/r-devel<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 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Advice on Namespaces
Hi Folks: I'm writing a little package that may not ever hit CRAN or even be distributed beyond a relatively narrow audience at my company. Nevertheless, I have tried to adhere to practices that would work if it were. With that in mind, I have read the Writing R Extensions Manual (and my humble kudos to its writers, as it has successfully guided even an ignoramus like myself ) and Luke Tierney's R Newsletter documentation on Namespaces. However, it is still not clear to me (see above ignoramus comment!) what functions -- and especially which S3 methods whose generics I define in my package -- should be exported and which should not. Perusing other packages also didn't reveal any clear patterns from which I could infer best practice. So may I ask for advice or any references that would provide such guidelines. Feel free to keep replies private if this query in not appropriate for this list. Many thanks. Cheers, Bert -- 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] Advice on Namespaces
Thanks Duncan. This was very helpful. -- Bert On Tue, Sep 11, 2012 at 4:05 AM, Duncan Murdoch wrote: > On 12-09-10 12:11 PM, Bert Gunter wrote: >> >> Hi Folks: >> >> I'm writing a little package that may not ever hit CRAN or even be >> distributed beyond a relatively narrow audience at my company. >> Nevertheless, I have tried to adhere to practices that would work if >> it were. With that in mind, I have read the Writing R Extensions >> Manual (and my humble kudos to its writers, as it has successfully >> guided even an ignoramus like myself ) and Luke Tierney's R Newsletter >> documentation on Namespaces. However, it is still not clear to me (see >> above ignoramus comment!) what functions -- and especially which S3 >> methods whose generics I define in my package -- should be exported >> and which should not. Perusing other packages also didn't reveal any >> clear patterns from which I could infer best practice. >> >> So may I ask for advice or any references that would provide such >> guidelines. Feel free to keep replies private if this query in not >> appropriate for this list. Many thanks. > > > If you export it, then you need to document it, and it needs to be usable by > others. > > Often you'll have specialized functions in a package that do what you need, > but they are too specialized to be useful to others: don't export those. > > Once you export a function, people (or maybe just yourself in some other > package or script) will start using it, so you tend to get locked in to the > interface. So don't export functions unless you want to support them in > their current form for the life of the package. > > If you export a function with the same name as one exported from another > package, it becomes inconvenient to use either function once both packages > are attached. (Which one you get depends on the order of attaching the > packages.) So don't export trivial functions, and think carefully about the > names you use for the ones you do export. > > It is slightly less convenient to test or inspect functions if you don't > export them (you need the package:::foo style to refer to them from the > console). So during early development, you may want to export more, and > limit the exports when you are happy with the package. > > Duncan Murdoch -- 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] as.data.frame.character lacks nm= argument
Bill: as.data.frame.character() has no nm, argument, so providing one causes the error as you can see from the code. Presumably, this is what you meant by bug/inconsistency, right? -- Bert On Thu, Sep 13, 2012 at 1:32 PM, William Dunlap wrote: > Is the following behavior with as.data.frame(nm=...) a bug? It is an > inconsistency: > >> as.data.frame(LETTERS[1:10], nm="FirstTenLetters") > Error in as.data.frame.vector(x, ..., nm = nm) : > formal argument "nm" matched by multiple actual arguments > > nm= works for integer arguments: > >> as.data.frame(1:10, nm="OneToTen") >OneToTen > 1 1 > 2 2 > 3 3 > 4 4 > 5 5 > 6 6 > 7 7 > 8 8 > 9 9 > 10 10 > > Bill Dunlap > Spotfire, TIBCO Software > wdunlap tibco.com > > ______ > 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] How to build a list with missing values? What is missing, anyway?
Why not just use the list constructor:
theList <- setNames(vector("list",3),letters[1:3])
## The list components are empty = NULL, not NA)
This also doesn't seem to be an R-devel topic.
-- Bert
On Wed, Oct 3, 2012 at 11:21 PM, Josh O'Brien wrote:
>
>>Say I have argnames <- c("a", "b", "c").
> >From that I want to construct the equivalent of alist(a=, b=, c=).
>
> Here's a one liner that'll do that for you:
>
> argnames <- letters[1:3]
> setNames(rep(list(bquote()), length(argnames)), argnames)
>
> - Josh
>
>
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/How-to-build-a-list-with-missing-values-What-is-missing-anyway-tp4644957p4644965.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> ______
> 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] How to build a list with missing values? What is missing, anyway?
The R Language definition manual explains all of this. Read it.
-- Bert
On Thu, Oct 4, 2012 at 3:53 PM, Peter Meilstrup
wrote:
> On Wed, Oct 3, 2012 at 11:21 PM, Josh O'Brien wrote:
>>
>>>Say I have argnames <- c("a", "b", "c").
>> >From that I want to construct the equivalent of alist(a=, b=, c=).
>>
>> Here's a one liner that'll do that for you:
>>
>> argnames <- letters[1:3]
>> setNames(rep(list(bquote()), length(argnames)), argnames)
>
> Thanks.
>
> Just so I have my mental model correct, I'm gathering that missing/``
> is a symbol that the interpreter has a special rule for -- evaluating
> it raises an error, as opposed to objects that evaluate to themselves
> or variable names that evaluate to objects.
>
> Does the same sort of thing explain the behavior of `...`? When the
> interpreter comes across `...` in the arguments during evaluation of a
> call, it trips a special argument-interpolating behavior?
>
> Peter
>
> __
> 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] How to build a list with missing values? What is missing, anyway?
On Thu, Oct 4, 2012 at 6:31 PM, Peter Meilstrup wrote: > On Thu, Oct 4, 2012 at 6:12 PM, Bert Gunter wrote: >> The R Language definition manual explains all of this. Read it. > > I always reread that before I post to this list. > > The only relevant mention of "missing" in the R Language Definition > that I could find were in section 4.1.2 on page 25, and that section Page 15, "NA handling" seems "relevant, " as does ?NA (at the command prompt in R). See also 2.5 in the Introduction to R tutorial. > did not answer anything about "missing" as a special symbol (e.g. that > my be put in a formal argument list.) > > There is another mention of `...` in section 4.3.2 and it does not See section 2.1.9 of the Language Definition manual and 10.4 of Intro to R. > explain some things, such as under what circumstances one would get a > "`...` used in incorrect context" error. How could it possibly know that? -- Bert > > Peter > >>> >>> Thanks. >>> >>> Just so I have my mental model correct, I'm gathering that missing/`` >>> is a symbol that the interpreter has a special rule for -- evaluating >>> it raises an error, as opposed to objects that evaluate to themselves >>> or variable names that evaluate to objects. >>> >>> Does the same sort of thing explain the behavior of `...`? When the >>> interpreter comes across `...` in the arguments during evaluation of a >>> call, it trips a special argument-interpolating behavior? >>> >>> Peter >>> >>> __ >>> 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 -- 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] as.data.frame.matrix() returns an invalid object
... and further > identical(as.list(df2),as.list(df1)) [1] TRUE in R 2.15.0 Not sure whether these sorts of degenerate cases are of much value, though. But I'll leave that for the wizards. -- Bert On Wed, Oct 10, 2012 at 11:22 PM, Hervé Pagès wrote: > Hi, > > Two ways to create what should normally be the same data frame: > > > df1 <- data.frame(a=character(0), b=character(0))> df1 > [1] a b > <0 rows> (or 0-length row.names) > > > df2 <- as.data.frame(matrix(character(0), ncol=2, dimnames=list(NULL, > letters[1:2]))) > > df2 > [1] a b > <0 rows> (or 0-length row.names) > > unique() works as expected except that I get a warning on 'df2': > > > unique(df1) > [1] a b > <0 rows> (or 0-length row.names) > > > unique(df2) > [1] a b > <0 rows> (or 0-length row.names) > Warning message: > In is.na(rows) : is.na() applied to non-(list or vector) of type 'NULL' > > Look like the two data frames are not identical: > > > identical(df1, df2) > [1] FALSE > > > all.equal(df1, df2) > [1] "Attributes: < Length mismatch: comparison on first 1 components >" > > > attributes(df1) > $names > [1] "a" "b" > > $row.names > integer(0) > > $class > [1] "data.frame" > > > attributes(df2) > $names > [1] "a" "b" > > $class > [1] "data.frame" > > Actually 'df2' is considered broken by validObject(): > > > validObject(df1) > [1] TRUE > > > validObject(df2) > Error in validObject(df2) : > invalid class “data.frame” object: slots in class definition but not in > object: "row.names" > > This is with R 2.15 and recent R devel. > > Cheers, > H. > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fhcrc.org > Phone: (206) 667-5791 > Fax:(206) 667-1319 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- 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] Bounty on Error Checking
Well... On Thu, Jan 3, 2013 at 10:00 AM, ivo welch wrote: > > Dear R developers---I just spent half a day debugging an R program, > which had two bugs---I selected the wrongly named variable, which > turns out to have been a scalar, which then happily multiplied as if > it was a matrix; and another wrongly named variable from a data frame, > that triggered no error when used as a[["name"]] or a$name . there > should be an option to turn on that throws an error inside R when one > does this. I cannot imagine that there is much code that wants to > reference non-existing columns in data frames. But I can -- and do it all the time: To add a new variable, "d" to a data frame, df, containing only "a" and "b" (with 10 rows, say): df[["d"]] <- 1:10 Trying to outguess documentation to create error triggers is a very bad idea. R already has plenty of debugging tools -- and there is even a "debug" package. Perhaps you need a better programming editor/IDE. There are several listed on CRAN, RStudio, etc. -- Bert > > > I know you guys are saints for developing without financial support. > but maybe we non-insider end-users can help by putting up a bounty > list on R-project for us end-users to contribute to? I would pledge > $500 to a $10,000 fund that funds a project to comprehensively enhance > the programming and debugging aspects of R. it would only take 20 of > us to make this possible. > > personally, I think basic nudgeware is the way to go. when a user > starts R in interactive mode, there should be a note that says, > > please donate $20 to the R foundation to support the development. > press enter to continue or enter your contribution number to avoid > this message in the future . > > you can even accept the same string if need be. it's a nudge only, > not a requirement. > > regards, > > /iaw > > > Ivo Welch (ivo.we...@gmail.com) > http://www.ivo-welch.info/ > J. Fred Weston Professor of Finance > Anderson School at UCLA, C519 > Director, UCLA Anderson Fink Center for Finance and Investments > Free Finance Textbook, http://book.ivo-welch.info/ > Editor, Critical Finance Review, http://www.critical-finance-review.org/ > > __ > 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] Printing of anonymous functions in calls is sub-optimal
As there has been no response to this ...
Why not simply:
> g <- substitute(f(x),list(f=function(x){x+1})) ## with curly braces
> g
function (x)
{
x + 1
}(x)
> x <- 2
> eval(g)
[1] 3
Cheers,
Bert
On Fri, Feb 15, 2013 at 7:45 AM, Hadley Wickham wrote:
> e.g.
>
> substitute(f(x), list(f = function(x) x + 1))
> # function (x)
> # x + 1(x)
>
> An extra pair of parentheses would really help:
>
> (function(x)
> x + 1)(x)
>
> (Better indenting etc would be nice, but not necessary for correct
> understand of the code)
>
> Hadley
>
> --
> Chief Scientist, RStudio
> http://had.co.nz/
>
> __
> 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
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] The *tmp* variable
Peter:
(Your function doesn't work -- you need to specify runif(1))
What ambiguity?
In the assignment within f(), x <- x+1,
the "x" on the rhs is a free variable in the function, and is
therefore looked for in the environment where the function was
defined. The x on the lhs is defined within the function only.
No matter what f() returns, x remains 1 in the environment from which
f is called. The function does not "return x" -- it returns a value,
which you can assign as you wish.
So ???
(and apologies if I'm missing something obvious).
Cheers,
Bert
On Sat, Jul 6, 2013 at 9:11 PM, Peter Meilstrup
wrote:
> When complex assignments are performed, the R interpreter creates, then
> removes a special variable *tmp*. However, when byte compiling is enabled,
> it seems that a different mechanism for making compound assignments is used.
>
> Would it be possible to eliminate *tmp* from interpreted R code as well? It
> might be useful for a function to lock its own environment, and the
> appearance and disappearance of *tmp* generally precludes that.
>
> (For example, a function might lock its own environment to guard against
> lexical-scope-breaking ambiguities such as
>
> x <- 1
> f <- function() {
>if (runif() < 0.5) {
> x <- x+1
> }
> x
> }
>
> where it is not clear where the returned x comes from inside or outside f.)
>
> [[alternative HTML version deleted]]
>
> ______
> 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] The *tmp* variable
Thanks, Peter. Now I get it.
It _was_ obvious!
-- Bert
On Sat, Jul 6, 2013 at 10:22 PM, Peter Meilstrup
wrote:
> The R interpreter does what it does at run time. The ambiguity is in
> reasoning at any time _other than run time_ which environment the returned
> value of 'x' is taken from.
>
> This is one reason why R has been profiled to spend a significant amount of
> time looking up names ( http://www.cs.purdue.edu/homes/jv/pubs/ecoop12.pdf
> -- see also:
> http://xianblog.wordpress.com/2010/09/13/simply-start-over-and-build-something-better/
> ). In languages with strict lexical scope, all var references are
> straightforwardly compiled into pointer jumps.
>
> But my concern is that it is generally bad _style_ to have bindings that are
> ambiguous in scope. Locking function environments would turn those cases, if
> they occur, into errors that can be caught and corrected.
>
> Peter
>
>
> On Sat, Jul 6, 2013 at 9:36 PM, Bert Gunter wrote:
>>
>> Peter:
>>
>> (Your function doesn't work -- you need to specify runif(1))
>>
>> What ambiguity?
>>
>> In the assignment within f(), x <- x+1,
>>
>> the "x" on the rhs is a free variable in the function, and is
>> therefore looked for in the environment where the function was
>> defined. The x on the lhs is defined within the function only.
>>
>> No matter what f() returns, x remains 1 in the environment from which
>> f is called. The function does not "return x" -- it returns a value,
>> which you can assign as you wish.
>>
>> So ???
>> (and apologies if I'm missing something obvious).
>>
>> Cheers,
>> Bert
>>
>> On Sat, Jul 6, 2013 at 9:11 PM, Peter Meilstrup
>> wrote:
>> > When complex assignments are performed, the R interpreter creates, then
>> > removes a special variable *tmp*. However, when byte compiling is
>> > enabled,
>> > it seems that a different mechanism for making compound assignments is
>> > used.
>> >
>> > Would it be possible to eliminate *tmp* from interpreted R code as well?
>> > It
>> > might be useful for a function to lock its own environment, and the
>> > appearance and disappearance of *tmp* generally precludes that.
>> >
>> > (For example, a function might lock its own environment to guard against
>> > lexical-scope-breaking ambiguities such as
>> >
>> > x <- 1
>> > f <- function() {
>> >if (runif() < 0.5) {
>> > x <- x+1
>> > }
>> > x
>> > }
>> >
>> > where it is not clear where the returned x comes from inside or outside
>> > f.)
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > 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
>
>
--
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] grid unit bug? (PR#14220)
Thank you Brian:
Maybe I should follow my own advice! I DID check methods(is.numeric) to see
if that were the case, but concluded it was not as that yielded an error.
But all I needed to do was read the docs! Registering the method indeed
seems the right way to do it.
Best regards,
Bert Gunter
Genentech Nonclinical Biostatistics
-Original Message-
From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
Sent: Wednesday, February 24, 2010 11:13 PM
To: gunter.ber...@gene.com; p...@stat.auckland.ac.nz
Cc: r-de...@stat.math.ethz.ch; r-b...@r-project.org
Subject: Re: [Rd] grid unit bug? (PR#14220)
is.numeric() is generic. So grid could include
is.numeric.unit <- function(x) FALSE
and register it in its namespace. Or Bert could define it in his
application.
On Thu, 25 Feb 2010, gunter.ber...@gene.com wrote:
> Paul:
>
> I figured that would be the problem.
>
> I encountered the issue when I tries to check arguments in a validDetails
> method for a grob.
>
> Could one substitute the following function in the grid namespace?
>
> is.numeric <- function(x)if(is.unit(x))TRUE else is.numeric(x)
>
> (or make the first clause FALSE)
>
> Obviously, messing around like this might be dangerous -- or at least
would
> compromise execution speed.
>
> Cheers,
> Bert
>
> Bert Gunter
> Genentech Nonclinical Biostatistics
>
>
>
> -Original Message-
> From: paul murrell [mailto:r-b...@r-project.org]
> Sent: Wednesday, February 24, 2010 4:22 PM
> To: gunter.ber...@gene.com
> Subject: Re: grid unit bug? (PR#14220)
>
>> The following seems to me to be at least a perverse trap, if not an =
>> outright
>> bug:
>>
>>> is.numeric(unit(1,"npc"))
>> [1] TRUE
>>> is.numeric(1*unit(1,"npc"))
>> [1] FALSE
>>> is.numeric(unit(0,"npc") +unit(1,"npc"))
>> [1] FALSE
>>
>> ...etc.
>> i.e. is.numeric() appears to be TRUE for class "unit" but false for =
>> class
>> ("unit.arithmetic" "unit" ). Seems to me it ought to b the same for =
>> both.
>
>
> These results simply reflect the underlying data structures (simple
"unit"s
> are
> just numeric vectors, but more complex "unit.arithmetic"s are lists). I
> don't
> see how I can "hide" the numeric-ness of simple units (just like there's
no
> way
> to stop a "ts" object like 'Nile' from satisfying is.numeric()). I could
> re-implement simple units as lists, but (apart from the work involved)
that
> would be (even) less efficient.
>
> 1. Is there a situation where this causes a problem?
>
> 2. Do you have a possible "fix" in mind?
>
> Paul
>
>
>>
>> Bert Gunter
>> Genentech Nonclinical Biostatistics
>>
>> (FWIW, I think grid graphics is brilliant!)
>>
>> This was R version 2.11.0dev for Windows btw (not that it makes a
>> difference):
>>
>> sessionInfo()
>>
>> R version 2.11.0 Under development (unstable) (2010-02-15 r51142)=20
>> i386-pc-mingw32=20
>>
>> locale:
>> [1] LC_COLLATE=3DEnglish_United States.1252=20
>> [2] LC_CTYPE=3DEnglish_United States.1252 =20
>> [3] LC_MONETARY=3DEnglish_United States.1252
>> [4] LC_NUMERIC=3DC =20
>> [5] LC_TIME=3DEnglish_United States.1252 =20
>>
>> attached base packages:
>> [1] datasets splines grid tcltk stats graphics =
>> grDevices
>> [8] utils methods base=20
>>
>> other attached packages:
>> [1] TinnR_1.0.3 R2HTML_1.59-1 Hmisc_3.7-0 survival_2.35-8
>> [5] svSocket_0.9-48 lattice_0.18-3 MASS_7.3-5=20
>>
>> loaded via a namespace (and not attached):
>> [1] cluster_1.12.1 svMisc_0.9-56
>>
>>
>>
>> =A0
>> =A0
>>
>>
>
> __
> 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
