R devel - Jul 2007 - (PR#9811) sequence(c(2, 0, 3)) produces surprising results,

This is as doumented, and I think you could say the same thing of seq().
BTW, sequence() allows negative inputs, and I don't think you want
sum(input) in that case.

I've never seen the point of sequence(), but it has been around in R for a 
long time.  It is used in packages eRm, extRemes, hydrosanity, klaR, seas.
Who knows what people have in private code, so I don't see any compelling 
case to change it.  If people want a different version, it would only take 
a minute to write (see below).

We could make seq_len take a vector argument, but as you point out in a 
followup that makes it slower in the common case.  It also changes its 
meaning if a length > 1 vector is supplied, and would speed matter in the 
long-vector case?  What does

sequence0 <- function (nvec)
{
     s <- integer(0)
     for (i in nvec) s <- c(s, seq_len(i))
     s
}

not do that is more than a very rare need?


On Thu, 26 Jul 2007, bill at insightful.com wrote:
> Full_Name: Bill Dunlap
> Version: 2.5.0
> OS: Linux
> Submission from: (NULL) (70.98.76.47)
>
>
> sequence(nvec) is documented to return
> the concatenation of seq(nvec[i]), for
> i in seq(along=nvec).  This produces inconvenient
> (for me) results for 0 inputs.
>    > sequence(c(2,0,3)) # would like 1 2 1 2 3, ignore 0
>    [1] 1 2 1 0 1 2 3
> Would changing sequence(nvec) to use seq_len(nvec[i])
> instead of the current 1:nvec[i] break much existing code?
>
> On the other hand, almost no one seems to use sequence()
> and it might make more sense to allow seq_len() and seq()
> to accept a vector for length.out and they would return a
> vector of length sum(length.out),
>    c(seq_len(length.out[1]), seq_len(length.out[2]), ...)
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Brian D. Ripley,                  ripley at 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, UK                Fax:  +44 1865 272595

On 27 Jul 2007, at 08:07, ripley at stats.ox.ac.uk wrote:
> This is as doumented, and I think you could say the same thing of  
> seq().
> BTW, sequence() allows negative inputs, and I don't think you want
> sum(input) in that case.
>
> I've never seen the point of sequence(), but it has been around in  
> R for a
> long time.  It is used in packages eRm, extRemes, hydrosanity,  
> klaR, seas.
> Who knows what people have in private code, so I don't see any  
> compelling
> case to change it.  If people want a different version, it would  
> only take
> a minute to write (see below).
>
> We could make seq_len take a vector argument, but as you point out  
> in a
> followup that makes it slower in the common case.  It also changes its
> meaning if a length > 1 vector is supplied, and would speed matter  
> in the
> long-vector case?  What does
>
> sequence0 <- function (nvec)
> {
>      s <- integer(0)
>      for (i in nvec) s <- c(s, seq_len(i))
>      s
> }
>
> not do that is more than a very rare need?
>

My 2 cents:

  Defining

        mySequence <- function(x){unlist(sapply(x,function(i){seq_len 
(i)}))}

is much faster.

Neither sequence0()  nor  mySequence() accepts vectors with any  
element <0
although as Brian Ripley points out, sequence() itself does (which I  
think is
undesirable).






Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
  tel  023-8059-7743

>>>>> "Robin" == Robin Hankin <r.hankin at
noc.soton.ac.uk>
>>>>>     on Fri, 27 Jul 2007 08:33:18 +0100 writes:
    Robin> On 27 Jul 2007, at 08:07, ripley at stats.ox.ac.uk
    Robin> wrote:

    >> This is as doumented, and I think you could say the same
    >> thing of seq().  BTW, sequence() allows negative inputs,
    >> and I don't think you want sum(input) in that case.
    >> 
    >> I've never seen the point of sequence(), but it has been
    >> around in R for a long time.  It is used in packages eRm,
    >> extRemes, hydrosanity, klaR, seas.  Who knows what people
    >> have in private code, so I don't see any compelling case
    >> to change it.  If people want a different version, it
    >> would only take a minute to write (see below).
    >> 
    >> We could make seq_len take a vector argument, but as you
    >> point out in a followup that makes it slower in the
    >> common case.  It also changes its meaning if a length > 1
    >> vector is supplied, and would speed matter in the
    >> long-vector case?  What does
    >> 
    >> sequence0 <- function (nvec) { s <- integer(0) for (i in
    >> nvec) s <- c(s, seq_len(i)) s }
    >> 
    >> not do that is more than a very rare need?
    >> 


 Robin> My 2 cents:

    Robin>   Defining

    Robin>         mySequence <-
    Robin> function(x){unlist(sapply(x,function(i){seq_len(i)}))}

    Robin> is much faster.

    Robin> Neither sequence0() nor mySequence() accepts vectors
    Robin> with any element <0 although as Brian Ripley points
    Robin> out, sequence() itself does (which I think is
    Robin> undesirable).

Yes, I agree.

Some more historical perspective (Brian alluded to) :

As the third R core member (first after Robert & Ross),
I still have access to the following R version 
{on one very old fortunately still running Solaris machine; I'm
 pretty sure it would not compile anymore on any recent
 OS/compiler suite} :

--------------------------------------------------------------------------
..$ R-0.00alpha

R Alpha-Test Version, Copyright (C) 1995 Robert Gentleman and Ross Ihaka

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type `license()' for details.
> sequence
function (nvec)
{
        sequence <- NULL
        for (i in (1:length(nvec))) sequence <- c(sequence, seq(nvec[i]))
        sequence
}
>                  
--------------------------------------------------------------------------

which interestingly also "works" for negative nvec[i],
but the way it is written even more clearly suggests that
negative nvec  entries were not the intent.

I'm voting that R should adopt a new (fast, but R code
only) version of sequence() which gives an error for negative
'nvec' entries --- though I do agree with Brian that it's not
really an important function at all.

Martin Maechler, ETH Zurich

PS: 
  Note that this was before R became GPL'ed "Free software", and
  that the R version stems from the following place -- back in 1995 :

  /anonymous at stat.auckland.ac.nz:/pub/R/unix/
  -rw-r--r--  1 51           1371 Jun 20  1995 INSTALL
  -rw-r--r--  1 51         466232 Jun 20  1995 R-unix-src.tar.gz
  -rw-r--r--  1 51           1079 Jun 20  1995 README

On Fri, 27 Jul 2007, Prof Brian Ripley wrote:
> This is as doumented, and I think you could say the same thing of seq().
> BTW, sequence() allows negative inputs, and I don't think you want
> sum(input) in that case.
help(sequence) says contradictory things about
the nvec[i]==0 case:
   For each element of 'nvec' the
   sequence 'seq(nvec[i])' is created.  ...
and
   nvec: an integer vector each element
   of which specifies the upper bound ...

0 is not the upper bound of seq(0).

In any case, a suitably general multisequence function
would probably want vectors of both to's and from's.

merge.data.frame() requires a combination of a vectorized
sequence function and rep.  It uses a .Internal to do
the job well.  (This is a case where the individual sequences
typically have length one or zero.)

  > .Internal(merge(rep(1:3, c(3,0,5)), rep(1:4, c(2,2,3,2)), T, T))
  $xi
   [1] 1 1 2 2 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8

  $yi
   [1] 1 2 1 2 1 2 5 6 7 5 6 7 5 6 7 5 6 7 5 6 7

  $x.alone
  integer(0)

  $y.alone
  integer(0)

sequence and rep produce complementary outputs, except in the nvec[i]==0 case.
  > rep(1:3, c(5,2,7)) # identifies group
   [1] 1 1 1 1 1 2 2 3 3 3 3 3 3 3
  > sequence(c(5,2,7)) # which in group
   [1] 1 2 3 4 5 1 2 1 2 3 4 5 6 7

----------------------------------------------------------------------------
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146

 "All statements in this message represent the opinions of the author and
do
 not necessarily reflect Insightful Corporation policy or position."