[Rd] R-devel Digest, Vol 133, Issue 23

[Hervé Pagès]

Hi,

On 03/26/2014 10:24 AM, Radford Neal wrote:
>> From: Richard Cotton <richierocks at gmail.com>
>>
>> The rep function is very versatile, but that versatility comes at a
>> cost: it takes a bit of effort to learn (and remember) its syntax.
>> This is a problem, since rep is one of the first functions many
>> beginners will come across.  Of the three main uses of rep, two have
>> simpler alternatives.
>>
>> rep(x, times = ) has rep.int
>> rep(x, length.out  = ) has rep_len
>>
>> I think that a rep_each function would be a worthy addition for the
>> third use case
>>
>> rep(x, each = )
>>
>> (It might also be worth having rep_times as a synonym for rep.int.)
>
> I think this is exactly the wrong approach.  Indeed, the aim should be
> to get rid of functions like rep.int (or at least discourage their
> use, even if they have to be kept for compatibility).
>
> Why is rep_each(x,n) better than rep(x,each=n)?

According to the NEWS file, it seems that R core felt that having
rep_len() was a good idea.

   There is a new function rep_len() analogous to rep.int() for when
   speed is required (and names are not).

Now one might wonder (and your students might wonder too) why having
rep_each() "for when speed is required (and names are not)" is not a
good idea.

By having rep_len(), rep_each(), and rep_times(), the 3 extra arguments
in rep(x, ...) would be covered. Plus, when I use tab completion after
typing rep_, I would get a nice summary and would be able to quickly
choose. Right now, when I do this, one function is missing, and one has
a misleading name. So I'd rather have no specialized function at all,
or have the 3. Would be cleaner and less confusing than the current
situation.

Cheers,
H.


> There is no saving in
> typing (which would be trivial anyway).  There *ought* to be no
> significant difference in speed (though that seems to have been the
> motive for rep.int).  Are you trying to let students learn R without
> ever learning about specifying arguments by name?
>
> And where would you stop?  How about seq_by(a,b,s) rather than having
> to arduously type seq(a,b,by=s)?  Maybe we should have glm_binomial,
> glm_poisson, etc. so we don't have to remember the "family" argument?
> This way lies madness...
>
>     Radford Neal
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
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: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319