[Axiom-developer] [#187 trouble with tuples] [#187 trouble with tuples] functions are objectsof type Mapping

[William Sit]

Changes 
http://page.axiom-developer.org/zope/mathaction/187TroubleWithTuples/diff
--
Bill Page wrote:

> From a mathematical point of view clearly the idea that
> Mapping(T, A, B) denotes the class of mappings from (A, B)
> into T implies that (A,B) denotes some kind of set, i.e.
> the Product(A,B).

> William Sit wrote:
> 
> > I don't agree. When one wraps up something into a single object,
> > it is inconvenient to look at the parts without unwrapping.

(Disclaimer: my earlier response above is not directly to your new comment. See
previous post. I agree that the Cartesian product of A, B is implied in the
notion of Mapping(T,A,B). But that is *not* the issue here.)

In most mathematics I know, products, if they exist, are formed from objects of
the same category. If $f:A \times B \rightarrow C$ is a mapping, where $A$, $B$
are from the same category, we may sometimes let $D = A \times B$ and identify
$f$ as $f:D \rightarrow C$ (let me rename this to $g:D \rightarrow C$). However,
there is this subtle distinction in the way we give the definition of $f$ and
$g$. In the first case, we would write f(a,b) = c, where as in the second case,
we would write g(d) = c, with d = (a,b). The two are *not* equivalent as
*mappings*: $f$ is binary and $g$ is unary. To define $c$ to be $a+b$ in both
cases, say, it is straight forward in the first case $f(a,b)=a+b$. In the second
case, there is necessarily a composition with two projection maps $p:D
\rightarrow A$ and $q:D \rightarrow B$, where $p(d)=a$, $q(d) = b$. The true
definition of $g$ is: $g(d) = p(d)+q(d)$. If the target $C$ is more involved,
say $C$ is D^2$ and $f$ is meant to be the diagonal map $D \rightarrow D^2$,
then the $g$-form would be more preferrable: $g(d) = (d,d)$.

In short, Axiom imitates closely mathematics and gives us both ways to define
mappings. When the data structure is complicated, a Record is preferred.

In mathematics, we have been trained to be sloppy with details that have been
seen too often already, so as to contemplate at newer and more abstract levels. 
We tend to see things as the same via isomorphisms. Now, we are forced to think
about all the details again in using Axiom. That is the main hurdle and a steep
"relearning" curve. Perhaps in 2032 (I'm not going to let this be a sliding
window of 30 years!), computer algebra can be smart enough to incorporate all
theorems (isomorphisms included) from a self-generated data-base and we don't
have to "relearn" what is in our subconsciousness.

> But [Cartesian Product] is implemented as a Record and the
> domain Record is a primative in Axiom. So my proposal above
> amounts to stating, for example, that:
> \begin{axiom}
> f1:Record(a:INT,b:FLOAT)->FLOAT
> f1(arg)==arg.b+arg.a
> f1[1,1.1]
> \end{axiom}
> 
> should be viewed as equivalent to
> \begin{axiom}
> f2:(INT,FLOAT)->FLOAT
> f2(a,b)==a+b
> f2(1,1.1)
> \end{axiom}
> 
> And in fact after a simple optimization, the compiler should
> be able to produce equivalent internal lisp code.

Axiom is a strongly typed language with object oriented roots. A Record, even if
it is a primary domain, is a single object. You cannot have the compiler
*sometimes* treat it as one object and *sometimes* not. In your example, f1 has
arity one (requiring two projection maps), and f2 has arity two. In general, the
compiler reads in a list of arguments for a function and then parses it. I don't
see much optimization (the parser needs to work one level deeper to parse the
content of the record,and there is *no way* the generated code can be simplified
to remove this level because the arities are different).

In the second form, you *explicitly* tell the compiler that f2 requires two
*objects* as inputs. In the first, only one. In terms of data structure, Axiom
*must* view arg as a Record object (note your use of square brackets). In your
scenario, you seem to suggest that the compiler *automatically* changes the
arity of f1 to the length of the record. If so, I think this will only confuse
users, even if that change is restricted to Records appearing as function
signatures.

There is also another problem with your automatic translation. In a record, the
*order* of the items is not important (conceptually speaking), each field is
tagged by an identifier. In a tuple, the physical order is important and items
are not tagged.

Please note also that Axiom *hides* the data representation of objects from code
external to the object constructors. So sometimes these projections are *not*
available (for 'Product' and domains of 'DirectProductCategory', they should be,
and are).

William

--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden