Re: [PATCH] enable basic arithmetic with infinity

[John Cremona <john.cremona@gmail.com>]

It's fun to see how function names propagate, and in particular how
many functions called lemma6 and lemma7 there are now (based on
https://github.com/JohnCremona/eclib/blob/master/libsrc/mlocsol.cc,
the names come from one of the original papers by Birch and
Swinnerton-Dyer).

I checked my own code (from which these pari function have evolved via
Denis's gp script) and as you can see from that C++ file, I do test
for 0.  I think I made that change when I started to distribute source
code and became embarrassed at simply defining the valuation of 0 to
be 999999 (though my source code does contain the line

#define VALUATION_OF_ZERO 99999

(in https://github.com/JohnCremona/eclib/blob/master/libsrc/marith.cc)
but I don't think this is ever used for real.

John

On 27 September 2014 14:44, Karim Belabas
<Karim.Belabas@math.u-bordeaux.fr> wrote:
> Hi Jeroen,
>
> * Jeroen Demeyer [2014-09-23 17:03]:
>> On 2014-09-23 16:03, Bill Allombert wrote:
>> >Purposefully, we restricted the semantic attached to oo.
>> >Most of the time such operations are the symptom of a bug.
>> The usage quoted before [if (lambda > 2*valuation(x,p),...)] is not a bug,
>> in fact it expresses something very natural and it would be a pity to force
>> people to write
>>
>> if (x!=0 && lambda > 2*valuation(x,p),...)
>>
>> Why would you introduce t_INFINITY in the first place if you don't allow
>> this? Surely, the philosophy of introducing t_INFINITY was to make code
>> easier and less prone to errors.
>
> It was originally meant as a special marker to use +/- oo as interval
> bounds, for polsturm or numeric integration.
>
> Then, after some hesitations, extended for degree and valuation, but
> again meant as a special marker. I never wanted to go into a partial
> implementation of \bar{R}-arithmetic. E.g. why allow 2 + oo but not
> 2^-oo ? 2^poldegree(T) is a sensible construction.
>
> Lots of function to inspect and instrument, possibly elegant, but for
> limited actual use-case...
>
>> Now, on the contrary, you're making code more difficult.
>>
>> If you really think that people should write
>>
>> if (x!=0 && lambda > 2*valuation(x,p),...)
>
> <aside>
>
> In that particular case, x == 0 should be catered for earlier
> (as it is in the C version, hidden in buch4.c and currently not
> exported, unfortunately). The original code (lemma[67]{nf} in buch4.c)
> is full of clever hacks allowing to use regular constructions
> independent of special cases. But treating them specially actually
> simplifies the code by making it clearer, if (arguably) less elegant.
>
> N.B. The following works
>   if (lambda/2 > valuation(x,p),...)
>
> </aside>
>
>> then why not raise an error for valuation(0,p)?
>
> I agree.
>
> Unfortunately, I made the mistake of allowing valuation(0) a long time
> ago (circa 1995). And poldegree(0) has been allowed since the dawn of
> time (circa 1985). Thus lots of scripts depend on this behaviour.
>
>> I think that's better than returning a useless t_INFINITY.
>
> The new behaviour is IMHO saner than the old one (return a big integer,
> either 2^63-1 or 2^32-1 depending on the architecture). And it avoids
> breaking simple scripts. (It does break hackish code, granted.)
>
> I introduced a new type t_INFINITY instead of (ab)using a t_REAL, say,
> so that, by default, functions would do the right thing: raise a type error.
>
> I really don't want to instrument essentially all numerical functions to
> make sense of infinities-as-actual-numbers, including beasts such as
> a+I*oo which make perfect sense for complex integrals. A related
> former TODO item was to introduce IEEE754 special values as t_REALs
> (infinities, signed 0s, NaN, etc.): I decided against it a long time ago.
>
> I can revert the change letting poldegree() and valuation() return
> t_INFINITYs. But, given the above, I don't see how to reach a situation
> that would both be saner than the current one, and avoid breaking too
> many scripts.
>
> Denis's script is the only one I'm aware of that was broken by the change,
> and there are various simple ways to fix it [ the easiest would be for
> us to export the C function and replace the function call: been in the
> TODO list for some time ].
>
> I understand your point that a minor extension (= allow simple kinds of
> add/sub/mul) is easy, unlikely to do any harm and possibly "useful", but
> I prefer sticking to a clear infinity-is-not-a-number rule.
>
> Cheers,
>
>     K.B.
> --
> Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
> Universite de Bordeaux         Fax: (+33) (0)5 40 00 69 50
> 351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~kbelabas/
> F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
> `
>