[Axiom-developer] [Tuples Products And Records]

[wyscc]

Changes 
http://page.axiom-developer.org/zope/mathaction/TuplesProductsAndRecords/diff
--

++added:

<hr>
From: wyscc Wed Jul 6 00:49:00 -5:00 2005

billpage wrote:

> makes no difference. My view is that
> (code snipped)
> should have the same meaning as the previous expression.

Of course you are correct here, but you are still missing my point. I was using 
'D' for 'Product(A,B)' to emphasize that in 'Product(A,B)', 'A' and 'B' are no 
longer by default available because they have been encapsulated (encapsulation 
need neither necessarily hide nor not hide information). But the distinction is 
that 'Product(A,B)' is not the same as '(A,B)' computationally, as it is 
currently in Axiom, and no amount of mathematical identifying each to 'A x B' 
is going to erase the distinction. This is computation, not mathematics! In 
symbolic computation, many concepts in mathematics split into computational 
branches because of different applications of the same mathematical domain. 
Sparse matrices versus dense matrices is an example.

> But the concept of a [Cartesian Closed Category] is much
> more important than mere jargon! 

I was half-joking. I went and read the articles (about currying, for example) 
until I had to stop! But a first step is always getting familiar with the 
jargon. There are relatively few ideas but lots of jargon for the same thing. 
So currying is nothing but specialization, something mathematicians have used 
to turn say group multiplication into the group acting on itself. At the end of 
the day, one still has to write the binary multiplication routine to compute.

> In the context of Axiom I strongly object to creating such
> "subtle distinctions". Axiom is intended to be a system for
> doing mathematics with a computer. 

The distinction is really not "subtle" but a key one for object oriented 
programming (of course I didn't realize this earlier since I was, and still am, 
just exploring along with you). Unfortunately, this seems unavoidable in 
computing. In order to be able to speak of a polynomial, say, as an abstract 
mathematical object (so we can differentiate, integrate, etc) in as general a 
fashion as possible (meaning allowing different data representation, for one, 
but ignoring these at the same time), we have to omit mentioning the details 
until we need them for computation. So we can say 'differentiate(p)' when 'p' 
is a polynomial, no matter what domain in POLYCAT p comes from. I think that is 
what distinguishes Axiom from M&M.

We are (and certainly Axiom is) very far away from your ideal of "doing 
mathematics" using a computer.  We can't really do "symbolic computation" the 
way a human mind can. Consider how a computer can interpret what mathematicians 
call ... (ellipsis) and compute with it. If you know any language that can 
handle that (and I don't mean just sums or products but something iterated in 
general, like iterated integrals with ellipsis between two integral signs), I 
would be very interested.

> > 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).
> 
> To me, when applied to Axiom this is wrong! wrong! wrong! :)
> We do not need this kind of distinction.

May be not for simple constructs like the Cartesian product (even though there 
is still a role for encapsulation).
How about there is just one polynomial ring in several variables over say the 
integers, but Axiom has DMP, HDMP, GDMP, SMP, and POLY? What would be the 
single implementation of the polynomial ring be?

> > 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?
> 
> No. I think the product '(A,B)' in the signature of a function
> (mapping) such as 'f:(A,B)->C' plays a more fundamental role in
> the semantics of the Axiom programming language than derived
> domains such 'Complex Integer'. That is why the domain 'Record'
> is considered a "primative". These are the basic types of things
> that we need to define more complex things.

No quarrel with that, but where do you draw the line? When does a domain become 
"derived enough" to count as one object one parameter? You did not answer my 
question on arity. I already commented on the role of 'Record'.
 
> > It is the idealistic mathematical view which identifies the two
> > that creates "vacuous" wraps and unwraps "where none is necessary".
> 
> No. There are no unnecessary "wraps and unwraps". This is just
> normal paramater passing. The compiler only needs to do what
> is usually necessary to pass, for example the tuple (a,b) i.e.
> object of type Product(A,B), to the body of the function by
> pushing the values of the projections onto the stack.

I can't agree that you can equate a tuple '(a,b)' with an object of type 
'Product(A,B)' because such equating does not generalize. In your mindset, 
'Product(A,B)' *is* '(A,B)'. Just because a tuple '(a,b)' is *one* way, even 
the canonical way, to represent objects of 'Product(A,B)' does not give it the 
right to be the only way. There are other ways and other uses of 
'Product(A,B)'. The design of the domain 'Product(A,B)' need not be dominated 
by the two projection maps. There are also more complicated tuples if every 
domain is unwrapped to the basics like integers.  If you identify 
'Product(A,B)' with '(A,B)', so there is no wrap and unwrap, then why not just 
use '(A,B)'? Is it just because you rather *rename* '(A,B)' as 'Product(A,B)' 
in function declarations? (That would be syntactic sugar if the current 
'Product' is removed or renamed)

> > It makes no sense to encapsulate objects from unrelated domains
> > just because they happen to be the argument types of some function.
> 
> I disagree. This makes perfectly good sense in the context of the
> cartesian closed category CAT of small categories. I think this
> the foundation on which all of Axiom's algebra and it's programming
> language should be based.

Care to elaborate? I fail to follow your logic. You on the one hand want 
'Product(A,B)' not to encapsulate 'A' and 'B' (by identifying it as '(A,B)') 
and on the other hand want to encapsulate all parameters? Even though 
encapsulation wraps data into a structure, its use goes far beyond just that. 
One main programming design is careful planning for information hiding that 
encapsulation facilitates (but not necessarily always). Needlessly 
encapsulating the set of parameters of every function only creates needless 
coercions.

Consider the two ways of coding

<pre>
g:(INT,INT)->INT
g(a,b)==a+b
g(1,2)
f:Product(INT,INT)->INT
f(z)==(selectfirst z)+selectsecond(z)
f(makeprod(1,2))
</pre>

 Which is more convenient?

 
> > why should the data-structures be the "canonical" cartesian product
> > structure
> 
> Precisely because of the special role that products play in the
> concept of a cartesian closed category.

So, use tuples.
Is CCC the only kind of categories in symbolic computation?

William


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