[Rd] Re: [R] Is k equivalent to k:k ?

[Roger D. Peng]

Martin Maechler wrote:
> I'm diverting to R-devel,  where this is really more
> appropriate.
> 
> 
>>>>>>"RichOK" == Richard A O'Keefe <ok at cs.otago.ac.nz>
>>>>>>    on Fri, 10 Dec 2004 14:37:16 +1300 (NZDT) writes:
> 
> 
>     RichOK> In this discussion of seq(), can anyone explain to
>     RichOK> me _why_ seq(to=n) and seq(length=3) have different
>     RichOK> types?  
> 
> well, the explantion isn't hard:  look at  seq.default  :-)
> 
>     RichOK> In fact, it's worse than that (R2.0.1):
> 
>     >> storage.mode(seq(length=0))
>     RichOK>     [1] "integer"
>     >> storage.mode(seq(length=1))
>     RichOK>     [1] "double"
> 
>   { str(.) is shorter than  storage.mode(.) }
> 
>     RichOK> If you want to pass seq(length=n) to a .C or
>     RichOK> .Fortran call, it's not helpful that you can't tell
>     RichOK> what the type is until you know n!  It would be nice
>     RichOK> if seq(length=n) always returned the same type.  I
>     RichOK> use seq(length=n) often instead of 1:n because I'd
>     RichOK> like my code to work when n == 0; it would make life
>     RichOK> simpler if seq(length=n) and 1:n were the same type.
> 
> now if that really makes your *life* simpler, what does that
> tell us about your life  ;-) :-)
> 
> But yes, you are right.  All should return integer I think.
> 
> BTW --- since this is now on R-devel where we discuss R development:
>   
>  In the future, we really might want to have a new type,
>  some "long integer" or "index" which would be used both in R
>  and C's R-API for indexing into large objects where 32-bit
>  integers overflow.
>  I assume, we will keep the    R "integer" == C "int" == 32-bit int
>  forever, but need something with more bits rather sooner than later.
>  But in any, case by then, some things might have to change in
>  R (and C's R-API) storage type of indexing.

I'm very much in favor of this suggestion.  I too believe that more 
people will begin running into this problem as more 64 bit machines 
come alive with > 4GB of memory.  (I believe) we've run into this 
problem a few times when trying to load large image arrays.

> 
> 
>     RichOK> Can anyone explain to me why the arguments of seq.default are
>     RichOK> "from", "to", "by", "length.out", "along.with"
>     RichOK>                            ^^^^         ^^^^^
>     RichOK> when the help page for seq documents them as
>     RichOK> "from", "to", "by", "length", and "along"?
> 
> 
> Well I can explain why this wasn't caught by R's builtin 
> QA (quality assurance) checks:
> 
> The base/man/seq.Rd page uses  both \synopsis{} and \usage{}
> which allows to put things on the help page that are not checked
> to coincide with the code...
> I'm about to fix this (documentation, not code).
> 
> Martin
> 
> ______________________________________________
> R-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

-- 
Roger D. Peng
http://www.biostat.jhsph.edu/~rpeng/