John Cremona on Sat, 27 Sep 2014 16:37:45 +0200

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

Re: [PATCH] enable basic arithmetic with infinity

It's fun to see how function names propagate, and in particular how
many functions called lemma6 and lemma7 there are now (based on,
the names come from one of the original papers by Birch and

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

but I don't think this is ever used for real.


On 27 September 2014 14:44, Karim Belabas
<> 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
> F-33405 Talence (France)  [PARI/GP]
> `