Re: Re: Re: FindRoot cannot find obvious solution
Since my other posting somehow did not make it or at least I have not
seen it I thought I should clarify just this one point, though I
consider all this exchange totally without any practical significance.
>> But that was exactly what I did in the examples with
>> How does your explanation clarify this inconsistency?
Firstly, as I wrote , this has nothing to do with interval arithmetic
an even nothing to do with Interval.
It is simply this:
Why is that? Well, the answer is here:
Sin increases Precision and 2 digits of precision seem to be the
borderline for this problem. I can't tell with complete confidence
exactly what the "identifying" rule is, but I do not need to know nor
particularly want to know.
On 15 May 2004, at 09:58, Andrzej Kozlowski wrote:
> On 14 May 2004, at 13:12, Maxim wrote:
>> Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote in message
>> news:<c7uspa$q7s$1 at smc.vnet.net>...
>>> On 11 May 2004, at 18:20, Maxim wrote:
>>>> Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote in message
>>>> news:<c7klcs$2kn$1 at smc.vnet.net>...
>>>>> makes everything work perfectly. This seems to be the case with
>>>>> every "problem" you have reported for as long as I can remember.
>>>>> deal with the remaining ones, like why 1`2 == 2 gives True, etc,
>>>>> requires only careful reading of the documentation).
>>>> Actually this was discussed in a different thread (
>>>> so I'll paste your answer from there:
>>>> Andrzej Kozlowski wrote:
>>>> Besides it is well known that Mathematica's high precision
>>>> model, based on approximate interval arithmetic, works well only
>>>> numbers whose uncertainty is much smaller than the number itself.
>>>> is the case in all applications I have ever heard of. For very low
>>>> precision numbers like your examples, it is known to give
>>>> pessimistic or wrong answers, but so what?
>>>> The statement that arbitrary-precision arithmetics in Mathematica is
>>>> based on interval arithmetics is inaccurate; perhaps we might say
>>>> since we have an estimate for the error, then we also implicitly
>>>> an interval, but this just leads to confusion with true interval
>>>> arithmetics which is implemented for Interval objects.
>>>> Instead, arbitrary-precision computations in Mathematica use
>>>> significance arithmetics and the notion of condition number to keep
>>>> track of precision. For example, squaring a number can lose one
>>>> digit, so after calculating the square Mathematica subtracts
>>>> from the precision of the input -- it doesn't use Interval to
>>>> represent bignums and this squaring isn't performed on any
>>>> Next, the suggestion that the uncertainty should be much smaller
>>>> (exactly how much that would be?) than the number itself seems to be
>>>> rather vacuous -- if the uncertainty and the number are of the same
>>>> order, that would mean that no digits are known for certain, that
>>>> the precision is zero.
>>>> I wouldn't say that true interval arithmetics is 'known' to give
>>>> answers -- that would totally defy the purpose of intervals; the
>>>> point of using them for approximate calculations is to obtain bounds
>>>> which are certain to encapsulate the possible error (so
>>>> and 'wrong' are more like antinomes -- pessimistic means that those
>>>> bounds might be too wide).
>>>> But now, as far as I understand from your last post, you changed
>>>> mind and instead of saying that those examples just gave meaningless
>>>> output due to low precision (which doesn't seem like a wise thing
>>>> Interval to do anyway), you claim that, after reading documentation,
>>>> you can offer some explanation other than "so what?". Then please
>>>> elaborate on why 1`2==2.2, 1`2==2.3 and
>>>> IntervalMemberQ[Sin[Interval[1`2]],0] work the way they do. I'd like
>>>> to hear the explanation, that's why I was asking the question in the
>>>> first place.
>>>> Maxim Rytin
>>>> m.r at prontomail.com
>>> I wrote "approximate" interval arithemtic. Mathematica's model of
>>> significnace arithemtic is an approximation to interval aithmetic.
>>> Mathemaitca uses an approximate model because real interval
>>> implemented via Interval is far too slow for everyday use. An
>>> approximate model rather naturally suffers form weaknesses: in
>>> Mathematica's case one of them is dealing with low precision numbers.
>>> However, if you ned to do that you can always use true interval
>>> arithemtic. As for your other question I will just cite from the
>>> documentation for Equal:
>>> Approximate numbers are considered equal if they differ in at most
>>> their last eight binary digits (roughly their last two decimal
>> In other words, using true interval arithmetic with low precision
>> numbers is safe? But that was exactly what I did in the examples with
>> 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.
> 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.
>> As to Equal,
>> let's count digits:
>> RealDigits[1`2, 2, 8, 1]
>> RealDigits[1`2, 2, 9, 1]
>> 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
>> 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
>> 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.
> Andrzej Kozlowski
> Chiba, Japan
Prev by Date:
Next by Date:
A question about sort
Previous by thread:
Re: Re: FindRoot cannot find obvious solution
Next by thread:
Re: FindRoot cannot find obvious solution