[om] more comments on CDs
Arjeh Cohen
amc at win.tue.nl
Thu Oct 24 20:36:36 CEST 2002
Comments on CDs produced so far
by
Arjeh M. Cohen
mainly for James Davenport, the CD editor
Eindhoven, October 2002
IN GENERAL: The content of the "CDUses" tag lists the short name of a
CD. How do you connect this to the URL that fully determines the CD?
Example: <CDUses> <CDName>logic1</CDName> <CDName>plangeo1</CDName>
<CDName>plangeo2</CDName> </CDUses>
IN GENERAL: David Carlisle's stylesheet does not detect spurious
<OMBVAR>s.
IN GENERAL:
When a symbol is defined as a constructor, we should be clear about
the conditions on the arguments when it is used as a head in an
apply. For instance: is rational(4,6) allowed? If we require a
normal form for 2/3, the answer is no. If we do not care, the answer
is yes. But then, what does it mean to take "denominator" (not yet
defined...): 2 or 4?
To prevent such ambiguities I propose:
a) we are very precise about the requirements on the arguments;
b) we make clear whether we are dealing with a normalform for the
object under construction or not. In our example, we may want to
add "rational_NF" which requires that there are two arguments, each
of them integers, and furthermore that the second argument be stricly
positive and 1 if the first is zero, and that the gcd of the first
and second argument is 1 if the first argument is nonzero.
etc..
IN GENERAL: Wouldn't it be useful for a symbol that is used as a
constructor to have default deconstructors---that is, to be able to
grab the i-th argument? It is not needed for codec's, where such
operations are standard (getleaf, etc.), but it is useful for
formulating FMP's. Sometimes, but not always, such arguments can be
retrieved by symbols defined elsewhere in a CD. A realization of
this idea could take place in a CD defining a symbol "arg" having
two arguments, the first is an OM object whose root is an OMA, the
second is an integer. Eg, if f is a symbol then arg(f(a,b,c,d),3) =
c. The symbol "arg" would not make sense when applied top a function
symbol instead of a constructor symbol. To prevent such
difficulties arising when using "arg", one might take an alternative
approach by staying away from the "meta symbol" arg and requiring
that each argument of a constructor symbol A is accessible via a
name/symbol defined in the same CD where A is defined. This would
then come close to Michael Kohlhase's suggestion of introducing structs.
IN FNS1: the introduction to the symbol "range" says that the range
contains the image, but the commented mathematical property (better
to capitalize property I would think) states the converse...
IN FNS1: in the introduction to "range" the word "whose" is misspelled
(to "whos").
IN FNS2: apply_to_list Description mentions "repeated application" but
does not define it. Vague. Later, in the example apply_to_list (set,
make_list ( 1 , 10 , lambda [ x ] . (power ( x, 2 ) ) ) ) the set
construct is n-ary and here n is supposed to be 10 (?!) So, an
interpretation for n-ary functions F of apply_to_list (F, somelist )
might be F(the sequence of elements in somelist). If this is the
intention, it should perhaps be explicitly mentioned. (BTW, I have
been using it as such)
IN LIST: Re: <OMSTR>This symbol represents a mapping function which
may be used to construct lists, it takes as arguments a function
from X to Y and a list over X in that order. The
value that is returned is a list of values in Y. The argument list may be a set or
an integer_interval.</OMSTR>
My question: may the argument list also be a multiset??
IN LIST1: Can we see list("james", "should", "be", "knighted") as a header of an <OMA>,
with argument a number in {1..4}, so that
(list("james", "should", "be", "knighted"))(3) evaluates to "be"?
RE POLYD: Groebner et al should be moved to a separate CD. The reason
is that the functionality of these symbols can be used for other
types of polynomials than those introduced here. For instance, for
polynomial expression in elementary arithmetic (and Mathematica does
not output any other kiind of polynomial anyway).
Re GROUP1: Group(a1,...,an) should become Group(operation,a1,...,an)
because without specification of the operation, there is ambiguity
(eg left_compose, *, or right_compose for permutations).
Re POLYD: John Abbott and I would like to be able to use apply_to_list
to save a lot of writing when dealing with a long polynomial all
of whose coefficients are integers mod 5. If the coefficients
were separated from the monomials (so that we get yet another
representation of a polynomial as a pair of lists of equal length,
one of which contains all coefficients, the other of which
contains all monomials), we could just write
[apply_to_list(lambda x. x mod 5 , *coeffs*), *monomials*]
which would save space, and also allow smooth transitions from integers
to integers mod 5.
Best regards, Arjeh M. Cohen
--
om at openmath.org - general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems
More information about the Om
mailing list