Re: Bad Precision output for SphericaBesselY and BesselY

*To*: mathgroup at smc.vnet.net*Subject*: [mg123178] Re: Bad Precision output for SphericaBesselY and BesselY*From*: Peter Falloon <pfalloon at gmail.com>*Date*: Fri, 25 Nov 2011 04:57:24 -0500 (EST)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*References*: <jafud8$rrr$1@smc.vnet.net> <jalcav$snk$1@smc.vnet.net>

On Nov 24, 11:12 pm, Antonio Alvaro Ranha Neves <ane... at gmail.com> wrote: > Thank you Oleksander, Peter, Oliver, and Richard for the reply. > > @Oleksander > Why is Rationalize[120.3] better than SetPrecision[120.3, Infinity]? > Each command gives me a rational output, > 1203/10 > And > 8465359924572979/70368744177664 > Respectivaly. > I used 120.3 as an example, but my actual number is an irrational number with a high precision (output of a findroot) > > @Peter > I really liked the FindRoot solution to the problem. It inspired me to write, > ListMap=ParallelTable[Replace[p,FindRoot[Precision[BesselY[n+1/2,SetPrecisi on[x,p]]]==90,{p,90},Evaluated->False]],{x,100},{n,100}]; > ListPlot3D[ListMap,Mesh->None,ColorFunction->"SouthwestColors"] > > Maybe this will shed some light on how the precision is affected by BesselY[n+1/2,x] algorithm. As one can see, when x is approximately n the required precision is maximum, and when x>n there are some =93instabilities=9 4. FWIW, I think this loss of precision is an unavoidable feature of these functions -- and not just an artifact of the calculation method. It comes about because the function is a (finite) sum of terms with alternating signs and a large range of magnitudes, such that the final result is much smaller than its largest terms. The following gives a feel for this: Clear[x]; n = 150; besselYTerms[x_] = List @@ Expand @ BesselY[n + 1/2, x] ListPlot[Sign[#]Log[Abs[#]] & /@ besselYTerms[120.3`100]] Cheers, Peter.