MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: NSolve vs. N[Solve ]

  • To: mathgroup at smc.vnet.net
  • Subject: [mg103444] Re: [mg103423] NSolve vs. N[Solve ]
  • From: "David Park" <djmpark at comcast.net>
  • Date: Mon, 21 Sep 2009 19:27:49 -0400 (EDT)
  • References: <30802611.1253528119105.JavaMail.root@n11>

This N business seems to be a never ending source of confusion. I'm not
certain I have it all correct.

The basic use of N is to convert EXACT numbers to APPROXIMATE numbers with a
specified precision. It only incidentally has anything to do with the number
of digits displayed.

N[\[Pi], 3]
% // FullForm
3.14
3.1415926535897932385`3.

N assured that the result had 3 places of precision (it actually has more in
this case) and put 3 after the number mark. You might think that N was
responsible for the 3 place display. Not so. It was the number mark `3 that
was responsible for that. Check this without N:

1.1111111111`3
% // FullForm
1.11
1.1111111111`3.

N does nothing when working on an approximate number.

N[2.302585092994046`, 3]
% // FullForm
2.30259
2.302585092994046`

So, it looks like one method to control the display is to use SetPrecision.

SetPrecision[NSolve[E^x == 10, x, 3], 3]
{{x -> 2.30}}

However, I don't think that would at all be the recommended method as it is
distorting information about the underlying number.

The proper method to control the display of a number is to use NumberForm.

NumberForm[NSolve[E^x == 10, x, 3], {3, 2}]
{{x->2.30}}

Again, the third argument of NSolve has nothing directly to do with the
display. It appears to be a kind of precision goal for the calculation and
it appears to only have an effect if it is set to more than machine
precision. (But I'm not totally certain of that.) So:

NSolve[E^x == 10, x, 30]
{{x->2.30258509299404568401799145468}}

NumberForm[NSolve[E^x == 10, x, 3], {30, 29}]
{{x->2.30258509299404600000000000000}}

If we Solve exactly and then use N we see that it behaves as expected
because N is working on an exact number.

Solve[E^x == 10, x]
N[%, 3]
{{x -> Log[10]}}
{{x -> 2.30}}

In summary:
1) N to convert exact numbers to approximate numbers.
2) NumberForm to control display of numbers.
3) Arguments or more often options (PrecisionGoal) to control precision of
internal calculation.


David Park
djmpark at comcast.net
http://home.comcast.net/~djmpark/  



From: Helen Read [mailto:hpr at together.net] 


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




  • Prev by Date: Re: NSolve vs. N[Solve ]
  • Next by Date: Re: NSolve vs. N[Solve ]
  • Previous by thread: Re: Re: NSolve vs. N[Solve ]
  • Next by thread: Re: Generating best-fit line formula