Hilmar Berger
2019-Sep-11 09:55 UTC
[Rd] '==' 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]]
Hilmar Berger
2019-Sep-11 10:24 UTC
[Rd] '==' operator: inconsistency in data.frame(...) == NULL
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
Hilmar Berger
2019-Sep-11 11:26 UTC
[Rd] '==' operator: inconsistency in data.frame(...) == NULL
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
Seemingly Similar Threads
- '==' operator: inconsistency in data.frame(...) == NULL
- '==' operator: inconsistency in data.frame(...) == NULL
- '==' operator: inconsistency in data.frame(...) == NULL
- Crash after (wrongly) applying product operator on S4 object that derives from list
- Crash after (wrongly) applying product operator on object from LIMMA package