[Rd] seq.int/seq.default

[Martin Maechler]

>>>>> Mick Jordan <mick.jordan at oracle.com>
>>>>>     on Wed, 4 Jan 2017 08:15:03 -0800 writes:

    > On 1/4/17 1:26 AM, Martin Maechler wrote:
    >>>>>>> Mick Jordan <mick.jordan at oracle.com>
    >>>>>>> on Tue, 3 Jan 2017 07:57:15 -0800 writes:
    >> > This is a message for someone familiar with the implementation.
    >> > Superficially the R code for seq.default and the C code for seq.int
    >> > appear to be semantically very similar. My question is whether, in fact,
    >> > it is intended that behave identically for all inputs.
    >> 
    >> Strictly speaking, "no":  As usual, RT?Manual (;-)
    >> 
    >> The help page says in the very first paragraph ('Description'):
    >> 
    >> ‘seq’ is a standard generic with a default method.
    >> ‘seq.int’ is a primitive which can be much faster but has a few restrictions.
    >> 
    >> > I have found two cases so far where they differ, first
    >> > that seq.int will coerce a character string to a real (via
    >> > Rf_asReal) whereas seq.default appears to coerce it to NA
    >> > and then throws an error:
    >> 
    >> >> seq.default("2", "5")
    >> > Error in seq.default("2", "5") : 'from' cannot be NA, NaN or infinite
    >> >> seq.int("2", "5")
    >> > [1] 2 3 4 5
    >> >>
    >> 
    >> this may be a bit surprising (if one does _not_ look at the code),
    >> indeed, notably because seq.int() is mentioned to have more
    >> restrictions than seq() which here calls seq.default().
    >> "Surprising" also when considering
    >> 
    >> > "2":"5"
    >> [1] 2 3 4 5
    >> 
    >> and the documentation of ':' claims 'from:to' to be the same as
    >> rep(from,to)  apart from the case of factors.
    >> 
    >> --- I am considering a small change in  seq.default()
    >> which would make it work for this case, compatibly with ":" and seq.int().
    >> 
    >> 
    >> > and second, that the error messages for non-numeric arguments differ:
    >> 
    >> which I find fine... if the functions where meant to be
    >> identical, we (the R developers) would be silly to have both,
    >> notably as the ".int" suffix  has emerged as confusing the
    >> majority of useRs (who don't read help pages).
    >> 
    >> Rather it has been meant as saying "internal" (including "fast") also for other
    >> such R functions, but the suffix of course is a potential clash
    >> with S3 method naming schemes _and_ the fact that 'int' is used
    >> as type name for integer in other languages, notably C.
    >> 
    >> > seq.default(to=quote(b), by=2)
    >> > Error in is.finite(to) : default method not implemented for type 'symbol'
    >> 
    >> which I find a very appropriate and helpful message
    >> 
    >> > seq.int(to=quote(b), by=2)
    >> > Error in seq.int(to = quote(b), by = 2) :
    >> > 'to' cannot be NA, NaN or infinite
    >> 
    >> which is true, as well, and there's no "default method" to be
    >> mentioned, but you are right that it would be nicer if the
    >> message mentioned 'symbol' as well.

    > Thanks for the clarifications. It was surprising that seq.int supported 
    > more types than seq.default. I was expecting the reverse.

exactly, me too!

    > BTW, There are a couple of, admittedly odd, cases, exposed by brute 
    > force testing, where seq.int will actually return "missing", which I 
    > presume is not intended, and seq.default behaves differently, vis:

    >> seq.default(to=1,by=2)
    > [1] 1
    >> seq.int(to=1,by=2)

    >> > x <- seq.int(to=1,by=2)
    >> x
    > Error: argument "x" is missing, with no default

    > Lines 792 and 799 of seq.c return the incoming argument (as opposed to a 
    > value based on its coercion to double via asReal) and this can, as in 
    > the above example, be "missing".

    > Thanks
    > Mick Jordan

Thanks a lot, Mick -- you are right!

I'm fixing these  (the line numbers have greatly changed in the
mean time: Remember we work with "R-devel", i.e., the "trunk" :
always available at
https://svn.r-project.org/R/trunk/src/main/seq.c

Martin Maechler
ETH Zurich