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 two different types, this is called "type instability". It requires the compiler (at least currently, but I know of no plans to change this) to return values in heap-allocated data structures instead of in registers. This is very expensive. See e.g. <http://julia.readthedocs.org/en/latest/manual/performance-tips/> for a discussion on type instability. Without this problem, using a separate type to denote infinity would indeed not only be a very elegant but also efficient solution. -erik > On Jan 10, 2015, at 17:44 , Jiahao Chen <jia...@mit.edu> wrote: > > 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 LLVM > intrinsics and/or hardware support for complex arithmetic? The story would be > different if there are (and I don't think we use them currently). > > The normalization of all complex infinities is essentially provided by the > C9X proposal's cproj function (which uses Inf + 0.0im as the representation > of ComplexInf). However, the C9X proposal acknowledges that there are use > cases for both topologies and thus avoids recommending one or the other. To > quote: > > "Two topologies are commonly used in complex mathematics: the complex plane > with its continuum of infinities and the Riemann sphere with its single > infinity. The complex plane is better suited for transcendental functions, > the Riemann sphere for algebraic functions. The complex types with their > multiplicity of infinities provide a useful (though imperfect) model for the > complex plane. The cproj function helps model the Riemann sphere by mapping > all infinities to one, and should be used just before any operation, > especially comparisons, that might give spurious results for any of the other > infinities." > > In this proposal, the complex plane is clearly the more fundamental space. > The Riemann sphere cannot be worked with directly; one can only work with the > shadow of the Riemann sphere projected back onto the complex plane, one > particular projection of which is provided by cproj. > > In contrast, it would be very Julian to represent the working topology with > types rather than explicitly forcing users to choose between the ordinary > complex plane and the Riemann sphere. The Riemann sphere would be a > first-class working algebra instead of being accessible indirectly via cproj. > The type model is also more composable, should there ever be a need to > intermix the two topologies. > > The situation for zeros is less dire since they compare equal with ==, > whereas the various representations of complex infinity do not. > > Thanks, > > Jiahao Chen > Staff Research Scientist > MIT Computer Science and Artificial Intelligence Laboratory > -- Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.
signature.asc
Description: Message signed with OpenPGP using GPGMail
