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.
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 fricas (1) -> cos(1.237)
Type: Floatcan handle expressions that mix floats and integers fricas cos(1.237/2)
Type: Floatbut will respect an integer expression, as we would want it too, by not evaluating fricas cos(2/3)
Type: Expression(Integer)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: fricas cos(2/3::Float)
Type: Floatfricas cos((2/3)::Float)
Type: Floatfricas cos(2/3$Float)
Type: Floatfricas cos((2/3)$Float)
Type: Floatfricas cos(2/3@Float)
Type: Floatfricas cos((2/3)@Float)
Type: FloatBut, as we would expect, it is too late to attempt coercion to Float after the fact: as illustrated here fricas cos(2/3)::Float Actually there is simple workaround: fricas cos(2/3)::Expression(Float)
Type: Expression(Float)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 fricas cosf(x:Expression Integer):Expression Integer == 1+cos(x/2) Type: Voidwhich 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): fricas cosf(2/3) fricas Compiling function cosf with type Expression(Integer) -> Expression( Integer)
Type: Expression(Integer)fricas cosf((2/3)::Float) But coercion to Expression(Float) works: fricas cosf(2/3)::Expression(Float)
Type: Expression(Float)If one needs Float as result type, it is a bit more complicated: fricas retract(cosf(2/3)::Expression(Float))@Float
Type: FloatHere 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: fricas draw(cosf(x), fricas Compiling function %B with type DoubleFloat -> DoubleFloat Graph data being transmitted to the viewport manager... FriCAS2D data being transmitted to the viewport manager...
Type: TwoDimensionalViewport?Actually draw produces compiled function, similar to example in GeneratingCompiledFunctions Some users think that
it would be best to have a fricas cos(2/3)+1.2323
Type: Expression(Float)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. fricas 3/4+%pi
Type: PiHowever, 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
Now let's examine properties and problems with overloading. Define the type Q of Hamiltonian biquaternions fricas C:=Complex Expression Integer
Type: Typefricas Q:=Quaternion C
Type: TypeWhile developing the support functions, this definition of biquat division was introduced to simplify the format of the formulae fricas ((x:Q)/(y:Q)):Q == x*inv(y) Type: VoidBut 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 fricas x:=15/6 fricas Compiling function / with type (Quaternion(Complex(Expression( Integer))),
Type: Quaternion(Complex(Expression(Integer)))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 fricas cos(x)
Type: Expression(Integer)Of course we still get a correct answers with fricas cos(1.237)
Type: FloatBut let's try to apply this is a simple mixed float/integer function fricas cos(15.457/6) 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: fricas cos((15.457/6)$Float)
Type: FloatOr in prefix form fricas cos((/$Float())(15.457,
Type: FloatNote that even if arguments are of exact types interpreter still uses user-defined function fricas cos(15.457 / 6::Float) Similarly using @ to request specific type does not help: fricas (15.457 / 6)@Float 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 "/"). |