Bringing up an old topic on a small technicality.
In the help documentation on seq.
Value:
The result is of 'mode' '"integer"' if
'from' is (numerically
equal to an) integer and 'by' is not specified.
The arguement in seq specifying length also creates "double" which is
not obvious in the wording, as "by" is not specified but
the object is double.
> typeof(seq(from=1, length=1))
[1] "double"
marcus
>>> Martin Maechler <maechler at stat.math.ethz.ch> 3/08/2004
3:15:45 AM >>>
>>>>> "Georgi" == Georgi Boshnakov <georgi.boshnakov
at umist.ac.uk>
>>>>> on Mon, 2 Aug 2004 15:46:37 +0100 writes:
Georgi> Hi, I wonder if the following (apparent)
Georgi> inconsistency is a bug or feature.
a feature "of course".
Georgi> Since scalars are simply vectors of length one I
Georgi> would think that a and a:a produce the same result.
Why would you?
Have you read the documentation for ":" carefully?
{Part this topic, namely that a numeric constant such as "4"
is a "double" in R (but integer in S-plus since S+5.0)
should probably finally end up in the R FAQ ...
}
Regards, Martin Maechler
Georgi> For example,
>> identical(4.01,4.01:4.01)
Georgi> [1] TRUE
Georgi> However,
Georgi> identical(4,4:4)
Georgi> [1] FALSE
Georgi> and
>> identical(4.0,4.0:4.0)
Georgi> [1] FALSE
Georgi> A closer look reveals that the colon operator produces objects of
different class, e.g.
a closer look wouldn't have been necessary had you read and
understood the documentation.
>> class(4)
Georgi> [1] "numeric"
>> class(4.0)
Georgi> [1] "numeric"
Georgi> but
>> class(4:4)
Georgi> [1] "integer"
>> class(4.0:4.0)
Georgi> [1] "integer"
Georgi> Georgi Boshnakov
Georgi>
------------------------------------------------------------------------------
Georgi> Dr Georgi Boshnakov tel.: +44
(0)161 200 3684
Georgi> Mathematics Department email:
georgi.boshnakov at umist.ac.uk
Georgi> UMIST
Georgi> P O Box 88
Georgi> Manchester M60 1QD
Georgi> UK
Georgi> [[alternative HTML version deleted]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
do read the posting guide why you should reconfigure
your e-mail software
______________________________________________
R-help at stat.math.ethz.ch mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
______________________________________________________
The contents of this e-mail are privileged and/or confidenti...{{dropped}}
>>>>> "Marcus" == Marcus Davy <MDavy at hortresearch.co.nz> >>>>> on Thu, 09 Dec 2004 11:38:29 +1300 writes:Marcus> Bringing up an old topic on a small technicality. Marcus> In the help documentation on seq() >> Value: >> The result is of 'mode' '"integer"' if 'from' is (numerically >> equal to an) integer and 'by' is not specified. Marcus> The arguement in seq specifying length also creates Marcus> "double" which is not obvious in the wording, as Marcus> "by" is not specified but the object is double. >> typeof(seq(from=1, length=1)) Marcus> [1] "double" yes, thank you, Marcus! Actually the situation is a bit more complicated and I'm currently looking at the (not yet committed) version \value{ The result is of \code{mode} \code{"integer"} if \code{from} is (numerically equal to an) integer and, e.g., only \code{to} is specified. % MM: to specify all the conditions doesn't seem worth, nor should the % code be changed just for docu.purposes; e.g. str(seq(from=1:1, to=8, by=3:3)) } Martin >>>> Martin Maechler <maechler at stat.math.ethz.ch> 3/08/2004 3:15:45 AM >>>>>>>> "Georgi" == Georgi Boshnakov <georgi.boshnakov at umist.ac.uk> >>>>> on Mon, 2 Aug 2004 15:46:37 +0100 writes:Georgi> Hi, I wonder if the following (apparent) Georgi> inconsistency is a bug or feature. Marcus> a feature "of course". Georgi> Since scalars are simply vectors of length one I Georgi> would think that a and a:a produce the same result. Marcus> Why would you? Marcus> Have you read the documentation for ":" carefully? Marcus> {Part this topic, namely that a numeric constant such as "4" Marcus> is a "double" in R (but integer in S-plus since S+5.0) Marcus> should probably finally end up in the R FAQ ... Marcus> } Marcus> Regards, Martin Maechler Georgi> For example, >>> identical(4.01,4.01:4.01) Georgi> [1] TRUE Georgi> However, Georgi> identical(4,4:4) Georgi> [1] FALSE Georgi> and >>> identical(4.0,4.0:4.0) Georgi> [1] FALSE Georgi> A closer look reveals that the colon operator produces objects of different class, e.g. Marcus> a closer look wouldn't have been necessary had you read and Marcus> understood the documentation. >>> class(4) Georgi> [1] "numeric" >>> class(4.0) Georgi> [1] "numeric" Georgi> but >>> class(4:4) Georgi> [1] "integer" >>> class(4.0:4.0) Georgi> [1] "integer" Georgi> Georgi Boshnakov Georgi> ------------------------------------------------------------------------------ Georgi> Dr Georgi Boshnakov tel.: +44 (0)161 200 3684 Georgi> Mathematics Department email: georgi.boshnakov at umist.ac.uk Georgi> UMIST Georgi> P O Box 88 Georgi> Manchester M60 1QD Georgi> UK Georgi> [[alternative HTML version deleted]] Marcus> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Marcus> do read the posting guide why you should reconfigure Marcus> your e-mail software Marcus> ______________________________________________ Marcus> R-help at stat.math.ethz.ch mailing list Marcus> https://www.stat.math.ethz.ch/mailman/listinfo/r-help Marcus> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Marcus> ______________________________________________________ Marcus> The contents of this e-mail are privileged and/or confidential to the Marcus> named recipient and are not to be used by any other person and/or Marcus> organisation. If you have received this e-mail in error, please notify Marcus> the sender and delete all material pertaining to this e-mail. Marcus> ______________________________________________________
In this discussion of seq(), can anyone explain to me _why_
seq(to=n) and seq(length=3) have different types?
In fact, it's worse than that (R2.0.1):
> storage.mode(seq(length=0))
[1] "integer"
> storage.mode(seq(length=1))
[1] "double"
If you want to pass seq(length=n) to a .C or .Fortran call,
it's not helpful that you can't tell what the type is until you know n!
It would be nice if seq(length=n) always returned the same type.
I use seq(length=n) often instead of 1:n because I'd like my code to
work when n == 0; it would make life simpler if seq(length=n) and 1:n
were the same type.
Can anyone explain to me why the arguments of seq.default are
"from", "to", "by", "length.out",
"along.with"
^^^^ ^^^^^
when the help page for seq documents them as
"from", "to", "by", "length", and
"along"?
I'm diverting to R-devel, where this is really more appropriate.>>>>> "RichOK" == Richard A O'Keefe <ok@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. 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
Havent seen anything on R-devel yet on this topic, but if the elseif statement
on line 43 of seq.default was
else if (length.out == 0)
double(0)
instead of
else if (length.out == 0)
numeric(0)
then that *might* satisfy Richard A. O'Keefe's comment for length=0:n
cases
>> storage.mode(seq(length=0))
RichOK> [1] "integer"
>> storage.mode(seq(length=1))
RichOK> [1] "double"
marcus
>>> Martin Maechler <maechler at stat.math.ethz.ch> 10/12/2004
9:34:11 PM >>>
I'm diverting to R-devel, where this is really more
appropriate. Here (R-help) only a shorter version:
>>>>> "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 ;-) :-)
For more on this, see the "R-devel" list to which this has been
diverted.
Martin Maechler, ETH Zurich
______________________________________________
R-help at stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
______________________________________________________
The contents of this e-mail are privileged and/or confidenti...{{dropped}}