An example where being able to define == is useful for users...

[jiahao]

... is in complex arithmetic.

Should Complex(Inf, 0.0) == Complex(Inf, Inf)?

Sometimes, people want the ordinary complex plane where there are many infinities in all directions away from zero. The direction toward the origin matters. At other times people want the extended complex numbers on the Riemann sphere, where there is only one infinity. The direction to the origin does not matter.

Arguably, the need to provide both topologies has stymied attempts to standardize complex arithmetic in programming languages. The C9X proposal N557 provides the cproj function which normalizes all complex infinities to Inf + 0.0im, as a single canonical representation of complex infinity. 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.

(This motivating paragraph was deleted from the C99 standard.)

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, Julia allows users to represent the working topology with types rather than explicitly forcing users to choose between the ordinary complex plane and the Riemann sphere. One can write a type (say ExtendedComplex) that mirrors the ordinary Complex type, but operations on it automatically checks for the presence of complex infinities and return a special value or singleton type that is ComplexInf. Another possibility is to define ExtendedComplex without the special value, but simply require that all complex infinities be == to each other, i.e.

Complex(Inf, 0.0) != Complex(Inf, Inf)
ExtendedComplex(Inf, 0.0) == ExtendedComplex(Inf, Inf)

In this way, a programming language can provide the Riemann sphere as a first-class working algebra instead of being accessible indirectly like in C99.

The type model is also more composable, should there ever be a need to intermix the two topologies.

Ref: julia-users thread

[alanedelman]

Cute On Jan 10, 2015 6:00 PM, "Jiahao Chen" notifications@github.com wrote:

... is in complex arithmetic.

Should Complex(Inf, 0.0) == Complex(Inf, Inf)?

Sometimes, people want the ordinary complex plane where there are many infinities in all directions away from zero. The direction toward the origin matters. At other times people want the extended complex numbers on the Riemann sphere https://en.wikipedia.org/wiki/Riemann_sphere#Extended_complex_numbers, where there is only one infinity. The direction to the origin does not matter.

Arguably, the need to provide both topologies has stymied attempts to standardize complex arithmetic in programming languages. The C9X proposal N557 http://www.open-std.org/jtc1/sc22/wg14/docs/c9x/complex/ provides the cproj function which normalizes all complex infinities to Inf + 0.0im, as a single canonical representation of complex infinity. 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."

(This motivating paragraph was deleted from the C99 standard.)

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, Julia allows users to represent the working topology with types rather than explicitly forcing users to choose between the ordinary complex plane and the Riemann sphere. One can write a type (say ExtendedComplex) that mirrors the ordinary Complex type, but operations on it automatically checks for the presence of complex infinities and return a special value or singleton type that is ComplexInf. Another possibility is to define ExtendedComplex without the special value, but simply require that all complex infinities be == to each other, i.e.

Complex(Inf, 0.0) != Complex(Inf, Inf) ExtendedComplex(Inf, 0.0) == ExtendedComplex(Inf, Inf)

In this way, a programming language can provide the Riemann sphere as a first-class working algebra instead of being accessible indirectly like in C99.

The type model is also more composable, should there ever be a need to intermix the two topologies.

Ref: julia-users thread https://groups.google.com/forum/#!topic/julia-users/reTxLNXvPgo

— Reply to this email directly or view it on GitHub https://github.com/JeffBezanson/phdthesis/issues/4.