Re: Re: FindRoot cannot find obvious solution
- To: mathgroup at smc.vnet.net
- Subject: [mg48205] Re: [mg48186] Re: FindRoot cannot find obvious solution
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Tue, 18 May 2004 04:16:07 -0400 (EDT)
- References: <200404270847.EAA18892@smc.vnet.net> <c6o3lc$cd0$1@smc.vnet.net> <c6qags$s56$1@smc.vnet.net> <200405080524.BAA11690@smc.vnet.net> <c7klcs$2kn$1@smc.vnet.net> <200405110920.FAA28320@smc.vnet.net> <c7uspa$q7s$1@smc.vnet.net> <200405140412.AAA04779@smc.vnet.net> <c83qlt$li3$1@smc.vnet.net> <200405170721.DAA29564@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
On 17 May 2004, at 16:21, Maxim wrote:
> Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote in message
> news:<c83qlt$li3$1 at smc.vnet.net>...
>> On 14 May 2004, at 13:12, Maxim wrote:
>>
>>> In other words, using true interval arithmetic with low precision
>>> numbers is safe? But that was exactly what I did in the examples with
>>> Interval:
>>>
>>> IntervalMemberQ[Interval[1`2],0]
>>> IntervalMemberQ[Sin[Interval[1`2]],0]
>>>
>>> How does your explanation clarify this inconsistency?
>>
>>
>> You are not actually using "Interval arithmetic" here. At best,you are
>> using a mixture of Interval arithmetic and significance arithmetic.
>> You
>> can certainly make accurate error estimates using interval arithmetic
>> with exact numbers.
>>
>>
>> IntervalMemberQ[Interval[{1-1/100,1+1/100}],0]
>> False
>> and so on.
>>
>> I have already answered the other question in another posting. This
>> happens because Sin increases Precision (and by the way, it's not yet
>> another "paradox"). No inconsistency.
>>
>
> But nobody says that Interval[Sin[1`2]] and Sin[Interval[1`2]] should
> be identical; it's no surprise that Sin[Interval[{0,Pi}]] is not
> Interval[{Sin[0],Sin[Pi]}].
>
> Here's what the question was about (it seems that I have to start with
> that). We create Interval[1`2]; numbers -0.29 and 2.2 belong to the
> interval, therefore taking Sin of the interval we must obtain an
> interval which includes at least the range from -0.28 to 1.0;
> otherwise it would be like squaring Interval[{0,2}] and still getting
> Interval[{0,2}] as the answer.
>
> Instead, Sin[Interval[1`2]] returns an interval which includes (by
> IntervalMemberQ) only numbers from 0.12 to 1.0.
>
> It's quite plausible that, while the interval bounds are rounded
> outwards as they should be, the increased precision 'eats up' this
> rounding and in the end we get an interval which is narrower than
> necessary. But to say that there is no inconsistency in the strict
> mathematical sense is incorrect.
>
>>> As to Equal,
>>> let's count digits:
>>>
>>> In[1]:=
>>> RealDigits[1`2, 2, 8, 1]
>>> RealDigits[1`2, 2, 9, 1]
>>>
>>> Out[1]=
>>> {{0,1,0,0,0,0,0,0},2}
>>>
>>> Out[2]=
>>> {{0,1,0,0,0,0,0,0,0},2}
>>>
>>> There's some uncertainty as to how many digits to take: by default
>>> RealDigits returns 7 digits, but we can ask it to give us 8 digits;
>>> all the next ones will be Indeterminate. I added leading zero just
>>> for
>>> alignment with RealDigits[2.2,2] and RealDigits[2.3,2], which give
>>>
>>> In[3]:=
>>> RealDigits[2.2,2]
>>> RealDigits[2.3,2]
>>>
>>> Out[3]=
>>> {{1,0,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1
>>> ,0
>>> ,0,1,
>>> 1,0,0,1,1,0,0,1,1,0,0,1,1,0,1,0},2}
>>>
>>> Out[4]=
>>> {{1,0,0,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0
>>> ,1
>>> ,1,0,
>>> 0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0},2}
>>>
>>> If the eight-digits rule applies here, 1`2 is either equal to
>>> anything
>>> (eight digits is all we know) or unequal both to 2.2 and 2.3 by the
>>> leading digit. Perhaps some more 'careful reading of documentation'
>>> is
>>> required?
>>>
>>> Maxim Rytin
>>> m.r at prontomail.com
>>
>>
>> As I wrote in my other posting, the actual rule is probably based on
>> Precision and not exactly the number of digits, which only roughly
>> corresponds to it. The exact rule for identifying "close" approximate
>> numbers is not given because nobody needs it.
>> In any case, as I wrote before, significance arithmetic does not work
>> well with low precision numbers and that is the price one pays for it
>> being manageable fast. If you need error estimates for low precision
>> computations use(exact!) interval arithmetic.
>
> We've been through that before: if equality is determined by the
> precision of the number (that would be explanation #4 or so by now?),
> then only numbers in the range from 1-0.01 to 1+0.01 should be
> considered as equal to 1`2.
>
> Maxim Rytin
> m.r at prontomail.com
>
>
>
This is argument is clearly not getting anywhere, and as it concerns
matters of so little significance that nobody else is likely to pay
attention to it, this is defintely my last response.
I never wrote that if equality is determined by the precision of the
number in the sense of interval arithmetic, because significance
arithemtic only approximates interval arithmetic. And by interval
arithmetic I mean what everybody except you means by interval
arithmetic: exact interval arithemtic. I do not know what the hybrid
one inplemented in Matheamtica is for, it seems ot me just a byproduct
of something.
The actual situation is this:
1. Mathematica has a fully implemented exact interval arithemtic. It is
fully logically self-consistent (barring bugs) and the fact that such
arithmetic must be in certian ways quite unlike ordinary arithmetic .
It is in fact "pessimistic" in the sense I described in another thread
that you started by claiming that a perfectly sensible answer was
wrong. (Since you seem to know very little about these matters I
suggest looking at 97 of "Structure and Interpretation of Computer
Programs" by Abelson and Sussman and solving problem 2.16. I would
certainly be interested in seeing your solution.) In any case, exact
interval arithmetic can be used to give bounds on errors when working
with low precision numbers. Fortunately most normal people do not do
this very often so the slowness is not a terrible problem.
2. Mathematica has also significance arithmetic, which is an
approximation to interval arithmetic. It is fast and works well in the
sort of situations that most people most of the time find themselves
in. It achieves this speed by "bending corners", in such a way that
computations with low precision numbers are generally very unreliable
and can give paradoxical results. In particular it produces the effect
you have re-discovered. (If you bothered to check the archives you
would have discovered that exactly the same discussion, including the
example with 1`2 was held here already a few years ago). I believe
that what i have written roughly corresponds to what actually happens
but in any case it does not matter at all. The reason why it does not
mater is that
1. You have been told that significance arithmetic is unreliable in
such cases
2. As Richard Fateman pointed out the last time this issue was
discussed (at least in my memory) question like:
1`2 == 2
do not make sense and there is never any reason to ask them.
3. If you can devise a system of arithmetic that has the advantages of
significance arithmetic without its defects than I am sure everyone
will be impressed and maybe even Wolfram will want to hire you.
Andrzej Kozlowski
Chiba, Japan
http://www.mimuw.edu.pl/~akoz/
- References:
- Re: FindRoot cannot find obvious solution
- From: ab_def@prontomail.com (Maxim)
- Re: FindRoot cannot find obvious solution
- From: ab_def@prontomail.com (Maxim)
- Re: FindRoot cannot find obvious solution
- From: ab_def@prontomail.com (Maxim)
- Re: FindRoot cannot find obvious solution
- From: ab_def@prontomail.com (Maxim)
- Re: FindRoot cannot find obvious solution