On Mon, 19 Nov 2018, Torbjörn Granlund wrote: > Richard Biener <rguent...@suse.de> writes: > > :/ But then with GCC we want deterministic behavior -- ISL > added some "computation budget" and error reporting if that was > taken up. Maybe gmp/mpfr/mpc could consider adding such a thing > (reporting budget overruns via a signal could be acceptable if > the API churn would be too bad for another way). > > I'll leave this up to the mpc maintainers. > > > I simplified your test case using 1 as the real part and an integer for > > the imaginary part. With the real part set to 10000, the computation > > finishes in about 10 seconds, with every doubling of it the runtime > > almost triples. (If my observation generalises to an extended real part > > range, the compilation for your test case should terminate in about > > 10*3^log2(4.045689747817175388336181640625e+8/10000)/3600/24/365 years.) > > Ick. I wonder if the actual ctan result is infinite or we just > fail to compute it in an efficient manner... > > The result should be extremely small, so returning Inf would be > quite inaccurate. :-)
I see. So I guess one issue might be that mpfr numbers have a precision (mantissa bits?) but no restriction on the exponent? That is, for ctan eventually zero _is_ a validly rounded result and the computation should simply terminate... Richard. -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs