Re: Re: NSolve vs. N[Solve ]
- To: mathgroup at smc.vnet.net
- Subject: [mg103454] Re: [mg103448] Re: [mg103423] NSolve vs. N[Solve ]
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Tue, 22 Sep 2009 07:09:31 -0400 (EDT)
- References: <200909210951.FAA04712@smc.vnet.net> <9517EE55-C474-402B-9E68-DF992895972F@mimuw.edu.pl> <200909212328.TAA01761@smc.vnet.net>
As Daniel Lichtblau pointed out to me off list I was wrong in believing that NSolve[eqn==0,x,p] and NSolve[eqn==0,x,WorkingPrecision- >p] did different things (for an algebraic equation eqn): the first exists only for reasons of compatibility with early versions of Mathematica and merely converts the input into the second form. The line in the documentation concerning the third argument in NSolve [eqn==0,x,p] is wrong and ought to be removed (in fact it was never correct). What exactly happens for transcendental equations is not quite clear but, as I wrote in my first post in this thread, it has nothing at all to do with NSolve which does not attempt to solve transcendental equations. Andrzej Kozlowski On 22 Sep 2009, at 08:28, Andrzej Kozlowski wrote: >> I believe that in the first of the above inputs NSolve actually >> seeks an answer with precision 3, while in the second case it uses >> WorkingPrecision 3, so the final answer may well have a lower >> precision. > > I meant by this that the answer returned by NSolve[eqn==0,x,p] (wehre > eqn is an algebraic equation) will always have precision p, while > NSolve[eqn==0,x,WorkingPrecision->p] may sometimes return answers with > precision less than p. In the particular example I gave below both > kinds of input return answers with the same precision, but, I think, > in general they need not do so. > > Andrzej Kozlowski > > > On 21 Sep 2009, at 21:54, Andrzej Kozlowski wrote: > >> This is not quite right. NSolve is primarily meant for polynomial >> and algebraic equations and when you give it an algebraic equation >> it will behave as advertised: >> >> x /. NSolve[x^3 - 3 x^2 - 2 x - 11 == 0, x, 3] // Precision >> >> 3. >> >> >> x /. NSolve[x^3 - 3 x^2 - 2 x - 11 == 0, x, >> WorkingPrecision -> 3] // Precision >> >> 3. >> >> I believe that in the first of the above inputs NSolve actually >> seeks an answer with precision 3, while in the second case it uses >> WorkingPrecision 3, so the final answer may well have a lower >> precision. (At least this is how I imagine this ought to work, I >> can't remember anymore if this is indeed so and I do not have the >> time to experiment). >> >> Now, in your case you have a transcendental equation >> >> Exp[x]==10 >> >> I think that in this sort of situation NSolve does not have any >> methods of its own that it can use. I believe that it simply asks >> Solve for the answer (which is Log[10], with a warning about inverse >> functions being used) and then it just applies N to the answer it >> gets from Solve. In doing so it simply ignores the precision you >> asked for. This is probably an oversight rather than a bug. Of >> course the best thing to do in such cases is to use N[Solve[Exp[x] >> == 10, x], 3], since really there is absolutely no benefit at all of >> using NSolve unless you are trying to solve an equation on which >> special methods that NSolve is able to use can be used. In other >> cases NSolve will just turn to Solve for the answer so you might as >> well tell your students to do that directly. >> (I assume they can tell a polynomial equation from a transcendental >> one. If not, its something worth explaining.) >> >> Andrzej Kozlowski >> >> >> >> On 21 Sep 2009, at 18:51, Helen Read wrote: >> >>> A while back (I forget what version), N was modified so that it will >>> give output to any number of significant digits that you desire. >>> Previously, N[x,k] would output 6 significant digits if k was >>> anything >>> less than machine precision. Asking for N[x,3] or N[x,15] or >>> whatever >>> would give output to 6 significant digits, while N[x,k] for k>=16 >>> would >>> give x to k significant digits. >>> >>> Lately my students have been using NSolve with a third argument >>> (for the >>> precision) -- which I hadn't told them about -- to solve a problem >>> that >>> I was actually expecting them to do a different way. What they did >>> was a >>> reasonable solution, but unfortunately they didn't notice that their >>> results from NSolve were not coming out to the number of significant >>> digits that they asked for. Evidently NSolve behaves like the old >>> N, and >>> differs from N[Solve ] >>> >>> For example, compare these: >>> >>> NSolve[E^x==10,x,3] (* result given to 6 significant digits, >>> despite >>> asking for only 3 *) >>> >>> N[Solve[E^x==10,x],3] (* result given to the desired precision *) >>> >>> NSolve[E^x == 10, x, 12] (* result given to only 6 significant >>> digits, >>> despite asking for 12 *) >>> >>> N[Solve[E^x==10,x],12] (* result given to the desired precision *) >>> >>> I hadn't noticed this unfortunate behavior until I started seeing >>> it in >>> my students' work. >>> >>> -- >>> Helen Read >>> University of Vermont >>> >> > >
- References:
- NSolve vs. N[Solve ]
- From: Helen Read <hpr@together.net>
- Re: NSolve vs. N[Solve ]
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- NSolve vs. N[Solve ]