Changes
http://page.axiom-developer.org/zope/mathaction/187TroubleWithTuples/diff
--
??changed:
-> \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}
->
>
> (code snipped, see above)
>
??changed:
-*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
*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
??changed:
-In the second form, you *explicitly* tell the compiler that f2 requires two
In the second form, you *explicitly* tell the compiler that 'f2' requires two
??changed:
-arity of f1 to the length of the record. If so, I think this will only confuse
arity of 'f1' to the length of the record. If so, I think this will only confuse
++added:
<hr>
>From William Sit Tues Jul 5 12:29:00 -5:00 2005
Bill Page wrote:
PS. Sorry these discussions get longer and longer. I know you are not
shy about long discussions. Let's hope we can come to some
understanding.
> William Sit wrote:
>
> > 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.
>
> ??? But that *is* precisely the issue with which **I am** concerned.
No one is saying that *mathematically* '(A,B)' is not 'A x B'. THEY
ARE! Here, 'A x B' is only a mathematical notation for '(A,B)'.
There is no Axiom domain with that notation. 'Mapping(C,A x B)' has
no meaning in Axiom. That was the reason I said this is not the issue
here. I'll refrain from using this notation when discussing Axiom,
since it only confuses the issues. The Cartesian product in Axiom is
either '(A,B)' or 'Product(A,B)', the latter is what I should have
denoted as 'D'.
> http://en.wikipedia.org/wiki/Cartesian_closed_category
Thanks for the pointer. Always nice to learn new jargon.
> > The two are not equivalent as mappings: f is binary and g is unary.
>
> I disagree strongly with your analysis. These two things are formally
> identical. No "subtle distinction" is necessary or relevant.
We don't agree then (even though I don't know what you mean by
"formally identical"). The distinction is both subtle and still very
relevant! The distinction is between 'Mapping(C,A,B)' and
'Mapping(C,D)' when 'D' is treated as an entity in itself (that is,
when you start writing 'Product(A,B)' in Axiom for '(A,B)',
"wrapping" the components).
> > 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.
>
> I agree. My point is that the expression '(A,B)' in the Mapping
> '(A,B)->C', does in fact denote a single object, not two objects.
> It is clear that when we write 'f(a,b) == a+b' in the definition
> of the function 'f:(A,B)->C', that 'a' and 'b' denote composition
> with the necessary projections - that is precisely what we mean
> when we say that 'a' and 'b' are "formal parameters" of the
> function.
>
> Your definition of "arity" is wrong. A function with multiple
> inputs is necessarily defined over a product and has an "arity"
> equal to the size of that product.
I see, this is what we are talking about: how to count arguments.
That depends on what you meant by "multiple inputs". We cannot
discuss about arity unless we first agree to allow the notation for
many-to-one functions: 'f:(A1,A2,...,Am)->C' is a function with 'm'
inputs. According to my understanding of the previous quote, you
consider '(A1,A2, ..., Am)' as one object, living in some Cartesian
product, and yet, you also consider that, in 'f(a1, a2, ..., am)', the
'a1, a2, ..., am' are "formal parameters" and the arity is the size of
the product, namely 'm'. This is a syntactic definition and I don't
think it is different from mine (if I ever gave one).
I would like to point out, however, that the domains 'A1, A2, ..., Am'
are considered *atomic* in this counting: that is, we do not look
inside each component, to see how they are constructed. This is how I
understand the word "formal" as in "formal parameter". So arity is
the number of formal parameters. If 'A1' turns out to be a Cartesian
product of three domains, we do not view 'A1' as contributing 3 to the
arity of 'f'. Perhaps you do not agree with this. I'll discuss later
the consequence of not viewing the components as anything other than
atomic as far as arity goes.
More specifically, your definition above first wraps the multiple
inputs (the "many") as a product and then unwraps it to count the
dimension. The number of inputs never changes in the process and is
the arity.
Notice you said this: 'a' and 'b' are "formal parameters" of the
function 'f(a,b)=a+b'. The number of *formal parameters* is precisely
the arity of the function. As long as 'a' and 'b' are supplied in the
form of parameters to a function, they are counted towards the arity
of the function. You think the composition with the projection is
implied and view '(A,B)' as "a single object". To me, '(A,B)'
definitely denotes two objects: it is spelled out loud and clear. I
am not disagreeing with your interpretation that '(A,B)' is identical
to the (mathematical) Cartesian product 'A x B' and by its notation,
'A x B', just like '(A,B)' indicates two objects are involved. But
when you *encapsulate* the cartesian product by giving it the first
class status as a new domain, by denoting it as 'Product(A,B)' or
more appropriately, as I did, as 'D', that is when it becomes one
object. This process of encapsulation is not trivial, and hides 'A',
'B' from the domain despite their appearances in 'Product(A,B)'. This
is much more than the mathematical sentence "Let D be A x B."
Encapsulation is where one starts going into the realm of computer
science. This is where the "subtle distinction" originates. When we
write 'g:D->C', the arity of 'g' is one because 'D' now becomes
atomic.
Let's look at another example regarding atomicity of parameters. If I
write a mapping in Axiom, 'f:Complex Integer->Float', would you
say 'f' has arity two just because a Gaussian integer *may be*
represented by two integers? In Axiom and object oriented languages,
I would consider 'f' having only *one* input, not two. I am not
supposed to look inside what the *data representation* of a 'Complex
Integer' is (indeed, I should *not* need to know; I may need to know
about the real and imaginary parts, but the data representation, or
inputs if you will, could be very different). Of course, if you write
the domain of 'f' in terms of these parts, 'a' and 'b', of a Gaussian
integer 'a+b i', it would have arity two and the signature would then
be: 'f:Integer x Integer->Float'. You do lose the identity of
the domain 'Complex Integer'. For illustration, I could also have
represented 'a+b i' by 'x,y,z', where 'x' is 'gcd(a,b)', 'y = a/x',
and 'z = b/x', using three integers (by the way, this would also be a
possible data representation of the Cartesian product 'Integer x
Integer'). Would you then say 'f' now has three inputs and arity 3?
There are many mathematical objects that are data-represented using
products of sets, but the arity of a function is the number of
*formal* arguments, not what the data representation of the domain of
the function is. Arity is an important notion even in mathematics
(recall the chain rule for several variables). There is some slight
difference in usage though. In computer languages, the number of
arguments are sometimes not fixed, known as *variable arity*, which in
fact, amounts to *one* list of arguments. In Axiom, I would much
prefer to call a function with source 'List ANY' as having arity one.
Take a harder example, if I write a mapping 'p:POLY INT->NNI',
what is the arity of 'p'? Are you going to say it is the number of
coefficients, which depends on the degree of the given polynomial and
hence has variable arity?
So getting back to my "subtle distinction": in 'g:D->C', where 'D' is
'Product(A,B)', the arity of 'g' is one; in 'f:(A,B)->C', the arity
of 'f' is two. It is the *formal* way the function is declared that
determines the arity, and the *mathematical* equivalences among 'D',
'(A,B)', and the mathematical object 'A x B' does not necessarily
preserve arity. In mathematics, there is but one Cartesian product of
'A' and 'B'. In computing, there are two, a raw version '(A,B)' and
an encapsulated version 'Product(A,B)'. The formal use of the symbol
'D' in declaring 'f' signifies an encapsulation.
(aside) In fact, in many Axiom constructors, to get around this
encapsulation, extra parameters are necessary, for example, in
Groebner basis package, the calling convention is::
'GroebnerPackage(Dom,Expon,VarSet,Dpol)'
where 'Dom', 'Expon' and 'VarSet' are all duplicated because they are
encapsulated in 'Dpol', which is a domain of
'POLYCAT(Dom,Expon,VarSet)'. Currently, there is no other way to
extract the parameter domains from domain constructors. But this is
another story. (My wish list includes each domain constructor freeing
the encapsulated parameter domains).
Arity may change when one makes substitutions (which is composition)!
So substituting '(A,B)' by 'D' or the other way around are both
compositions with an isomorphism (note). The map 'g' is the
composition of 'h:D->(A,B)' with 'f:(A,B)->C'. The signature of the
composite 'f o h' is not the same as the original map 'f' and the
arity of the composite need not be the same, and is not the same in
this case. (Of course, 'h' is not allowed in Axiom, the source of all
these discussions! but perfectly ok mathematically for many-to-many
functions.)
(note) Here the map is of course the identity map. But it is not
instructive to think that way. Rather, because we deliberately give
the Cartesian product a new identity, not as made up of two component
parts, but as a new object. It may be helpful to think of 'D' as just
another Cartesian product of 'A' and 'B' and by universal property is
isomorphic to '(A,B)'. In an object oriented language like Axiom, new
objects must not be thought of as just the sum of its parts, which
should be hidden, but available when needed. Polynomials would be a
good example. But 'D' with the representation '(x,y,z)' given above
is simpler and we can indeed have an isomorphism between 'h:D->(A,B)'
defined by 'h(d) = (d.x * d.y, d.x * d.z)'.
> I think Axiom's definition of
> Mapping is wrong to admit more than two arguments (mapping should
> be semantically equivalent to exponentiation in a cartesian closed
> category). It is confusing and unnecessarily complicated from a
> mathematical point of view to define Mapping(C,A,B) as different
> from Mapping(C,Product(A,B)). It makes a vacuous distinction where
> none is necessary.
On the contrary. It is the idealistic mathematical view which
identifies the two that creates "vacuous" wraps and unwraps "where
none is necessary". Indeed, I would have preferred mapping to be
many-to-many so that this wrapping and unwrapping are unnecessary both
on the source and target sides. I have argued that it is convenient
not to have to wrap cartesian products with few components. Your
correct but pedantic mathematical view of 'Mapping(Y,X)' as $Y^X$
would require wrapping on both source and targets for all mappings and
turn these multi-inputs and multi-outputs into cartesian products. It
[81 more lines...]
--
forwarded from http://page.axiom-developer.org/zope/mathaction/[EMAIL PROTECTED]
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
