Handling Imaginary numbers in Python values.

[rocky]

Recently, I was considering revising Transpose to utilize NumPy's transpose function when the matrix is populated with 2-dimensional numbers.

This uncovered an issue that I request a discussion on here.

When the matrix doesn't have complex numbers, we are fine. But as soon as a complex number appears in a Matrix, we have a problem.

In Python's complex type, the real and imaginary parts are float types; the float type is roughly equivalent to MachineReal in Mathics3/WMA.

But in Mathics3 and WMA, a Complex can be made of other kinds of numbers, such as Integer, Real, and Rational. And while NumPy supports different kinds of floats, it doesn't allow for integer real and imaginary parts.

This limits what can be allowed in a Python literal value for a Mathics3 literal value, that is, a Python value that exactly represents is Mathics3 literal value.

Now consider the Mathics3 literal expression {{0, I}, {0, 0}}. You might think, as I did, that this could be represented in Python as ((0, 1j), (0, 0)). But this is not correct since the real and imaginary parts of 1j have type floats while in Mathics3, they are Integers.

Can we use SymPy's Complex datatype instead? The good news is that SymPy does allow the Real and Imaginary parts of a complex to be Integers, Floats, and presumably other numeric datatypes.

However, equality works differently from Python and Mathics3/WMA. A sympy.core.numbers.Float type does not seem to be equal == to an sympy.core.numbers.integer type when they would be == in Mathics3/WMA and Python.

[axkr]

• the '==' operator in WMA is head Equal
• the'===' operator in WMA is Head SameQ

Roughly said:

• if you're calculating in "numeric mode" all numbers must be evaluated to floating point based numbers and compared with "WMA Equal-operator" and a "very small floating-point tolerance" to test for equality.
• if you're calculating in "symbolic mode" all numbers should be "exact numbers"
• if a user uses a floating-point number in a function with attribute NumericFunction WMA often implicitly switches to "numeric mode"
• there are exceptions like the integer functions Floor,Ceiling,... which return a symbolic number from a float input

[rocky]

Thanks for the information.

But with this, we are not out of the woods yet.

Okay, so there is a numeric evaluation mode and a symbolic/exact evaluation mode.
In numeric evaluation mode, using Python floats (WMA Real) instead of Python ints (WMA Integer) is not a concern, due to the looseness of how Equal or == works.

But in symbol/exact evaluation mode, it is a concern.

When parsing the Mathics3 expressions, we have the opportunity to save their Python equivalent when the expression is a literal. This can help us a lot by reducing conversions all over the place from Mathics3 into Python, SymPy, or NumPy.

Maybe someday we'll have a type inference system that can indicate when an exact value is needed and when it is not. But for now, in parsing, we don't know whether we need the exact representation or not.

One possibility might be to mark whether an expression's corresponding literal value (the Python/Sympy/Numpy-friendly representation) is exact or numeric. If exact mode is needed, but the value used in the literal is numeric/inexact, we can then fall back to the Mathics3 representation rather than the literal value representation.

A subtlety here, though, is that various Atoms or leaf nodes in an Expression might need to be "boxed". That is, putting it inside a container that allows for this additional property (and others) to be stored.

In many Atoms classes, such as String, Real, Integer, and Complex, a value is stored internally only once. This reduces memory, reduces the need for garbage collection, and decreases the virtual memory live pages. So a Real 1. might represent an exact value in one context, like 1. + 1.5 but might be numeric or inexact in expression I + 1.5. I is supposed to contain Integer 1 for its imaginary part, but instead would be Real 1. if we used NumPy's or Python's version of I.

However, the object Real 1. exists in our system only once.

It so happens that the boxing issue also came up recently when I was trying to expand the notion of adding source-code locations to the nodes making up a Mathics3 Expression tree.

[rocky]

I just looked at SymPy's code for Sympy.I. .

We don't handle Mod properly. And it integrates with the mpmath library nicely. I think we should start moving our implementation of numbers over to use SymPy as a base rather than basically duplicate a lot of code (with in some cases, less functionality)