[R] seq(2,5,-2) not an error but NULL
Robin Hankin
r.hankin at noc.soton.ac.uk
Mon Mar 27 15:28:13 CEST 2006
Hi.
seq() is a complex beast indeed. 'by' being the wrong
sign is a special case of the behaviour seen in the
following code snippets, the first of which is correctly
rejected by seq(), the second of which should arguably
return a three element complex vector.
> seq(from=1,to=3,by=1+1i)
Error in n < 0 : invalid comparison with complex values
> seq(from=1,to=4+3i,by=1+1i)
Error in n < 0 : invalid comparison with complex values
best wishes
Robin
On 27 Mar 2006, at 13:23, Duncan Murdoch wrote:
> On 3/27/2006 4:41 AM, Christian Hoffmann wrote:
>> Hi,
>>
>> This may belong more to r-develop, but general discussion may be
>> useful
>> (for the how many-th time ?)
>>
>> seq(2,5,-2)
>> seq(5,2,2)
>>
>> both result in
>>
>> Error in seq.default(2, 5, -2) : wrong sign in 'by' argument
>>
>> But often, if not always, mathematicians and programmers want a
>> behaviour e.g. in for loops, where this statement results in an empty
>> statement, that is
>>
>> for (ii in seq(2,5,-2)) print(ii)
>>
>> were equivalent to
>>
>> for (ii in NULL) print(ii).
>>
>> The relevant part in seq.default is now
>>
>> if (n < 0)
>> stop("wrong sign in 'by' argument")
>>
>> but could be changed by option to
>>
>> return(NULL)
>>
>> I think there should be an option to seq requiring this behaviour,
>> or a
>> specific function, may be even a special operator, e.g. %;%:
>>
>> 3;5 resulting in NULL.
>>
>> What do you think?
>
> If you want optional behaviour, the easiest way is to write your own
> wrapper function. E.g.
>
> emptyseq <- function(from, to, by) {
> if ((to-from)*by < 0) return(NULL)
> else return(seq(from, to, by))
> }
>
> I don't think this is a desirable default, though. We already have a
> special way to handle the most common case, i.e.
>
> seq(1, length(x), 1)
>
> should be written as
>
> seq(along=x))
>
> to handle the length(x) == 0 case the way you're requesting.
>
> But I'm not so sure that seq(2,5,-2) should really be NULL; it looks
> much more like an error to me. You say mathematicians and programmers
> want this behaviour, but I really can't think of any examples other
> than
> the one above.
>
> As a general principle, I think it's better to throw an error on
> ambiguous or apparently erroneous code rather than always returning an
> answer. If the code can be made unambiguous, it should be. (R
> doesn't
> always follow this principle; for example, recycling of vectors of
> lengths bigger than 1 is probably an error at least as often as it's
> intended.)
>
> Duncan Murdoch
>
> ______________________________________________
> 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
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
More information about the R-help
mailing list