[Rd] documentation / warning when passing a vector as lower/upper bound in stats::integrate()

[Martin Maechler]

>>>>> Baptiste Auguie <baptiste.auguie at gmail.com>
>>>>>     on Tue, 29 Mar 2016 19:31:02 +1300 writes:

    > Dear R-dev list,
    > I wonder if stats::integrate shouldn't warn the user when a numeric vector
    > of length > 1 is passed as lower or upper bounds. If a vector is passed,
    > only the first value is used and the others are silently ignored:

    > integrate(sin, lower=0, upper=pi)
    > integrate(sin, lower=0:10, upper=pi)

    > ?integrate doesn't appear to mention explicitly that the function is not
    > vectorised over those arguments.

well, that's not true:  Almost the very first text on the help
is the description and that already *does* say so :

> Description:

>      Adaptive quadrature of functions of one variable over a finite or
>      infinite interval.

"a .. interval"  is singular, ...

and then there are 14 examples, all using one interval...
*AND* one of them showing that you need to use *integrands*
which are vectorized.

So to me, it seems pretty bizarre that anyone assumes lower or upper
should be allowed to be vectors after reading the help page.
R users not reading the help page of a function after having problems or being
puzzled about it should not be allowed to post anywhere publicly on the
internet ;-)

    > It's probably not a common mistake, 
I think so, too !!     

    > consequences in the iterative calculation of multiple integrals. Someone
    > was puzzled by this today (http://stackoverflow.com/q/36275909/471093) and
    > it wasn't immediately obvious what had led to incorrect results (and worse,
    > it could have gone unnoticed).

I agree here.

Note however that checking for user errors always comes with a small
performance penalty and so, programmers traditionally have liked
to deal with such problems by keeping the code optimally fast...

If I remember the many silly performance comparisons of R with X
(notably with 'X' being a compiled language) and all the bad
propaganda of "R is slow", when much of that relative slowness
is because S and R have always aimed to be safe rather than
fast, I am sometimes reluctant to add yet another test for user
error..  but of course still agree we should do it.
Just think about the issue, next time someone tells you how much
faster his C++ / ... code is compared to plain R..

Martin


    > Best regards,
    > baptiste