axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] [#187 trouble with tuples] [#187 trouble with tuples]


From: William Sit
Subject: [Axiom-developer] [#187 trouble with tuples] [#187 trouble with tuples]
Date: Sat, 02 Jul 2005 11:54:29 -0500

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


Bill Page wrote:
> I think a domain such as Product deserves (much) more documentation
> then just to be listed in Appendix C! Of course that is also true of
> many other domains in Axiom. It worries me that a 1000+ page book is
> not nearly enough to properly document more than a small number of
> Axiom's mathematical constructs. How big of a book do we need? Is the
> idea of a "book" adequate at all? In fact Appendix C seems to be of
> very little value to me.

Documenting the algebra code of Axiom is a very big project itself. I agree that
the Appendices are not that helpful. 
 
> > Tuple is more like Direct Product since the entries must come
> > from the same domain.
> 
> The domain Tuple and the use of tuple in Axiom seems to be
> a little confused. See page 1100 of Book::
> 
>   tuple
> 
>   an expression of two or more other expressions separated by
>   commas, for example, 4,7,11. Tuples are also used for multiple
>   arguments both for applications (for example, f (x,y)) and in
>   signatures (for example, (Integer, Integer)b > Integer). A
>   tuple is not a data structure, rather a syntax mechanism for
>   grouping expressions.
> 
> This implies that we should not think of a function with
> a signature like '(Integer,Float)->Float' as a mapping
> 'Product(Integer,Float)->Float' and it certainly isn't the
> mapping 'Tuple Any -> Float', but elsewhere in Axiom the
> notion of a function as a mapping is very important.

There is a subtle distinction. Tuples have no bounding parenthesis or brackets
or structures. It is simply a "list" in raw enumerated form. It is convenient
because it is a true list, where as a List object is a single object, not a
"list". This distinction is important in the notion of arity of operators (and
OOP).

> What I want is for Product to be generalized to an n-ary
> [Cartesian Product] and then instead of expressions like:
> \begin{axiom}
> T1:=(1,1.1)
> f:(Integer,Float)->Float
> \end{axiom}
> 
> being interpreted as Tuples, I think such tuples should be
> Products:
> \begin{axiom}
> (1,1.1)$(Product(Integer,Float)
> f:Product(Integer,Float)->Float
> \end{axiom}
> 
I don't agree.  When one wraps up something into a single object, it is
inconvenient to look at the parts without unwrapping. (May be some optical
technology can? :-) Here in f you must take an integer and a float, wrap them up
into a product, and then unwrap it to compute the resulting float. For objects
that are complicated, there is of course a role to wrap up the pieces before
shipping. (Ever think of zipping if you are sending just two small files?)

William

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]