[Rd] (NA || x) and (NA && y) {another "bug" } (PR#749)

[maechler@stat.math.ethz.ch]

>>>>> "TL" == Thomas Lumley <thomas@biostat.washington.edu> writes:

on Subject: Re: [Rd] Problem with NAs using chisq.test() (PR#748)
which I've changed, since it is another bug we are talking about now

    TL> On Sun, 26 Nov 2000 kjetikj@astro.uio.no wrote:
    >> Full_Name: Kjetil Kjernsmo

    ..............
    ..............

    TL> However, it would also be reasonable for NA || B to evaluate B and
    TL> return TRUE or NA depending on the value.  This is what S-PLUS 5
    TL> does, so at least it's an incompatibility.

    TL> The R documentation says 

    TL>>  The longer form [ie ||] evaluates left to right examining only the
    TL>>  first element of each vector.  Evaluation 
    TL>>  proceeds only until the result is determined. 

    TL> which at least seems incomplete as NA | TRUE gives TRUE, but
    TL> NA || TRUE gives an error.

Looks over-cautious to me as well.
We should reach a conclusion here, asap [to be effective for R 1.2].

Either

1)	NA || x
  (and	NA && y )

  continue to give errors, and we should strongly emphasize it in the
  documentation -- and in the FAQ list of differences to S

or

2) really do the same as S, not only Splus 5.x, but also 3.4 which used to
   be our prototype, namely

    > NA || TRUE
    [1] TRUE
    > NA && FALSE
    [1] FALSE
    > NA && TRUE
    [1] NA
    > NA || FALSE
    [1] NA

The advantage of "1)" is to catch programming errors early in some cases,
however for consistency (with "|" and "&") and compatibility,
I'm voting for a change to "2)" behaviour.

---
Martin Maechler <maechler@stat.math.ethz.ch>	http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum  LEO D10	Leonhardstr. 27
ETH (Federal Inst. Technology)	8092 Zurich	SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1228			<><

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._