[Rd] seq.int/seq.default

[Mick Jordan]

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.

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".

>
>      > Please reply off list.
>
> [which I understand as that we should  CC you (which of course is
>   netiquette to do)]
>
Yes

Thanks
Mick Jordan