Dear Hadly, dear list,
On Wed, Feb 16, 2011 at 9:53 PM, Hadley Wickham wrote:
> I wondered about this statement too but:
>
>> system.time(replicate(1e4, base::print))
> user system elapsed
> 0.539 0.001 0.541
>> system.time(replicate(1e4, print))
> user system elapsed
> 0.013 0.000
On Wed, Feb 16, 2011 at 1:13 PM, Paul Gilbert
wrote:
> (subject changed from: RE: [Rd] Avoiding name clashes: opinion on best
> practice naming conventions)
>
> Dominick,
>
> Is this really true? Is there a speed advantage to defining a local function
> this way, say, within another function, a
On Wed, Feb 16, 2011 at 12:13 PM, Paul Gilbert
wrote:
> (subject changed from: RE: [Rd] Avoiding name clashes: opinion on best
> practice naming conventions)
>
> Dominick
>
> Is this really true? Is there a speed advantage to defining a local function
> this way, say, within another function, a
Dear list,
Were you aware that, strictly speaking, do_radixsort in sort.c actually
implements a counting sort, not a radix sort ?
http://en.wikipedia.org/wiki/Counting_sort
It it was a radix sort it wouldn't need the 100,000 range restriction.
Clearly the method argument can't be changed (now)
Hi Paul,
> `:::`
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
get(name, envir = asNamespace(pkg), inherits = FALSE)
}
and
> `::`
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(
I tend to code with return(), at least in development, because I've once
stepped in the
cowpad of
ans<- list()
then attr(ans )
and forgot to do another
ans
so got only part of what I wanted. Perhaps its just my thinking style, but I
agree with
some others who suggest that it
(subject changed from: RE: [Rd] Avoiding name clashes: opinion on best practice
naming conventions)
Dominick
Is this really true? Is there a speed advantage to defining a local function
this way, say, within another function, and then calling it within a loop
rather than the original? Do you
On Wed, Feb 16, 2011 at 4:29 AM, Janko Thyson
wrote:
> Dear List,
>
> I'm trying to figure out some best practice way with respect to the naming
> conventions when building own packages.
>
> I'd like to minimize the risk of choosing function names that might
> interfere with those of other package
> -Original Message-
> From: h.wick...@gmail.com [mailto:h.wick...@gmail.com] On
> Behalf Of Hadley Wickham
> Sent: Wednesday, February 16, 2011 9:21 AM
> To: William Dunlap
> Cc: Tim Hesterberg; Henrik Bengtsson; r-devel@r-project.org
> Subject: Re: [Rd] matrixStats: Extend to arrays too
On 02/16/2011 10:57 AM, Prof Brian Ripley wrote:
The most obvious answer is not to do that. You have not used the
standard mechanism to to do that (which should work here as R CMD
INSTALL overrides that one). It's all in ?Startup (look for
R_DEFAULT_PACKAGES).
Note that R CMD INSTALL is not men
>> You mean rowMaxes, right? Or is the rule to add an s, not to
>> pluralise?
>
> In S+ we chose to just append the 's' instead of making
> everyone worry about the vagarities of English spelling
> and pluralization rules. We also have 'groupAnys' and
> 'igroupAnys' (and should have {row,col}Anys
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Hadley Wickham
> Sent: Wednesday, February 16, 2011 7:32 AM
> To: Tim Hesterberg
> Cc: Henrik Bengtsson; r-devel@r-project.org
> Subject: Re: [Rd] matrixStats: Extend to arrays
The most obvious answer is not to do that. You have not used the
standard mechanism to to do that (which should work here as R CMD
INSTALL overrides that one). It's all in ?Startup (look for
R_DEFAULT_PACKAGES).
The simplest way to ignore ~/.Rprofile is to set R_PROFILE_USER to
something el
Luke,
thanks for your explanation.
I now remember that I was indeed getting an error (instead of a silent
abort) because I did something comparable to a .Call() to "lapply" in
section 5.11 of WRE (Writing R extensions) where expr was the body of a
function f (literally) which contained a retur
Dear all,
Is there a way to force R CMD INSTALL to ignore ~/.Rprofile and
similar? I presume it sources these startup files for a reason, but
I've found that it can cause confusion or problems. In particular, my
~/.Rprofile loads a few packages which I very frequently use, but this
stops me from i
If you evaluate return(x) in an evironment env then then that will
execute a return from the function call associated with env or signal
an error if there is none. That is the way return() is intended to
work.
Best,
luke
On Wed, 16 Feb 2011, Duncan Murdoch wrote:
On 11-02-16 7:31 AM, Martin
On Wed, Feb 16, 2011 at 2:48 PM, Tim Hesterberg wrote:
> For consistency with rowSums colSums rowMeans etc., the names should be
> colMins colMaxs
> rowMins rowMaxs
> This is also consistent with S+.
You mean rowMaxes, right? Or is the rule to add an s, not to pluralise?
I think i
For consistency with rowSums colSums rowMeans etc., the names should be
colMins colMaxs
rowMins rowMaxs
This is also consistent with S+.
FYI, the rowSums naming convention was chosen to avoid conflict
with rowsum (which computes column sums!).
Tim Hesterberg
>> A well-designed AP
On 16 February 2011 at 08:00, Dirk Eddelbuettel wrote:
| Hoping that it is nothing to permanent, could someone with the power to do so
| please give the r-forge machine (or something in the network controlling
| access to it) a good shake or reboot ?
That appears to have been temporary. http an
Hoping that it is nothing to permanent, could someone with the power to do so
please give the r-forge machine (or something in the network controlling
access to it) a good shake or reboot ?
Thanks, Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
___
On 11-02-16 7:31 AM, Martin Becker wrote:
On 15.02.2011 22:48, David Scott wrote:
On 16/02/2011 7:04 a.m., Paul Johnson wrote:
...
4. We don't want gratuitous use of "return" at the end of functions.
Why do people still do that?
Well I for one (and Jeff as well it seems) think it is good
pro
On 15.02.2011 22:48, David Scott wrote:
On 16/02/2011 7:04 a.m., Paul Johnson wrote:
...
4. We don't want gratuitous use of "return" at the end of functions.
Why do people still do that?
Well I for one (and Jeff as well it seems) think it is good
programming practice. It makes explicit what
On 11-02-16 4:29 AM, Janko Thyson wrote:
Dear List,
I'm trying to figure out some best practice way with respect to the naming
conventions when building own packages.
I'd like to minimize the risk of choosing function names that might
interfere with those of other packages (both available ones
Dear List,
I'm trying to figure out some best practice way with respect to the naming
conventions when building own packages.
I'd like to minimize the risk of choosing function names that might
interfere with those of other packages (both available ones and those yet to
come).
I came up with fol
24 matches
Mail list logo
