Displaying 20 results from an estimated 1000 matches similar to: "c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?"
2023 Nov 09
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
>>>>> 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
2023 Nov 07
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
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
2023 Nov 06
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
>>>>> 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
2023 Nov 06
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
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
2023 Nov 05
2
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
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
2016 Jul 16
1
sample() fails with double or integer NA input of length one
Hi,
I have discovered that sample() fails with an uninformative error
message when the x argument is a single NA of type double or integer.
I can reproduce the problem with the following code:
base::sample(NA)
# NA is of logical type above
base::sample(NA_character_)
base::sample(NA_complex_)
base::sample(NA_real_)
base::sample(NA_integer_)
The last two lines throw the following error:
Error
2023 Apr 14
1
Possible inconsistency between `as.complex(NA_real_)` and the docs
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
2009 Jun 03
1
Print bug for matrix(list(NA_complex_, ...))
In R 2.8.0 on Windows (tested both under ESS and under R Console in case
there was an I/O issue)
There is a bug in printing val <- matrix(list(NA_complex_,NA_complex_),1).
> dput(val)
structure(list(NA_complex_, NA_complex_), .Dim = 1:2)
> print(val)
[,1]
[1,]
[,2]
[1,]
Note that a large number of spaces are printed instead of NA. Compare the
unproblematic real case:
2013 Dec 12
2
Status of reserved keywords and builtins
According to http://cran.r-project.org/doc/manuals/r-release/R-lang.html#Reserved-words
if else repeat while function for in next break
TRUE FALSE NULL Inf NaN
NA NA_integer_ NA_real_ NA_complex_ NA_character_
... ..1 ..2 etc.
are all reserved keywords.
However, in R 3.0.2 you can do things like:
`if` <- function(cond, val1, val2) val2
after which
if(TRUE) 1 else 2
returns 2.
2010 Mar 31
2
Should as.complex(NaN) -> NA?
I'm having trouble grokking complex NaN's.
This first set examples using complex(re=NaN,im=NaN)
give what I expect
> Re(complex(re=NaN, im=NaN))
[1] NaN
> Im(complex(re=NaN, im=NaN))
[1] NaN
> Arg(complex(re=NaN, im=NaN))
[1] NaN
> Mod(complex(re=NaN, im=NaN))
[1] NaN
> abs(complex(re=NaN, im=NaN))
[1] NaN
and so do the following
> Re(complex(re=1,
2017 May 19
2
Inconsistency in handling of numeric input with %d by sprintf
Consider
#as.numeric for emphasis
sprintf('%d', as.numeric(1))
# [1] "1"
vs.
sprintf('%d', NA_real_)
> Error in sprintf("%d", NA_real_) :
invalid format '%d'; use format %f, %e, %g or %a for numeric object
>
I understand the error is correct, but if it works for other numeric input,
why doesn't R just coerce NA_real_ to NA_integer_?
2020 May 23
2
Should 0L * NA_integer_ be 0L?
I don't see this specific case documented anywhere (I also tried to search
the r-devel archives, as well as I could); the only close reference
mentions NA & FALSE = FALSE, NA | TRUE = TRUE. And there's also this
snippet from R-lang:
In cases where the result of the operation would be the same for all
> possible values the NA could take, the operation may return this value.
>
2017 May 23
2
Inconsistency in handling of numeric input with %d by sprintf
I initially thought this is "documented behaviour". ?sprintf says:
Numeric variables with __exactly integer__ values will be coerced to
integer. (emphasis mine).
Turns out this only works when the first value is numeric and not NA, as
shown by the following example:
> sprintf("%d", as.numeric(c(NA,1)))
Error in sprintf("%d", as.numeric(c(NA, 1))) :
invalid
2017 May 23
2
Inconsistency in handling of numeric input with %d by sprintf
https://github.com/Rdatatable/data.table/issues/2171
The fix was easy, it's just surprising to see the behavior change almost on
a whim. Just wanted to point it out in case this is unknown behavior, but
Evan seems to have found this as well.
On Tue, May 23, 2017 at 12:00 PM, Michael Chirico <michaelchirico4 at gmail.com
> wrote:
> Astute observation. And of course we should be
2020 Jan 21
2
class(<matrix>) |--> c("matrix", "arrary") -- and S3 dispatch
Dear Martin,
What's the ETA for _R_CLASS_MATRIX_ARRAY_=TRUE to become the new
unconditional behavior in R devel? Thanks!
H.
On 11/21/19 08:57, Martin Maechler wrote:
>
> TLDR: This is quite technical, still somewhat important:
> 1) R 4.0.0 will become a bit more coherent: a matrix is an array
> 2) Your package (or one you use) may be affected.
>
>
2020 May 23
0
Should 0L * NA_integer_ be 0L?
>>>>> Michael Chirico
>>>>> on Sat, 23 May 2020 18:08:22 +0800 writes:
> I don't see this specific case documented anywhere (I also tried to search
> the r-devel archives, as well as I could); the only close reference
> mentions NA & FALSE = FALSE, NA | TRUE = TRUE. And there's also this
> snippet from R-lang:
> In
2019 Nov 15
5
class(<matrix>) |--> c("matrix", "arrary") [was "head.matrix ..."]
>>>>> Pages, Herve
>>>>> on Thu, 14 Nov 2019 19:13:47 +0000 writes:
> On 11/14/19 05:47, Hadley Wickham wrote:
>> On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler
>> <maechler at stat.math.ethz.ch> wrote:
>>>
>>>>>>>> Gabriel Becker
>>>>>>>> on Sat, 2 Nov 2019
2017 May 23
0
Inconsistency in handling of numeric input with %d by sprintf
Yes, what Joris posts about is exactly what I noted in my March 9th post to
R-devel. The behaviour is sort of documented, but not in the clearest
manner (in my opinion). Like I say, my ultimate conclusion was that the
silent coercion of numerics to integers by sprintf() was a handy
convenience, but not one that should be relied about to always work
predictably.
On Tue, May 23, 2017 at 10:02 AM,
2017 May 23
0
Inconsistency in handling of numeric input with %d by sprintf
Hi Michael,
I posted something on this topic to R-devel several weeks ago, but never
got a response. My ultimate conclusion is that sprintf() isn't super
consistent in how it handles coercion: sometimes it'll coerce real to
integer without complaint, other times it won't. (My particular email had
to do with the vectors longer than 1 and their positioning vis-a-vis the
format string.)
2017 May 23
0
Inconsistency in handling of numeric input with %d by sprintf
Astute observation. And of course we should be passing integer when we use
%d. It's an edge case in how we printed ITime objects in data.table:
On Tue, May 23, 2017 at 11:53 AM, Joris Meys <jorismeys at gmail.com> wrote:
> I initially thought this is "documented behaviour". ?sprintf says:
>
> Numeric variables with __exactly integer__ values will be coerced to
>