>>>>> Richard O'Keefe
>>>>> on Fri, 6 Sep 2024 17:24:07 +1200 writes:
> The thing is that real*complex, complex*real, and complex/real are not
> "complex arithmetic" in the requisite sense.
> The complex numbers are a vector space over the reals,
Yes, but they _also_ are field (and as others have argued mathematically only
have one infinity point),
and I think here we are fighting with which definition should
take precedence here.
The English Wikipedia page is even more extensive and precise,
https://en.wikipedia.org/wiki/Complex_number (line breaking by me):
" The complex numbers form a rich structure that is simultaneously
- an algebraically closed field,
- a commutative algebra over the reals, and
- a Euclidean vector space of dimension two."
our problem "of course" is that we additionally add +/- Inf for
the reals and for storage etc treating them as a 2D vector space
over the reals is "obvious".
> and complex*real and real*complex are vector*scalar and scalar*vector.
> For example, in the Ada programming language, we have
> function "*" (Left, Right : Complex) return Complex;
> function "*" (Left : Complex; Right : Real'Base) return Complex;
> function "*" (Left : Real'Base; Right : Complex) return Complex;
> showing that Z*R and Z*W involve *different* functions.
> It's worth noting that complex*real and real*complex just require two
> real multiplications,
> no other arithmetic operations, while complex*complex requires four
> real multiplications,
> an addition, and a subtraction. So implementing complex*real by
> conventing the real
> to complex is inefficient (as well as getting the finer points of IEEE
> arithmetic wrong).
I see your point.
> As for complex division, getting that *right* in floating-point is
> fiendishly difficult (there are
> lots of algorithms out there and the majority of them have serious flaws)
> and woefully costly.
> It's not unfair to characterise implementing complex/real
> by conversion to complex and doing complex/complex as a
> beginner's bungle.
ouch! ... but still I tend to acknowledge your point, incl the "not unfair" ..
> There are good reasons why "double", "_Imaginary double", and "_Complex
double"
> are distinct types in standard C (as they are in Ada),
interesting. OTOH, I think standard C did not have strict
standards about complex number storage etc in the mid 1990s
when R was created.
> and the definition of multiplication
> in G.5.1 para 2 is *direct* (not via complex*complex).
I see (did not know about) -- where can we find 'G.5.1 para 2'
> Now R has its own way of doing things, and if the judgement of the R
> maintainers is
> that keeping the "convert to a common type and then operate" model is
> more important
> than getting good answers, well, it's THEIR language, not mine.
Well, it should also be the R community's language,
where we, the R core team, do most of the "base" work and also
emphasize guaranteeing long term stability.
Personally, I think that
"convert to a common type and then operate"
is a good rule and principle in many, even most places and cases,
but I hate it if humans should not be allowed to break good
rules for even better reasons (but should rather behave like algorithms ..).
This may well be a very good example of re-considering.
As mentioned above, e.g., I was not aware of the C language standard
being so specific here and different than what we've been doing
in R.
> But let's not pretend
> that the answers are *right* in any other sense.
I think that's too strong -- Jeff's computation (just here below)
is showing one well defined sense of "right" I'd say.
(Still I know and agree the Inf * 0 |--> NaN
rule *is* sometimes undesirable)
> On Fri, 6 Sept 2024 at 11:07, Jeff Newmiller via R-help
> <r-help@r-project.org> wrote:
>>
>> atan(1i) -> 0 + Inf i
>> complex(1/5) -> 0.2 + 0i
>> atan(1i) -> (0 + Inf i) * (0.2 + 0i)
-> 0*0.2 + 0*0i + Inf i * 0.2 + Inf i * 0i
>> infinity times zero is undefined
-> 0 + 0i + Inf i + NaN * i^2
-> 0 + 0i + Inf i - NaN
-> NaN + Inf i
>>
>> I am not sure how complex arithmetic could arrive at another answer.
>>
>> I advise against messing with infinities... use atan2() if you don't
actually need complex arithmetic.
>>
>> On September 5, 2024 3:38:33 PM PDT, Bert Gunter
<bgunter.4...@gmail.com> wrote:
>> >> complex(real = 0, imaginary = Inf)
>> >[1] 0+Infi
>> >
>> >> Inf*1i
>> >[1] NaN+Infi
>> >
>> >>> complex(real = 0, imaginary = Inf)/5
>> >[1] NaN+Infi
>> >
>> >See the Note in ?complex for the explanation, I think. Duncan can
correct
>> >if I'm wrong.
>> >
>> >-- Bert
[...................]
Martin
--
Martin Maechler
ETH Zurich and R Core team
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
