Just to muddy the waters a bit further. Currently we can do things like:
> pascal.tri <- numeric(0)
> class(pascal.tri) <- 'pasctri'
>
> `[.pasctri` <- function(x, ...) {
+ dots <- list(...)
+ n <- dots[[1]]
+ row <- choose(n, 0:n)
+ if(length(dots) > 1) {
+ row <- row[ dots[[2]] ]
+ }
+ row
+ }
>
> pascal.tri[4]
[1] 1 4 6 4 1
> pascal.tri[4,2]
[1] 4
Now whether that is clever or abusive, I'm not sure (probably not clever).
But what would we expect:
> pascal.tri[end]
to return?
Also if we can access the last element of a vector as:
> x[end]
(which I am not opposed to, just don't know if it is worth the effort) then how
long will it be before someone wants to be able to do:
> x[end+1] <- new.value
and put that in a loop, which would lead to very poor programming practice (but
so easy it would tempt many).
Just my $0.015 worth,
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
> -----Original Message-----
> From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-
> project.org] On Behalf Of Wacek Kusnierczyk
> Sent: Friday, December 12, 2008 8:57 AM
> To: claudia.belei...@gmx.de
> Cc: R help
> Subject: Re: [R] The end of Matlab
>
> Claudia Beleites wrote:
> >>> Wacek:
> >>>
> >>>> x[3:]
> >>>> instead of
> >>>> x[3:length(x)]
> >>>> x[3:end]
> >>>>
> >>> I don't think that would help:
> >>> what to use for end - 3 within the convention that negative values
> mean
> >>> exclusion?
> >>>
> >> might seem tricky, but not impossible:
> >>
> >> x[-2]
> >> # could mean 'all except for 2nd', as it is now
> >>
> >> x[1:-2]
> >> # could mean 'from start to the 2nd backwards from the end'
> >>
> > I know you get thus far. You might even think to decide whether
> exclusion or
> > 'from the end' is meant from ascending ./. descending order of the
> sequence,
> > but this messes around with returning the reverse order.
> >
> >
>
> that's a design issue. one simple solution is to have this sort of
> indexing return always in ascending order. thus,
>
> x = 1:5
> x[1:-1]
> # 1 2 3 4 5
> x[5:-5]
> # NULL rather than 5 4 3 2 1 -- as in matlab or python
>
> x[seq(5,1)]
> # 5 4 3 2 1
>
> that is, the ':'-based indexing can be made not to mess with the order.
> for reversing the order, why not use:
>
> x[5:-1:1]
> # 5 4 3 2 1
>
> x[-3:-1:-5]
> # 3 2 1 rather than x[c(-3,-4,-5)], which would be 1 2
>
>
> >> since r disallows mixing positive and negative indexing, the above
> would
> >> not be ambiguous. worse with
> >>
> >> x[-3:-1]
> >>
> >> which could mean both 'except for 3rd, 2nd, and 1st' and 'from the
> 3rd
> >> to the 1st from the end', and so would be ambiguous. in this
> context,
> >> indeed, having explicit 'end' could help avoid the ambiguity.
> >>
> > that's the problem.
> > also: how would 'except from the 5th last to the 3rd last' be
> expressed?
> >
>
> for exclusions you'd need to use negative indices anyway:
>
> x[seq(-5,-3)]
>
> now, neither x[-5:-3] nor x[-3:-5] would do the job they do now, but
> the
> above is not particularly longer, while selecting the
> 5th-to3rd-from-the-end columns is simply x[-5:-3] (which could be made
> to fail on out-of-range indices) instead of something like x[length(x)
> -
> 4:2] (which will silently do the wrong thing if length(x) < 4, and thus
> requires extra care).
>
> this is a rather loose idea, and unrealistic in the context of r, but i
> do not see much problem with it on the conceptual level.
>
> vQ
>
> ______________________________________________
> R-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-
> guide.html
> and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
