Type Conversion and Overloading problems

(Found while developing Biquaternion calculus support function collection)

Originally by D. Cyganski - July 11-13, 2007

Several non-intuitive problems with overloading and type conversions while developing the biquaternion support function collection. I have extracted the minimum code set to illustrate each of these herein.

Implicit and Explicit Type Conversions

We begin by illustrating function calling with variously typed arguments and conversions which we will break in various ways, some understandable, others not(?), below.

The cos function will produce float outcomes for float arguments

(1) -> cos(1.237)

(1)

can handle expressions that mix floats and integers

cos(1.237/2)

(2)

but will respect an integer expression, as we would want it too, by not evaluating

cos(2/3)

(3)

We can coerce the evaluation as a float by forcing the floating point evaluation of the division and typing of the outcome in a variety of ways. Each of the following forms is effective in some appropriate and understandable way. Some act explicitly on the "/" operator to force a polymorphic choice, others convert the type of the second constant in each expression with then results in a proper implicit selection of which "/" definition to use:

cos(2/3::Float)

(4)

cos((2/3)::Float)

(5)

cos(2/3$Float)

(6)

cos((2/3)$Float)

(7)

cos(2/3@Float)

(8)

cos((2/3)@Float)

(9)

But, as we would expect, it is too late to attempt coercion to Float after the fact: as illustrated here

cos(2/3)::Float

   Cannot convert the value from type Expression(Integer) to Float .

Actually there is simple workaround:

cos(2/3)::Expression(Float)

(10)

Here result is expression with floating point coefficients, which by default evaluates cosine, so result is effectively a float.

More generally, when there is a need for a deep coercion operator that operates on the inner most atomic constants, one needs to specify full type tower, with changed inner type. In such case interpreter usually is able to create needed coercion, even if there is no definition of appropriate coerce. To clarify, suppose we define:

cosf(x:Expression Integer):Expression Integer == 1+cos(x/2)

   Function declaration cosf : Expression(Integer) -> Expression(
      Integer) has been added to workspace.

which is an example of a simple function that might be defined in the course of typical work. We wish to declare functions as having Integer based arguments and outcomes because this results in behaviors that preserve our representation of Integer fractions, rather than forming approximate decimal expansions, which is perferred for purposes of analytic examination and simplification for both the human and the FriCAS system. The FriCAS book and online resources are full of examples in which this choice has been made by the authors thanks to the power of this form of expression - even though it amounts to lying to FriCAS in many cases as to the ultimate destiny of the function being defined. If we wish later to evaluate it in a more general way we need appropriate coercion or convertion (which in hard case may require few manual steps). However, one needs to use appropriate types, for example Expression(Float):

cosf(2/3)

Compiling function cosf with type Expression(Integer) -> Expression(
      Integer)

(11)

cosf((2/3)::Float)

   Conversion failed in the compiled user function cosf .

   Cannot convert the value from type Float to Expression(Integer) .

But coercion to Expression(Float) works:

cosf(2/3)::Expression(Float)

(12)

If one needs Float as result type, it is a bit more complicated:

retract(cosf(2/3)::Expression(Float))@Float

(13)

Here retract forgets about expression type and gives us a float.

In some case, in particular in the draw function appropriate convertions are done automatically, to allow floating point evaluation:

draw(cosf(x),x=0..15)

Compiling function %C with type DoubleFloat -> DoubleFloat 
   Graph data being transmitted to the viewport manager...
   FriCAS2D data being transmitted to the viewport manager...

(14)

Actually draw produces compiled function, similar to example in GeneratingCompiledFunctions

Some users think that it would be best to have a mixed type - mixed = Interger/Float. Like Maple expressions it would leave Integers as integers and floats as floats, unmolested and treated as generic constant quantities will distinguishable parts until an evalf like function that would force them entirely into the Float type. For example, in Maple, "cos(2/3)+1.2323" remains as is, while in FriCAS we get

cos(2/3)+1.2323

(15)

However, such type would be quite different from current FriCAS Expression. Also, symbolic operations on floating point values are problematic (in floating point we only have approximate result, so can not decide true equality). Keeping distinction between float and integers would significantly limit possible simplifications. Anyway, nobody wrote such a domain for FriCAS...

At first glance it looks that FriCAS already has a quantity with "mixed rule" - the constant %pi is treated as a special float which remains unevaluated and does not force combination of itself with an Integer and simply results in a new kind of Integer expression of type Pi.

3/4+%pi

(16)

However, this is done by giving %pi a special type, called Pi. Simple operations preserve this type, but ultimately it is converted to some other type, usually Expression(Integer) or Float

Overloading problems

Now let's examine properties and problems with overloading.

Define the type Q of Hamiltonian biquaternions

C:=Complex Expression Integer

(17)

Q:=Quaternion C

(18)

While developing the support functions, this definition of biquat division was introduced to simplify the format of the formulae

((x:Q)/(y:Q)):Q == x*inv(y)

   Function declaration ?/? : (Quaternion(Complex(Expression(Integer)))
      , Quaternion(Complex(Expression(Integer)))) -> Quaternion(Complex
      (Expression(Integer))) has been added to workspace.

But is this typed function in any way actually restricted to quaternions? On the face, it would appear all is normal, here's an example of integer division

x:=15/6

Compiling function / with type (Quaternion(Complex(Expression(
      Integer))), Quaternion(Complex(Expression(Integer)))) -> 
      Quaternion(Complex(Expression(Integer)))

(19)

But though the answer was right, the type is now a biquat. If we don't notice this, and procede, some things seem still to act normally, for example, no complaint from FriCAS with

cos(x)

(20)

Of course we still get a correct answers with

cos(1.237)

(21)

But let's try to apply this is a simple mixed float/integer function

cos(15.457/6)

   Conversion failed in the compiled user function / .

   Cannot convert the value from type Float to Quaternion(Complex(
      Expression(Integer))) .

Obviously the quaternion version of "/" is being invoked despite mismatches of the arguments and the supposed overloading in effect.

Actually, problem here is that "/" is defined in interpreter and interpreter does not allow overloading for user functions. To avoid "capture" of names reusable functions must be defined in Spad files (and some care is needed to structure algebra files to avoid unexpected choices).

In interpreter one can use domain qualification to avoid unwanted choice:

cos((15.457/6)$Float)

(22)

Or in prefix form

cos((/$Float())(15.457, 6))

(23)

Note that even if arguments are of exact types interpreter still uses user-defined function

cos(15.457 / 6::Float)

   Conversion failed in the compiled user function / .

   Cannot convert the value from type Float to Quaternion(Complex(
      Expression(Integer))) .

Similarly using @ to request specific type does not help:

(15.457 / 6)@Float

   Conversion failed in the compiled user function / .

   Cannot convert the value from type Float to Quaternion(Complex(
      Expression(Integer))) .

In general, redefining some core function as user function may lead to trubles in seemingly unrelated places. In compiled files overloading was resolved at compile time, so calls in compiled files are unaffected by user-defined function (they are affected when some of library files are modified and recompiled). But FriCAS library sometimes uses interpreter to define new functions on the fly. If such generated function uses "/", then (with our earlier definition) it will get user-defined version, which typically will cause trouble.

In particular, this may affect draw, since it generates function on the fly (but many function are generated in simplified way which uses hardcoded meaning of "/").