> Martin Maechler
> on Thu, 28 Sep 2023 12:11:27 +0200 writes:
> Gregory R Warnes
> on Sat, 23 Sep 2023 13:22:35 -0400 writes:
> > It sounds like we need to add arguments (with sensible
> > defaults) to complex(), Re(), Im(), is.na.complex() etc to
> > allow
> Gregory R Warnes
> on Sat, 23 Sep 2023 13:22:35 -0400 writes:
> It sounds like we need to add arguments (with sensible
> defaults) to complex(), Re(), Im(), is.na.complex() etc to
> allow the user to specify the desired behavior.
I don't think I'd like such extra flexib
On 9/25/23 07:05, Martin Maechler wrote:
>> Hervé Pagès
>> on Sat, 23 Sep 2023 16:52:21 -0700 writes:
> > Hi Martin,
> > On 9/23/23 06:43, Martin Maechler wrote:
> >>> Hervé Pagès
> >>> on Fri, 22 Sep 2023 16:55:05 -0700 writes:
> >> > The problem is
> Hervé Pagès
> on Sat, 23 Sep 2023 16:52:21 -0700 writes:
> Hi Martin,
> On 9/23/23 06:43, Martin Maechler wrote:
>>> Hervé Pagès
>>> on Fri, 22 Sep 2023 16:55:05 -0700 writes:
>> > The problem is that you have things that are
>> > **semantically** dif
Hi Martin,
On 9/23/23 06:43, Martin Maechler wrote:
>> Hervé Pagès
>> on Fri, 22 Sep 2023 16:55:05 -0700 writes:
> > The problem is that you have things that are
> > **semantically** different but look exactly the same:
>
> > They look the same:
>
> >> x
> > [
It sounds like we need to add arguments (with sensible defaults) to complex(),
Re(), Im(), is.na.complex() etc to allow the user to specify the desired
behavior.
--
Change your thoughts and you change the world.
--Dr. Norman Vincent Peale
> On Sep 23, 2023, at 12:37 PM, Mikael Jagan wrote:
>
On 2023-09-23 9:43 am, Martin Maechler wrote:
Hervé Pagès
on Fri, 22 Sep 2023 16:55:05 -0700 writes:
> The problem is that you have things that are
> **semantically** different but look exactly the same:
> They look the same:
>> x
> [1] NA
>> y
> [1]
> Hervé Pagès
> on Fri, 22 Sep 2023 16:55:05 -0700 writes:
> The problem is that you have things that are
> **semantically** different but look exactly the same:
> They look the same:
>> x
> [1] NA
>> y
> [1] NA
>> z
> [1] NA
>> is.na(x)
On 9/22/23 16:55, Hervé Pagès wrote:
> The problem is that you have things that are **semantically**
> different but look exactly the same:
>
> They look the same:
>
> > x
> [1] NA
> > y
> [1] NA
> > z
> [1] NA
>
> > is.na(x)
> [1] TRUE
> > is.na(y)
> [1] TRUE
> > is.na(z)
> [1] TRUE
>
> > str(x)
The problem is that you have things that are **semantically** different
but look exactly the same:
They look the same:
> x
[1] NA
> y
[1] NA
> z
[1] NA
> is.na(x)
[1] TRUE
> is.na(y)
[1] TRUE
> is.na(z)
[1] TRUE
> str(x)
cplx NA
> str(y)
num NA
> str(z)
cplx NA
but they are sem
Perhaps I shouldn't comment without having read the entire thread,
but I will: I can envision situations where I might want, e.g., 2 from
complex(r=2, i=NA_real_).
Spencer Graves
On 9/22/23 3:43 PM, Duncan Murdoch wrote:
Since the result of is.na(x) is the same on each of those
Since the result of is.na(x) is the same on each of those, I don't see a
problem. As long as that is consistent, I don't see a problem. You
shouldn't be using any other test for NA-ness. You should never be
expecting identical() to treat different types as the same (e.g.
identical(NA, NA_rea
We could also question the value of having an infinite number of NA
representations in the complex space. For example all these complex
values are displayed the same way (as NA), are considered NAs by
is.na(), but are not identical or semantically equivalent (from an Re()
or Im() point of view)
On 2023-09-22 6:38 am, Martin Maechler wrote:
Mikael Jagan
on Thu, 21 Sep 2023 00:47:39 -0400 writes:
> Revisiting this thread from April:
> https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
> where the decision (not yet backported) was made for
>
> Mikael Jagan
> on Thu, 21 Sep 2023 00:47:39 -0400 writes:
> Revisiting this thread from April:
> https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
> where the decision (not yet backported) was made for
> as.complex(NA_real_) to give NA_complex_ ins
Revisiting this thread from April:
https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
where the decision (not yet backported) was made for as.complex(NA_real_)
to give NA_complex_ instead of complex(r=NA_real_, i=0), to be consistent
with help("as.complex") and as.complex(NA) and
16 matches
Mail list logo
