This routine checks that the interval is small enough. We check interval that bounds the root that we are looking for. Now, let me consider interval whose lower and upper bounds are equal. In such case we find our root exactly. There is no way to make it more precise. and, actually let a=b=x, lim_{x->0} ((x-x)/min(|x|,|x|)) = lim_{x->0} (0/min(|x|,|x|)) = lim_{x->0} (0) = 0 Steven Watanabe wrote:

What exactly do you mean by "the relative length of the interval tends to zero?"

lim_{(a,b)->(0,0)} |a-b| / min(|a|, |b|)

doesn't exist.

In Christ, Steven Watanabe

Viatcheslav.Sysoltsev@h-d-gmbh.de wrote:

On Sun, 09 Oct 2011 19:04:39 +0200, Matwey V. Kornilov wrote:

...

and, actually let a=b=x,

lim_{x->0} ((x-x)/min(|x|,|x|)) = lim_{x->0} (0/min(|x|,|x|)) = lim_{x->0} (0) = 0

I'am not active mathematician, but I believe lim {x->0} (0/x) is 0/0 and thus considered undefined, not 0.

lim 0/x is 0, but the original expression (with a and b) has no limit when a, b -> 0. If we let a = 2x, b = x, for example, we get lim(x->0) x/|x| which is either +1 or -1.

I haven't been following this thread closely, but I know enough math to say that lim_{x->0} (0/x) is 0. When evaluating a limit, one does not simply substitute the limiting value into the expression. The limit is the value of the expression as the variable gets arbitrarily close but not equal to the limiting value. As x gets arbitrarily close to 0, 0/x remains exactly 0. I have no clue, how this impacts the original issue. Cheers. Curtis Gehman Burlingame, CA On Oct 10, 2011, at 3:17 AM, Michael Powell wrote:

On Mon, Oct 10, 2011 at 3:01 AM, wrote: On Sun, 09 Oct 2011 19:04:39 +0200, Matwey V. Kornilov wrote:

and, actually let a=b=x,

lim_{x->0} ((x-x)/min(|x|,|x|)) = lim_{x->0} (0/min(|x|,|x|)) = lim_{x->0} (0) = 0

I'am not active mathematician, but I believe lim {x->0} (0/x) is 0/0 and thus considered undefined, not 0.

I haven't run the numbers either, but 0/0 is indeed undefined or Single.NaN if you prefer.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

writes:

I haven't been following this thread closely, but I know enough math to say that lim_{x->0} (0/x) is 0. When evaluating a limit, one does not simply substitute the limiting value into the expression.  The limit is the value of the expression as the variable gets arbitrarily close but not equal to the limiting value.  As x gets arbitrarily close to 0, 0/x remains exactly 0.  I have no clue, how this impacts the original issue.

Cheers.

Curtis Gehman Burlingame, CA

Another way of looking at it is to use L'Hopital's rule: lim_{x->0} ((x-x)/min(|x|,|x|)) => lim_{x->0} ((x-x)/x) => d/dx(x-x) / d/dx(x) => (1-1) / 1 => 0 Like Curtis says, no idea exactly what that means for the original question. Jerry

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jonathan Franklin Sent: Monday, October 10, 2011 11:37 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] math tools roots

On Mon, Oct 10, 2011 at 2:51 PM, Jerry wrote:

...

Another way of looking at it is to use L'Hopital's rule:

0/x is not an indeterminate form, so you can't apply l'Hopital's rule. If fact, there is no need since 0/x = 0 for all x != 0.

Whoa - I fear you mathematicians are getting over-excited! This is C++ and floating-point and NaN (with arbitrary definitions of behaviour). Entirely different rules apply! A more interesting question might be how to avoid going round the loop too many times when a and b are getting so near to zero that they are becoming ill-defined in the floating-point type in use. But let's not go there now ;-) Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

ok, I will do that little bit later. John Maddock wrote:

Will fix: can you please file a bug report at svn.boost.org so I don't forget?

Thanks, John.