Re: [julia-users] Complex infinity

On Jan 10, 2015, at 18:22 , Jiahao Chen wrote: > > On Sat, Jan 10, 2015 at 6:12 PM, Erik Schnetter wrote: > This may lead to problems with nans. For example, 1.0/(0.0, 0.0) is (inf, > nan), and 1.0/(inf,nan) is (0.0, nan); multiply by (1, im) yields (nan, nan), > and all information is lost. W

Re: [julia-users] Complex infinity

On Jan 10, 2015, at 18:15 , Jiahao Chen wrote: > > Ah, I see your concern about the singleton ComplexInf type. This sounds just > like the very same design issue behind NA in DataArrays and Nullables in 0.4. Yes, it is. But no matter how efficient this will be -- this approach will always requ

Re: [julia-users] Complex infinity

On Sat, Jan 10, 2015 at 6:12 PM, Erik Schnetter wrote: > This may lead to problems with nans. For example, 1.0/(0.0, 0.0) is (inf, > nan), and 1.0/(inf,nan) is (0.0, nan); multiply by (1, im) yields (nan, > nan), and all information is lost. With a proper treatment, this would be > (0.0, 0.0) ins

Re: [julia-users] Complex infinity

Ah, I see your concern about the singleton ComplexInf type. This sounds just like the very same design issue behind NA in DataArrays and Nullables in 0.4.

Re: [julia-users] Complex infinity

This may lead to problems with nans. For example, 1.0/(0.0, 0.0) is (inf, nan), and 1.0/(inf,nan) is (0.0, nan); multiply by (1, im) yields (nan, nan), and all information is lost. With a proper treatment, this would be (0.0, 0.0) instead. -erik > On Jan 10, 2015, at 18:07 , Jiahao Chen wrote:

Re: [julia-users] Complex infinity

What I was imagining was a new type, called e.g. ExtendedComplex (or RiemannComplex) that substitutes for the current Complex type. I didn't know about cproj, but I was imagining something equivalent to RiemannComplex calls cproj after every complex number operation. If a function can return tw

Re: [julia-users] Complex infinity

Another possibility that occurs to me is to redefine the == equality comparison. Currently this is defined as ==(z::Complex, w::Complex) = (real(z) == real(w)) & (imag(z) == imag(w)) but for some purposes it may be sufficient to redefine this as ==(z::Complex, w::Complex) = if isinf(z) && isinf(

Re: [julia-users] Complex infinity

Julia's support for complex arithmetic is written purely in Julia, so I don't see how my suggestion to implement a new type is necessarily slower than hard-coding in special values indicating complex infinity. The code branches that one would need would simply be put in different places. Are there

Re: [julia-users] Complex infinity

Instead of defining a new type, it should be faster to "normalize" complex numbers after every operation. The current, IEEE-based complex numbers not only have various representations of infinity, but also for zero, since they distinguish between +0.0 and -0.0. Thus, the normalization would map

Re: [julia-users] Complex infinity

Whoops, that version didn't work. Try this version instead: abstract ExtendedComplex{T<:Real} immutable ComplexInf{T<:Real} <: ExtendedComplex{T} end immutable FiniteExtendedComplex{T<:Real} <: ExtendedComplex{T} z :: Complex{T} end function FiniteExtendedComplex{T<:Real}(r::T, i::T)

Re: [julia-users] Complex infinity

You might be interested in Issue #5234 , where I tried to catalogue issues arising from nonfinite floating-point computations in the ordinary complex plane (without closure on the Riemann sphere). Being able to switch between complex and extended com