[Axiom-developer] 20080819.01.tpd.patch (overload.input added (Cyganski))

[daly]

Add overload.input 
=======================================================================
diff --git a/changelog b/changelog
index 377aa85..fc15048 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,5 @@
+20080819 tpd src/input/Makefile overload.input added
+20080819 dxc src/input/overload.input added
 20080818 tpd src/input/Makefile biquat.input added
 20080818 dxc src/input/biquat.input added
 20080818 dxc "David Cyganski" (no known email)
diff --git a/src/input/Makefile.pamphlet b/src/input/Makefile.pamphlet
index 0d919d6..1c2fa8e 100644
--- a/src/input/Makefile.pamphlet
+++ b/src/input/Makefile.pamphlet
@@ -341,6 +341,7 @@ REGRES= algaggr.regress algbrbf.regress  algfacob.regress 
alist.regress  \
     nqip.regress      nsfip.regress    numbers.regress  octonion.regress \
     oct.regress       ode.regress      odpol.regress    op1.regress \
     opalg.regress     operator.regress op.regress       ovar.regress \
+    overload.regress  \
     padic.regress     parabola.regress pascal1.regress  pascal.regress \
     patch51.regress   page.regress \
     patmatch.regress  pat.regress      perman.regress   perm.regress \
@@ -613,10 +614,10 @@ FILES= ${OUT}/algaggr.input  ${OUT}/algbrbf.input    
${OUT}/algfacob.input \
        ${OUT}/nepip.input    ${OUT}/newton.input \
        ${OUT}/nlode.input    ${OUT}/none.input       ${OUT}/noonburg.input \
        ${OUT}/noptip.input   ${OUT}/nqip.input       ${OUT}/nsfip.input \
-       ${OUT}/ntube.input    ${OUT}/oct.input      ${OUT}/ode.input \
+       ${OUT}/ntube.input    ${OUT}/oct.input        ${OUT}/ode.input \
        ${OUT}/octonion.input ${OUT}/odpol.input \
        ${OUT}/opalg.input    ${OUT}/operator.input   ${OUT}/op.input \
-       ${OUT}/op1.input      ${OUT}/ovar.input \
+       ${OUT}/op1.input      ${OUT}/ovar.input       ${OUT}/overload.input \
        ${OUT}/padic.input    ${OUT}/palette.input \
        ${OUT}/parpcurv.input ${OUT}/parscurv.input   ${OUT}/parsurf.input \
        ${OUT}/pascal1.input \
@@ -927,6 +928,7 @@ DOCFILES= \
   ${DOC}/odpol.input.dvi       ${DOC}/op1.input.dvi        \
   ${DOC}/opalg.input.dvi       ${DOC}/operator.input.dvi   \
   ${DOC}/op.input.dvi          ${DOC}/ovar.input.dvi       \
+  ${DOC}/overload.input.dvi   \
   ${DOC}/padic.input.dvi       ${DOC}/palette.input.dvi    \
   ${DOC}/parabola.input.dvi    ${DOC}/parpcurv.input.dvi   \
   ${DOC}/parscurv.input.dvi    ${DOC}/parsurf.input.dvi    \
diff --git a/src/input/overload.input.pamphlet 
b/src/input/overload.input.pamphlet
new file mode 100644
index 0000000..2db85a7
--- /dev/null
+++ b/src/input/overload.input.pamphlet
@@ -0,0 +1,680 @@
+\documentclass{article}
+\usepackage{axiom}
+\begin{document}
+\title{\$SPAD/src/input overload.input}
+\author{David Cyganski}
+\maketitle
+\begin{abstract}
+Type conversion and overload problems
+\end{abstract}
+\eject
+\tableofcontents
+\eject
+<<*>>=
+)spool overload.output
+)set message test on
+)set message auto off
+)clear all
+@
+\section{Type Conversion and Overload problems}
+Several non-intuitive problems with overloading and type conversions
+arose while developing the biquaternion (see biquat.input) support
+function collection. I have extracted the minimum code set to illustrate
+each of these problems.
+
+\section{Implicit and Explicit Type Conversions}
+We begin by illustrating function calling with variously typed 
+arguments and conversion which we will break in various ways, some
+understandable, some not(?), below.
+
+The cos function will produce float outcomes for float arguments
+<<*>>=
+
+--S 1 of 28
+cos(1.237)
+--R 
+--R
+--R   (1)  0.3276321705 9891498386
+--R                                                                  Type: 
Float
+--E 1
+
+@
+can handle expressions that mix floats and integers
+<<*>>=
+
+--S 2 of 28
+cos(1.237/2)
+--R 
+--R
+--R   (2)  0.8147490934 6341557739
+--R                                                                  Type: 
Float
+--E 2
+
+@
+but will respect an integer expression, as we would want it to,
+by not evaluating
+<<*>>=
+
+--S 3 of 28
+cos(2/3)
+--R 
+--R
+--R            2
+--R   (3)  cos(-)
+--R            3
+--R                                                     Type: Expression 
Integer
+--E 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
+constand in each expression which results in a proper implicit selection
+of which ``/'' definitition to use.
+<<*>>=
+
+--S 4 of 28
+cos(2/3::Float)
+--R 
+--R
+--R   (4)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 4
+
+--S 5 of 28
+cos((2/3)::Float)
+--R 
+--R
+--R   (5)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 5
+
+--S 6 of 28
+cos(2/3$Float)
+--R 
+--R
+--R   (6)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 6
+
+--S 7 of 28
+cos((2/3)$Float)
+--R 
+--R
+--R   (7)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 7
+
+--S 8 of 28
+cos(2/address@hidden)
+--R 
+--R
+--R   (8)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 8
+
+--S 9 of 28
+cos((2/3)@Float)
+--R 
+--R
+--R   (9)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 9
+
+@
+But, as we would expect, it is too late to attempt coercion after the
+fact. Coercion operates ``on the surface and not deeply'' as illustrated
+here.
+<<*>>=
+
+--S 10 of 28
+cos(2/3)::Float
+--R 
+--R 
+--RDaly Bug
+--R   Cannot convert from type Expression Integer to Float for value
+--R       2
+--R   cos(-)
+--R       3
+--R
+--E 10
+
+@
+However, there is a real need for a deep coercion operator that operates
+on the innermost atomic constants. Suppose we define
+<<*>>=
+
+--S 11 of 28
+cosf(x:Expression Integer):Expression Integer == 1+cos(x/2)
+--R 
+--R   Function declaration cosf : Expression Integer -> Expression Integer
+--R      has been added to workspace.
+--R                                                                   Type: 
Void
+--E 11
+
+@
+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 fractions, rather than forming approximate decimal expansions, which
+is preferred for purposes of analytic examination and simplification for
+both the human and the Axiom system. The Axiom 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 Axiom in many cases as to the ultimate destiny of the function
+being defined. But woe to us if we wish later to evaluate it in a more
+general way because it is a tangled web we weave when we practice to
+decieve.
+<<*>>=
+
+--S 12 of 28
+cosf(2/3)
+--R 
+--R   Compiling function cosf with type Expression Integer -> Expression 
+--R      Integer 
+--R
+--R             1
+--R   (11)  cos(-) + 1
+--R             3
+--R                                                     Type: Expression 
Integer
+--E 12
+
+--S 13 of 28
+cosf((2/3)::Float)
+--R 
+--R   Conversion failed in the compiled user function cosf .
+--R 
+--RDaly Bug
+--R   Cannot convert from type Float to Expression Integer for value
+--R   0.6666666666 6666666667
+--R
+--E 13
+
+@
+Thus in effect once we wrap a function around an integer base definition,
+we are stuck and unable to evaluate it as a float later, unlike the core
+basic functions that can be used either way. This forces us to choose the
+Float type throughout at a loss of comprehensibility and analyzability,
+unless we seek to more than double our development type by supplying an
+overloaded integer base and Float base version of {\bf every} step of a
+sequential development of a formula.
+
+Bizarrely, the draw function seems to have the power to override the
+type problem as shown here
+<<*>>=
+
+--S 14 of 28
+--draw(cosf(x),x=0..15)
+--E 14
+
+@
+Why can't we grant this deep coercion power to some new form of floating
+point conversion operation which can be applied at will? If draw has
+this power, why not put it in the hands of the user?
+
+Alternatively, it would be best to have a {\bf mixed} type -- mixed 
+= Integer/Float. Like Maple expressions it would leave integers as
+integers and floats as floats, unmolested and treated as generic
+constant quantities with distinguishable parts until an {\bf 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 Axiom
+we get
+<<*>>=
+
+--S 15 of 28
+cos(2/3)+1.2323
+--R 
+--R
+--R   (12)  2.0181872607 769480007
+--R                                                       Type: Expression 
Float
+--E 15
+
+@
+In a way, Axiom already has a quantity treated like this -- the constant
+%pi is treated as a special float which remains unevaluated and does not
+force combination of itself with an Integer. It simply results in a new
+kind of Integer evaluation of type Pi
+<<*>>=
+
+--S 16 of 28
+3/4+%pi
+--R 
+--R
+--R         4%pi + 3
+--R   (13)  --------
+--R             4
+--R                                                                     Type: 
Pi
+--E 16
+
+@
+\section{Overloading problems}
+Now let's examine properties and problems with overloading.
+
+Define the type $Q$ of Hamiltonian biquaternions
+<<*>>=
+
+--S 17 of 28
+C:=Complex Expression Integer
+--R 
+--R
+--R   (14)  Complex Expression Integer
+--R                                                                 Type: 
Domain
+--E 17
+
+--S 18 of 28
+Q:=Quaternion C
+--R 
+--R
+--R   (15)  Quaternion Complex Expression Integer
+--R                                                                 Type: 
Domain
+--E 18
+
+@
+While developing the support functions, this definition of biquat
+division was introduced to simplify the format of the formulae
+<<*>>=
+
+--S 19 of 28
+((x:Q)/(y:Q)):Q == x*inv(y)
+--R 
+--R   Function declaration ?/? : (Quaternion Complex Expression Integer,
+--R      Quaternion Complex Expression Integer) -> Quaternion Complex 
+--R      Expression Integer has been added to workspace.
+--R                                                                   Type: 
Void
+--E 19
+
+@
+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
+<<*>>=
+
+--S 20 of 28
+x:=15/6
+--R 
+--R   Compiling function / with type (Quaternion Complex Expression 
+--R      Integer,Quaternion Complex Expression Integer) -> Quaternion 
+--R      Complex Expression Integer 
+--R
+--R         5
+--R   (17)  -
+--R         2
+--R                                  Type: Quaternion Complex Expression 
Integer
+--E 20
+
+@
+But though the answer was right, the type is now a biquat. If we don't
+notice this, and proceed, some things seem still to act normally,
+for example, no complaint from Axiom with
+<<*>>=
+
+--S 21 of 28
+cos(x)
+--R 
+--R
+--R             5
+--R   (18)  cos(-)
+--R             2
+--R                                                     Type: Expression 
Integer
+--E 21
+
+@
+Of course, we still get a correct answer with
+<<*>>=
+
+--S 22 of 28
+cos(1.237)
+--R 
+--R
+--R   (19)  0.3276321705 9891498386
+--R                                                                  Type: 
Float
+--E 22
+
+@
+But let's try to apply this as a simple mixed float/integer function
+<<*>>=
+
+--S 23 of 28
+cos(15.457/6)
+--R 
+--R   Conversion failed in the compiled user function / .
+--R 
+--RDaly Bug
+--R   Cannot convert from type Float to Quaternion Complex Expression 
+--R      Integer for value
+--R   15.457
+--R
+--E 23
+
+@
+Obviously the quaternion version of ``/'' is being invoked despite
+mismatches of the arguments and the supposed overloading in effect.
+Well, what if we built a new cosine function that forced the form of
+the arguments into certain types to avoid mismatch?
+<<*>>=
+
+--S 24 of 28
+c(y:Float):Float == cos(y)
+--R 
+--R   Function declaration c : Float -> Float has been added to workspace.
+--R                                                                   Type: 
Void
+--E 24
+
+@
+At first this seems to work, we can still evaluate a float
+<<*>>=
+
+--S 25 of 28
+c(1.237)
+--R 
+--R   Compiling function c with type Float -> Float 
+--R
+--R   (21)  0.3276321705 9891498386
+--R                                                                  Type: 
Float
+--E 25
+
+@
+and we can even get a float answer when we introduce the integer coercible
+biquat variable value generated from the above.
+<<*>>=
+
+--S 26 of 28
+c(x)
+--R 
+--R
+--R   (22)  - 0.8011436155 4693371483
+--R                                                                  Type: 
Float
+--E 26
+
+@
+But that was only misdirection, because this breaks down for reasonable
+expressions because of the ``/'' operation still not being resolved
+correctly.
+<<*>>=
+
+--S 27 of 28
+c(1.237/2)
+--R 
+--R   Conversion failed in the compiled user function / .
+--R 
+--RDaly Bug
+--R   Cannot convert from type Float to Quaternion Complex Expression 
+--R      Integer for value
+--R   1.237
+--R
+--E 27
+
+@
+Rather than complaining about it, what if we tried the various coercions
+that served to solve the similar type conversion problem we had when 
+just dealing with Integer Fraction versus Floats at the top of the page.
+Our results are mixed. Recall that each of the following worked in the
+previous case, producing the correct floating result in each case.
+<<*>>=
+
+--S 28 of 28
+cos(2/3::Float)
+--R 
+--R
+--R             2
+--R   (23)  cos(-)
+--R             3
+--R                                                     Type: Expression 
Integer
+--E 28
+
+--S 29 of 28
+cos((2/3)::Float)
+--R 
+--R
+--R   (24)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 29
+
+--S 30 of 28
+cos(2/3$Float)
+--R 
+--R
+--R             2
+--R   (25)  cos(-)
+--R             3
+--R                                                     Type: Expression 
Integer
+--E 30
+
+--S 31 of 28
+cos((2/3)$Float)
+--R 
+--R
+--R   (26)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 31
+
+--S 32 of 28
+cos(2/address@hidden)
+--R 
+--R
+--R             2
+--R   (27)  cos(-)
+--R             3
+--R                                                     Type: Expression 
Integer
+--E 32
+
+--S 33 of 28
+cos((2/3)@Float)
+--R 
+--R 
+--RDaly Bug
+--R   An expression involving @ Float actually evaluated to one of type 
+--R      Quaternion Complex Expression Integer . Perhaps you should use ::
+--R      Float .
+--E 33
+
+@
+Try these examples with our type constrained function, which has better
+luck now
+<<*>>=
+
+--S 34 of 28
+c(2/3::Float)
+--R 
+--R
+--R   (28)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 34
+
+--S 35 of 28
+c((2/3)::Float)
+--R 
+--R
+--R   (29)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 35
+
+--S 36 of 28
+c(2/3$Float)
+--R 
+--R
+--R   (30)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 36
+
+--S 37 of 28
+c((2/3)$Float)
+--R 
+--R
+--R   (31)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 37
+
+--S 38 of 28
+c(2/address@hidden)
+--R 
+--R
+--R   (32)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 38
+
+--S 39 of 28
+c((2/3)@Float)
+--R 
+--R 
+--RDaly Bug
+--R   An expression involving @ Float actually evaluated to one of type 
+--R      Quaternion Complex Expression Integer . Perhaps you should use ::
+--R      Float .
+--E 39
+
+@
+Could the above problems have been avoided by not assigning types
+to the function we defined? Let's repeat the entire example with
+this single change for the function c2
+<<*>>=
+
+--S 40 of 28
+c2(y) == cos(y)
+--R 
+--R                                                                   Type: 
Void
+--E 40
+
+--S 41 of 28
+c2(1.237)
+--R 
+--R   Compiling function c2 with type Float -> Float 
+--R
+--R   (34)  0.3276321705 9891498386
+--R                                                                  Type: 
Float
+--E 41
+
+--S 42 of 28
+c2(x)
+--R 
+--R   There are 2 exposed and 6 unexposed library operations named cos 
+--R      having 1 argument(s) but none was determined to be applicable. 
+--R      Use HyperDoc Browse, or issue
+--R                               )display op cos
+--R      to learn more about the available operations. Perhaps 
+--R      package-calling the operation or using coercions on the arguments
+--R      will allow you to apply the operation.
+--R   Cannot find a definition or applicable library operation named cos 
+--R      with argument type(s) 
+--R                    Quaternion Complex Expression Integer
+--R      
+--R      Perhaps you should use "@" to indicate the required return type, 
+--R      or "$" to specify which version of the function you need.
+--R   AXIOM will attempt to step through and interpret the code.
+--R
+--R             5
+--R   (35)  cos(-)
+--R             2
+--R                                                     Type: Expression 
Integer
+--E 42
+
+@
+But that was only misdirection, because this breaks down for
+reasonable expressions
+<<*>>=
+
+--S 43 of 28
+c2(1.237/2)
+--R 
+--R   Conversion failed in the compiled user function / .
+--R 
+--RDaly Bug
+--R   Cannot convert from type Float to Quaternion Complex Expression 
+--R      Integer for value
+--R   1.237
+--R
+--E 43
+
+@
+and various attempts at coercion also fail -- compare these results
+to the previous ones
+<<*>>=
+
+--S 44 of 28
+c2(2/3::Float)
+--R 
+--R
+--R             2
+--R   (36)  cos(-)
+--R             3
+--R                                                     Type: Expression 
Integer
+--E 44
+
+--S 45 of 28
+c2((2/3)::Float)
+--R 
+--R
+--R   (37)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 45
+
+--S 46 of 28
+c2(2/3$Float)
+--R 
+--R
+--R             2
+--R   (38)  cos(-)
+--R             3
+--R                                                     Type: Expression 
Integer
+--E 46
+
+--S 47 of 28
+c2((2/3)$Float)
+--R 
+--R
+--R   (39)  0.7858872607 7694800072
+--R                                                                  Type: 
Float
+--E 47
+
+--S 48 of 28
+c2(2/address@hidden)
+--R 
+--R
+--R             2
+--R   (40)  cos(-)
+--R             3
+--R                                                     Type: Expression 
Integer
+--E 48
+
+--S 49 of 28
+c2((2/3)@Float)
+--R 
+--R 
+--RDaly Bug
+--R   An expression involving @ Float actually evaluated to one of type 
+--R      Quaternion Complex Expression Integer . Perhaps you should use ::
+--R      Float .
+--E 49
+
+@
+Lastly, we cannot now use the graph function, draw, on such a function 
+since the wrong ``/'' function is used, contrary to the bypassing of
+internal types we saw take place with draw in the example prior to the
+introduction of operator overloading.
+<<*>>=
+
+--S 50 of 28
+--draw(c(x),x=0..15)
+--E 50
+
+@
+{\sl Not safe at any speed}. Most oddly, the ordinary cos() function which
+exposes no ``/'' division Now fails to work with draw despite the fact
+that we just saw it above still working with Integer and Float arguments
+applied directly.
+<<*>>=
+
+--S 51 of 28
+--draw(cos(x),x=0..15)
+--E 51
+
+)spool 
+)lisp (bye)
+ 
+@
+\eject
+\begin{thebibliography}{99}
+\bibitem{1} nothing
+\end{thebibliography}
+\end{document}