axiom-developer
[Top][All Lists]

## Re: [Axiom-developer] RE: Types as values, and Re: Static versusDynamica

 From: Ralf Hemmecke Subject: Re: [Axiom-developer] RE: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... ) Date: Wed, 28 Sep 2005 12:01:47 +0200 User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

William Sit wrote:
Besides requiring a priori knowledge of S, the above "work around" does not help
with the constructor FRAC when its parameter is a field (not to mention when it
is FRAC S for some S). Ideally, FRAC F when F is a field should simply return F,

In fraction.spac the Fraction code starts with
Fraction(S: IntegralDomain): QuotientFieldCategory S with
if S has IntegerNumberSystem and S has OpenMath then OpenMath
if S has canonical and S has GcdDomain and S has canonicalUnitNormal
then canonical
...

Isn't it allowed to modify this to

== if F has Field
then F
else LocalAlgebra(S, S, S) add ...

but then since F need not be of the form FRAC R for an integral domain R (for
example when F is a finite field), it would be meaningless to export functions
like numerator or denominator. But this necessitates recursive inquiry if R may
itself be a field. To avoid all such problems, Axiom (probably just the
interpreter) forbids FRAC FRAC INT.

It seems that the interpreter knows more about algebra as I would like. If one does not like FRAC FRAC INT then is should clearly be specified somewhere and not hidden in the interpreter. IMHO, the interpreter should interpret, but not add "implicit knowledge" that is not in the SPAD code itself.

> If it is possible to inquire about the
parameters or even the constructor of F (by this I mean, is F has the form  FRAC
S, or FF(p, n), etc without having the user to specify any S, p, or n), and to
return info on the parameters, then types and domains can be truly analogous to
normal data objects: we are able to look into the entries of a matrix, or the
terms and coefficients of a polynomial

Yes, we are able to look inside a matrix and even to modify entries destructively, but this only works because the designer of the Matrix has given enough exports to do so. Otherwise Matrix would just be a black box which might have properties like, for example, Algebra(R). Good enough for some algorithms, but probably not what an ordinary person thinks about matrices.

That is why I think that an explicit export of a function that returns the parameter domain would be the better way to go. If Q = FRAC R and one wants to get out R from Q, it is basically the same as asking to get
1 out of x (where x was previously obtained by x := inc(1). Or was it
x:=lenght("a") and one wants to get "a"?

Ralf