Martin Rubey wrote: > > Ralf Hemmecke writes: > > William Sit wrote: > > > > > For example, if I have a constructor that requires an integral domain R > as > > > a parameter, and I constructed in the package the quotient field of R, as > > > you may suggest as an explicit way to achieve efficiency, then the > package > > > will FAIL if R is actually a field (you can consider this as a bug if you > > > like), even though a field IS an integral domain, mathematically. > > Why would it fail? I don't think it does, in fact. However, if you are going > to > apply FRAC you can simply ask whether the domain is a Field.
Mathematically speaking, it should not, but one is still creating only an isomorphic copy (presumably with a less efficient data structure) since the total quotient ring of a field is isomorphic to the field itself. However, while FRAC FRAC INT in the interpreter seems to return a valid domain, a: FRAC FRAC INT would return an error that the type is invalid. The problem is the current algebra code for FRAC does not anticipate a field as its argument because it was implemented as the localization of the ring with respect to a multipicatively closed set. > On the other hand, given a Field to ask whether it is a QuotientField is a > question that I consider quite important. > > However, the desirable query > > if R has QuotientField S > > thus defining S is, I think, quite difficult to implement sensibly. Not only that, such a use is limited because it requires the user to supply S already. > Throughout > Axiom, this effect is obtained by adding another parameter to the > Package/Domain signature like: > > MyPackage(F: Field, S: IntegralDomain): ... > > if F is Fraction S then > > Martin This construction certainly is because Axiom does not support querying the parameters of a constructor from a domain resulting from that constructor. So if some function returns a domain (constructors are such functions), the domain already hides its parameters unless the author deliberately provides functions to return such information (as suggested by Ralf). 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, 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. 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: what I called operations ON the objects, not USING the objects. Only by having operations ON the objects can one add operations USING the objects. This feature would facilitate simplification of type construction such as FRAC FRAC INT to just FRAC INT, making them valid as well as efficiently and trivially implementable. William _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
