search for: cequal

...lt;- complex(real = c(0,NaN,NaN), imaginary = c(NA,NA,0)) > sapply(z, match, table = z) [1] 1 1 2 > match(z, z) [1] 1 1 3 An explanation of the behavior: With normal equality, if z[2] is equal to z[1] and z[3] is not equal to z[1], z[3] is not equal to z[2]. It is not the case here with 'cequal'. However, it seems that the property is assumed in usual case of 'match'. For it, just changing 'cequal' so that a complex number that has both NA and NaN matches NA and doesn't match NaN is enough. It also makes length(unique(.)) not order-dependent. For more change, I a...

I am raising this again. With z <- complex(real = c(0,NaN,NaN), imaginary = c(NA,NA,0)) , results of sapply(z, match, table = z) and match(z, z) are different in R 3.4.0 alpha. I think they should be the same. I suggest changing 'cequal' in unique.c such that a complex number that has both NA and NaN matches NA and doesn't match NaN, as such complex number is printed as NA.

...3 7 8 2 4 8 12? # R 2.10.1, different from below ? ? > 1 2 3 4 1 3 7 8 2 4 8 12? # R 3.2.5, different from below interesting, thank you... and another reason why the change (currently only in R-devel) may have been a good one: More uniformity. ? ? > I noticed that, by function 'cequal' in unique.c, a complex number that has both NA and NaN matches NA and also matches NaN. ? ? >> x0 <- c(0,1, NA, NaN); z <- outer(x0,x0, complex, length.out=1); rm(x0) ? ? >> (z <- z[is.na(z)]) ? ? > [1]? ? ???NA NaN+? 0i? ? ???NA NaN+? 1i? ? ???NA? ? ???NA? ?...

...m, using 32-bit R for Windows from binary from CRAN, the result of sapply(z, match, table = z) (not in current R-devel) may be different from below: 1 2 3 4 1 3 7 8 2 4 8 12 # R 2.10.1, different from below 1 2 3 4 1 3 7 8 2 4 8 12 # R 3.2.5, different from below I noticed that, by function 'cequal' in unique.c, a complex number that has both NA and NaN matches NA and also matches NaN. > x0 <- c(0,1, NA, NaN); z <- outer(x0,x0, complex, length.out=1); rm(x0) > (z <- z[is.na(z)]) [1] NA NaN+ 0i NA NaN+ 1i NA NA NA NA [9] 0+NaNi 1+...

...ish almost all complex NA / NaN's which is NOT according to documentation. I have found that this is just because of of our hashing function for the complex case, chash() in R/src/main/unique.c, is bogous in the sense that it is not compatible with the above documentation and also not with the cequal() function (in the same file uniqu.c) for checking equality of complex numbers. As I have found,, a *simplified* version of the chash() function to make it compatible with cequal() does solve all the problems I've indicated, and the current plan is to commit that change --- after some discuss...

...should do the trick. */ static int requal3(SEXP x, int i, SEXP y, int j) { double xi, yj; if (i < 0 || j < 0) return 0; xi = REAL(x)[i]; yj = REAL(y)[j]; if (!ISNAN(xi) || !ISNAN(yj)) return xi == yj; return R_IsNA(xi) == R_IsNA(yj); } The logic of the cequal() function (in the same file) could also be cleaned up in a similar way, probably for an even greater speedup. This will benefit duplicated(), anyDuplicated() and unique() on numeric and complex vectors. Cheers, H. -- Herv? Pag?s Program in Computational Biology Division of Public Health Scien...