From radford at cs.toronto.edu  Thu Sep 30 05:15:57 2010
From: radford at cs.toronto.edu (Radford Neal)
Date: Wed, 29 Sep 2010 23:15:57 -0400
Subject: [Rd] History of seq and seq.int
Message-ID: <20100930031557.GA2782@cs.toronto.edu>

I wonder what is the history of "seq" and "seq.int"?  

>From "help(seq)", one reads that "'seq.int' is an internal generic
which can be much faster but has a few restrictions".  And indeed,
"seq.int(1,99,by=2)" is over 40 times faster than "seq(1,99,by=2)" in
a quick test I just did.  This is not surprising given that "seq" is
written in R whereas "seq.int" is a primitive written in C.  The only
documented restriction on "seq.int" that I can see is that it won't
produce complex-valued sequences.

It would be nice if the 40-times-faster version could replace the slow
version, if it can be made to do the same thing.  But is there some
reason I don't see that this makes this hard?  Was the C version the
original, and then someone decided that complex number support was
essential, and most easily obtained by translating it to R?  (The R
code and C code are very parallel, so there was certainly a
translation rather a rewrite one way or the other.)  Or was the
original in R, and someone rewrote it in C for speed, but stopped just
short of being able to replace the R version with the C version
because they didn't implement complex-valued sequences?  Or is there
some other feature that's missing from seq.int?

By the way, I've submitted a bug report for seq.int, about it
evaluating all it's arguments twice, but that isn't really related to
the efficiency issue of seq versus seq.int.  It is perhaps related to
some strange code (and comments) in seq.int regarding special
treatment for the along.with argument, which maybe also has some
unusual history that isn't obvious...



[Rd] History of seq and seq.int
Radford Neal