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 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] > ` >