similar to: Logic ("!", "&", ...) on complex

Thanks Martin. My hang-up was not on what the outcome of as.complex(NA) should be, but rather, how I should read code like c(x, y) generally. Till now, I have thought of it like 'c(x, y)' is c(as(x, typeof(y)), y)` when "type(y) > type(x)". Basically in my mind, "coercion" in R <-> as.<newtype>(.) (or coerceVector() in C). So I tracked down the source

>>>>> Michael Chirico >>>>> on Sun, 5 Nov 2023 09:41:42 -0800 writes: > This is another follow-up to the thread from September > "Recent changes to as.complex(NA_real_)". > A test in data.table was broken by the changes for NA > coercion to complex; the breakage essentially comes from > c(NA, 0+1i) > # vs

So, to summarize, the open questions are: (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) instead of NA_complex_? (2) Should the first argument in c(NA, x) and c(NA_integer_, x), where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0) instead of NA_complex_? My opinions: (1) No. The imaginary part of the

>>>>> Mikael Jagan >>>>> on Wed, 8 Nov 2023 11:13:18 -0500 writes: > So, to summarize, the open questions are: > (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) > instead of NA_complex_? > (2) Should the first argument in c(NA, x) and c(NA_integer_, x), > where typeof(x) == "complex", be promoted

This is another follow-up to the thread from September "Recent changes to as.complex(NA_real_)". A test in data.table was broken by the changes for NA coercion to complex; the breakage essentially comes from c(NA, 0+1i) # vs c(as.complex(NA), 0+1i) The former is the output we tested against; the latter is essentially (via coerceVector() in C) what's generated by our

Hmm, it is not actually at odds with help(c), it is just that the autocoercion works different that it used to, so that as.complex(NA) == as.complex(NA_real) == NA_real_+0i) which now differs from NA_complex although both print as NA. I haven't been quite alert when this change was discussed, but it does look a bit unfortunate that usage patterns like c(NA, 0+1i) does not give complex NA

With 'z' of length 8 below, or of length 12 previously, one may try sapply(rev(z), match, table = rev(z)) match(rev(z), rev(z)) I found that the two results were different in R devel r70604. A shorter one: > z <- 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

i wonder about the following examples showing incoherence in how type conversions are done in r: x = TRUE x[2] = as.raw(1) # Error in x[2] = as.raw(1) : # incompatible types (from raw to logical) in subassignment type fix it seems that there is an attempt to coerce the raw value to logical here, which fails, even though as.logical(as.raw(1)) # TRUE likewise, x[2]

i wonder about the following examples showing incoherence in how type conversions are done in r: x = TRUE x[2] = as.raw(1) # Error in x[2] = as.raw(1) : # incompatible types (from raw to logical) in subassignment type fix it seems that there is an attempt to coerce the raw value to logical here, which fails, even though as.logical(as.raw(1)) # TRUE likewise, x[2]

Dear all, in R 3.1.0, this is happening: > cummin(c(1+1i,2-3i,4+5i)) Error in cummin(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 'cummax' not defined for complex numbers > cummax(c(1+1i,2-3i,4+5i)) Error in cummax(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 'cummin' not defined for complex numbers It may be fixed in R-devel, but I thought I'd mention it to make sure

This is not only bug report, but also a RFC (request for comments): The basic problem is that there are (at least) two ways of easily getting non-factor character columns in data.frames. The first is read.table(*, as.is = TRUE) and the second is data.frame(.., I(...), ..) which differ in their result. Whereas the first produces `pure' character columns in the data.frame,

>>>>> robin hankin <hankin.robin at gmail.com> >>>>> on Thu, 8 Sep 2016 10:05:21 +1200 writes: > Martin I'd like to make a comment; I think that R's > behaviour on 'edge' cases like this is an important thing > and it's great that you are working on it. > I make heavy use of zero-extent arrays, chiefly

Hi all, Surprisingly (at least to me), `as.complex(NA_real_)` results in `complex(real = NA_real_, imaginary = 0)` rather than `NA_complex_`. It seems to me that this goes against the docs of `as.complex()`, which say this in the Details section: "Up to R versions 3.2.x, all forms of NA and NaN were coerced to a complex NA, i.e., the NA_complex_ constant, for which both the real and

Shouldn't binary operators (arithmetic and logical) should throw an error when one operand is NULL (or other type that doesn't make sense)? This is a different case than a zero-length operand of a legitimate type. E.g., any(x < 0) should return FALSE if x is number-like and length(x)==0 but give an error if x is NULL. I.e., I think the type check should be done before the length

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Tue, 6 Sep 2016 22:26:31 +0200 writes: > Yesterday, changes to R's development version were committed, relating > to arithmetic, logic ('&' and '|') and > comparison/relational ('<', '==') binary operators > which in NEWS are

On 09/08/2016 01:22 PM, Gabriel Becker wrote: > On Thu, Sep 8, 2016 at 10:05 AM, William Dunlap <wdunlap at tibco.com> wrote: > >> Shouldn't binary operators (arithmetic and logical) should throw an error >> when one operand is NULL (or other type that doesn't make sense)? This is >> a different case than a zero-length operand of a legitimate type. E.g.,

Prior to the mid-1990s, S did "length-0 OP length-n -> rep(NA, n)" and it was changed to "length-0 OP length-n -> length-0" to avoid lots of problems like any(x<0) being NA when length(x)==0. Yes, people could code defensively by putting lots of if(length(x)==0)... in their code, but that is tedious and error-prone and creates really ugly code. Is your suggestion to

I think POSIXct and POSIXlt are badly-chosen names. The name "POSIX" implies UNIX. (i.e. XYZix operating system is mostly POSIX compliant... Woo-Hoo!). My assumption is that most people modelling industrial/econometric data etc, or data imported from databases, don't want system references everywhere. Historically, I've use the principle that: If programming language A uses

On 'factor', I meant the case where 'levels' is not specified, where 'unique' is called. > factor(c(complex(real=NaN), complex(imaginary=NaN))) [1] NaN+0i <NA> Levels: NaN+0i Look at <NA> in the result above. Yes, it happens in earlier versions of R, too. On matching both NA and NaN, another consequence is that length(unique(.)) may depend on order.

That, for example, complex(real=NaN) and complex(imaginary=NaN) are regarded as equal makes it possible that length(unique(as.character(x))) > length(unique(x)) (current code of function 'factor' doesn't expect it). Yes, an argument for the behavior is that NA and NaN are of one kind. On my system, using 32-bit R for Windows from binary from CRAN, the result of sapply(z, match,