ApCoCoALib:RingDouble
User documentation for files RingDouble.C and RingDouble.H
These files contain an interface to a class derived from CoCoA::ring, using a truncated floating point arithmetic.
The interface works as follows:
NewRingDouble(Precision)
Creates a new instance of a RingDouble with precision Precision. The returned ring can than be used as any other ring. This means if the absolute value of the difference of two elements is smaller than the precision, they are treated as equal. This leads to some problems, or behavior which is not standard. For example we have zero-divisors in RingDouble. Having e.g. a precision of 0.01, then 0.02 * 0.03 = 0.006 which is treated as 0, because |0.006| < 0.01. So although this rings models a field, it is NOT a integral domain! Also other field/ring axioms do not hold, due to numerical effects (e.g. the distributive laws may generate problems). Due to this is also problematic to generate ring homomorphism into this ring and from there to somewhere else.
These techniques may lead to strange behavior, so please be careful when using them.
For example there are examples, where something which is zero times something
which is not is unequal zero (e.g. 0.009 * 2 with a precision of 0.1 ). All
this may be tricky.
Also the precision is NOT used for internal rounding! The ring always computes with the precision of the hardware's double implementation. It is only considered for checks if two values are equal ( or zero or one).
There is also another floating point ring, contained in the CoCoA library. Its concept
is much more advanced and is able to handle much higher precisions than this ring (which
internally works on doubles). The CoCoALib's floating point arithmetic is called
TwinFloats and respectively RingTwinFloats. Please consider CoCoALib's documentation for
more information regaring twin floats.
Maintainer documentation for files RingDouble.C and RingDouble.H
Bugs, Shortcomings and other ideas
A problem, which is yet unsolved is the handling of "inf", "-inf" and "nan". These 'values' are integrated in the hardware's double-implementation and are therefore also elements of RingDouble. Eventually there should be checking to disallow doing computations with them, but I am not sure. Sometimes it may be handy to divide by zero, multiply with infinity or divide by it. Also RingDouble currently claims to be a field while it admits to be not a integral domain, which contradicts itself. It should -in my eyes- claim to be a field, to be easily able to use it as coefficient 'field' for polynomial rings and in Groebner basis computations, on the other hand, it is in the strict algebraic eyes not a field.
Also the OpenMath output routines are not implemented. They throw an corresponding CoCoA exception.