(1) -> F := MachineFloat

(1)

a: F := -0.12345

(2)

b: F := -1234567890.0

(3)

c: F := 1234567890.12345

(4)

(a+b)+c

(5)

a+(b+c)

(6)

F has Field

(7)

MachineFloat? clearly doesn't form a (mathematical) field as the above code demonstrates (and we all know).

)cl all

   All user variables and function definitions have been cleared.
F := Float

(8)

digits()

(9)

a: F := -0.12345

(10)

b: F := -1234567890.0

(11)

c: F := 1234567890.12345

(12)

(a+b)+c

(13)

a+(b+c)

(14)

F has Field

(15)

Unfortunately, Axiom is not very strict with these things, although it should be, I believe. Some examples:

• in Axiom, every field has the attribute canonicalUnitNormal.

In ATTREG.SPAD, we find:

  canonicalUnitNormal
    ++ \spad{canonicalUnitNormal} is true if we can choose a canonical
    ++ representative for each class of associate elements, that is
    ++ \spad{associates?(a,b)} returns true if and only if 
    ++ \spad{unitCanonical(a) = unitCanonical(b)}.

However, I suspect, this cannot be done in every field.

• the domain EXPR is a field, although it is (I think) meant to allow arbitrary functions to be expressed, for example , which does not have an inverse, I'd say.

In the documentation of MuPAD?, they say that (their) expression domain is a field for "convenience". Maybe this is related to the above.

In any case, we certainly cannot decide whether an element is zero or not.

Martin

Category: Axiom Mathematics => Axiom Library