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@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 ______________________________________________ R-help@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