R devel - Sep 2019 - '==' operator: inconsistency in data.frame(...) == NULL

Dear Martin,

On 11/09/2019 09:56, Martin Maechler wrote:
>
>      > I wonder if data.frame(<some non-empty data>) == NULL
should also return
>      > a value instead of an error. R help reads:
>
>          > "At least one of |x| and |y| must be an atomic vector,
but
> 	>  if the other is a list R attempts to coerce it to the
> 	>  type of the atomic vector: this will succeed if the list
> 	>  is made up of elements of length one that can be coerced
> 	>  to the correct type.
>
> 	>  If the two arguments are atomic vectors of different
> 	>  types, one is coerced to the type of the other, the
> 	>  (decreasing) order of precedence being character, complex,
> 	>  numeric, integer, logical and raw."
>
>      > It is not clear from the help what to expect for NULL or
>      > empty atomic vectors.
>
> Well, strictly speaking an error would be expected for NULL,
> as it is *not* an atomic vector, and your main issue
>
>   " data.frame(..) == NULL "
>
> would already be settled by the first half sentence from the
> doc, and strictly speaking, even  data.frame(NULL) == NULL
> "should" return an error ((Note: I'm not saying it really
>   should, but at least the reference does not say it should work at all))
Thanks, this explanation makes total sense to me. I did not consider 
that NULL might be non-atomic. Strangely, is.atomic(NULL) returns TRUE. 
On the other hand, I understand that one would not like to treat it like 
atomic in ==.

However, in this case one might expect that the error message would be 
more like that for S4 objects (which always seem to report an 
informative error message for ==):

 > Pos <- setClass("Pos", slots = c(latitude =
"numeric", longitude =
"numeric", altitude = "numeric"))
 > p = Pos()
 > p == NULL
Error in p == NULL :
 ? comparison (1) is possible only for atomic and list types
 > p == "FOO"
Error in p == "FOO" :
 ? comparison (1) is possible only for atomic and list types

In the data.frame()==NULL cases I have the impression that the fact that 
both sides are non-atomic is not properly detected and therefore R tries 
to go on with the == method for data.frames.

 From a cursory check in Ops.data.frame() and some debugging I have the 
impression that the case of the second argument being non-atomic or 
empty is not handled at all and the function progresses until the end, 
where it fails in the last step on an empty value:

matrix(unlist(value, recursive = FALSE, use.names = FALSE),
 ??? nrow = nr, dimnames = list(rn, cn))

Best regards,
Hilmar

-- 
Dr. Hilmar Berger, MD
Max Planck Institute for Infection Biology
Charit?platz 1
D-10117 Berlin
GERMANY

Phone:  + 49 30 28460 430
Fax:    + 49 30 28460 401
  
E-Mail: berger at mpiib-berlin.mpg.de
Web   : www.mpiib-berlin.mpg.de


	[[alternative HTML version deleted]]

Another example where a data.frame is compared to (here non-null, 
non-empty) non-atomic values in Ops.data.frame, resulting in an error 
message:

setClass("FOOCLASS2",
 ???????? slots = c(M="matrix")
)
ma = new("FOOCLASS2", M=matrix(rnorm(300), 30,10))

 > isS4(ma)
[1] TRUE
 > ma == data.frame(a=1:3)
Error in eval(f) : dims [product 1] do not match the length of object [3]

As for the NULL/logical(0) cases I would suggest to explicitly test for 
invalid conditions in Ops.data.frame and generate a comprehensible 
message (e.g. "comparison is possible only for atomic and list types")
if appropriate.

Best regards,
Hilmar


On 11/09/2019 11:55, Hilmar Berger wrote:
>
> In the data.frame()==NULL cases I have the impression that the fact 
> that both sides are non-atomic is not properly detected and therefore 
> R tries to go on with the == method for data.frames.
>
> From a cursory check in Ops.data.frame() and some debugging I have the 
> impression that the case of the second argument being non-atomic or 
> empty is not handled at all and the function progresses until the end, 
> where it fails in the last step on an empty value:
>
> matrix(unlist(value, recursive = FALSE, use.names = FALSE),
> ??? nrow = nr, dimnames = list(rn, cn)) 
-- 
Dr. Hilmar Berger, MD
Max Planck Institute for Infection Biology
Charit?platz 1
D-10117 Berlin
GERMANY

Phone:  + 49 30 28460 430
Fax:    + 49 30 28460 401
  
E-Mail: berger at mpiib-berlin.mpg.de
Web   : www.mpiib-berlin.mpg.de

Sorry, I can't reproduce the example below even on the same machine. 
However, the following example produces the same error as NULL values in 
prior examples:

 > setClass("FOOCLASS",
+????????? representation("list")
+ )
 > ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))
 > isS4(ma)
[1] TRUE
 > data.frame(a=1:3) == ma
Error in matrix(unlist(value, recursive = FALSE, use.names = FALSE), 
nrow = nr,? :
 ? length of 'dimnames' [2] not equal to array extent

Best,
Hilmar


On 11/09/2019 12:24, Hilmar Berger wrote:
> Another example where a data.frame is compared to (here non-null, 
> non-empty) non-atomic values in Ops.data.frame, resulting in an error 
> message:
>
> setClass("FOOCLASS2",
> ???????? slots = c(M="matrix")
> )
> ma = new("FOOCLASS2", M=matrix(rnorm(300), 30,10))
>
> > isS4(ma)
> [1] TRUE
> > ma == data.frame(a=1:3)
> Error in eval(f) : dims [product 1] do not match the length of object [3]
>
> As for the NULL/logical(0) cases I would suggest to explicitly test 
> for invalid conditions in Ops.data.frame and generate a comprehensible 
> message (e.g. "comparison is possible only for atomic and list
types")
> if appropriate.
>
> Best regards,
> Hilmar
>
>
> On 11/09/2019 11:55, Hilmar Berger wrote:
>>
>> In the data.frame()==NULL cases I have the impression that the fact 
>> that both sides are non-atomic is not properly detected and therefore 
>> R tries to go on with the == method for data.frames.
>>
>> From a cursory check in Ops.data.frame() and some debugging I have 
>> the impression that the case of the second argument being non-atomic 
>> or empty is not handled at all and the function progresses until the 
>> end, where it fails in the last step on an empty value:
>>
>> matrix(unlist(value, recursive = FALSE, use.names = FALSE),
>> ??? nrow = nr, dimnames = list(rn, cn)) 
>
-- 
Dr. Hilmar Berger, MD
Max Planck Institute for Infection Biology
Charit?platz 1
D-10117 Berlin
GERMANY

Phone:  + 49 30 28460 430
Fax:    + 49 30 28460 401
  
E-Mail: berger at mpiib-berlin.mpg.de
Web   : www.mpiib-berlin.mpg.de