[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Axiom-developer] [#187 trouble with tuples] [#187 trouble with tuples],
William Sit <=