Aurel Page on Sun, 30 Oct 2022 13:45:55 +0100

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: arithmetic operations with t_INFINITY

On 29/10/2022 23:09, Karim Belabas wrote:
* Max Alekseyev [2022-10-29 22:38]:
For this purpose, the function isinfinite(v) (or alike) would be more
suitable, or checking the equality type(v) == "t_INFINITY".
Testing "v == oo" is not mathematically rigorous [...]
If is rigorous, because we *define* valuation(0, p) := +oo or
poldegree(0) := -oo, i.e. those two sentinel objects +oo and -oo are
returned by specific functions to indicate well-specified conditions.
(As explained before, those are not "arithmetic objects" that could for
instance be returned or incorporated into a floating point computation
as we could expect from a standard such as IEEE 754.)



P.S. oo can also be used as loop or integral endpoint as in
   intnum(x = 1, oo, 1/x^2)
   for (k = 1, oo, ...)

I would add that since oo was introduced to encode the output of valuations, what is important is that it belongs to the *ordered set* Z union {oo}. So having a well-defined comparison is actually the most important thing about it.

On the other hand, I would like to be the devil's advocate and note that in standard definitions of valuations, what is important is that the codomain is a totally ordered *abelian group* augmented by oo in which the addition law is extended by a+oo = oo for all a. For that point of view, it would be natural to define addition a + (+oo) = +oo for all a in Z union {+oo}. (I don't think we have non-integer valued valuations, do we?)
and maybe
a + (-oo) = -oo for all a in Z union {-oo}, since poldegree is treated as minus a valuation,
but not +oo + -oo or multiplications.
This way, the defining property of valuations: v(xy) = v(x)+v(y) could actually be checked.
That said, I would not push strongly to include those operations.