Re: Re: Re: Re: More /.{I->-1}

• To: mathgroup at smc.vnet.net
• Subject: [mg106950] Re: [mg106925] Re: [mg106656] Re: [mg106882] Re: More /.{I->-1}
• From: DrMajorBob <btreat1 at austin.rr.com>
• Date: Fri, 29 Jan 2010 07:47:02 -0500 (EST)
• References: <hjbvc0\$2tp\$1@smc.vnet.net> <hjeqh1\$g3c\$1@smc.vnet.net>

```OK... heard this before.

Still seems counter-intuitive, but I suppose it's the inevitable result
(at the boundaries) of a useful mechanism.

Bobby

On Thu, 28 Jan 2010 04:01:56 -0600, Andrzej Kozlowski
<akozlowski at gmail.com> wrote:

> The definition of precision in Mathematica is this. Suppose x is a
> number known up to an error of epsilon, that is it can be viewed as
> lying in the interval (x-epsilon/2,x+epsilon/2). Then its precision is
> -Log[10,epsilon/x]. Its accuracy is -Log[10,epsilon]. The two are
> related by the equation:
> Precision[x] - Accuracy[x] == RealExponent[x]
>
> The interpretation in terms of digits is only approximate. Both accuracy
> and precision can be negative - this depends on the scale of the number
> i.e. RealExponent. A number will have negative accuracy if its absolute
> error is large. It is easy to produce such numbers by cancellation
>
> With[{x = N[10^100, 50] - N[10^100, 50]},
>      Accuracy[x]]
>
> -50.301
>
> On the other hand, since
>
> \$MinPrecision
>
> 0
>
> You won't normally in Mathematica see numbers with negative Precision.
> Precision is the main concept, Accuracy is only used because Precision
> is singular at 0 (remember - its relative error).
>
> It's all perfectly documented so this tired scape goat is not available
> this time.
>
> Andrzej Kozlowski
>
>
> On 28 Jan 2010, at 08:45, DrMajorBob wrote:
>
>> OK... so numbers are allowed to have NEGATIVE precision?
>>
>> LESS than zero digits of accuracy? Really?
>>
>> Whatever for?
>>
>> Bobby
>>
>> On Wed, 27 Jan 2010 18:23:32 -0600, Daniel Lichtblau <danl at wolfram.com>
>> wrote:
>>
>>> DrMajorBob wrote:
>>>> 0 and 1 are not "fuzzballs", so what interval could be >= 1 and also
>>>> 0.?
>>>> Bobby
>>>
>>> I had in mind the spoiler answer Richard Fateman provided in his first
>>> post mentioning this particular tangent, err, example.
>>>
>>> http://forums.wolfram.com/mathgroup/archive/2010/Jan/msg00638.html
>>>
>>> At the bottom we find:
>>> ---
>>> I would especially avoid .nb objects, and most especially on topics of
>>> numerical analysis, where the design flaws are, in my opinion, so
>>> fundamental.  Example (mathematica 7.0):
>>> {x >= 1, x > 1, x > 0, x}
>>>     evaluates to
>>> {True, False, False, 0.}
>>>
>>>   can you construct x?
>>>
>>> RJF
>>>
>>>
>>> x=0``-.5
>>> ---
>>>
>>> The point is that with Mathematica's version of significance
>>> arithmetic,
>>> equality, I believe, is effectively treated as having a nontrivial an
>>> intersection (of the implicit intervals defining two numbers). If
>>> neither has any fuzz (i.e. both are exact), then Equal allows for no
>>> fuzz, so this is only a subtlety if at least one of the values is
>>> approximate.
>>>
>>> One implication is that a "zero" of sufficiently low (as in bad)
>>> accuracy can be regarded as 1, or -1, or Pi, if those values happen to
>>> fall within the accuracy (which I refer to as fuzz).
>>>
>>> The other inequalities follow from the preservation of trichotomy. For
>>> explicitly real values we regard that as important. mathematica makes
>>> no
>>> pretense that Equal is transitive and I do not see any way to do that
>>> and also have useful approximate arithmetic.
>>>
>>> There has been some amount of communication off-line on this topic,
>>> which is why some of us (well, me, at least) sometimes forget the
>>> examples are not universally obvious to those who have not memorized
>>> the
>>>
>>> Daniel
>>>
>>>
>>>> On Wed, 27 Jan 2010 00:44:22 -0600, Daniel Lichtblau
>>>> <danl at wolfram.com>
>>>> wrote:
>>>>
>>>>> Richard Fateman wrote:
>>>>>> [...]
>>>>>> If all of Mathematica functionality were available in the free
>>>>>> player
>>>>>> version, WRI would need to drastically change its business model.
>>>>>> And
>>>>>> even it it were free, we still have behavior like this: (..for some
>>>>>> values of zero)
>>>>>>
>>>>>>  {x >== 1, x > 0, x}  evaluates to {True, False, 0.}
>>>>>>
>>>>>> RJF
>>>>>
>>>>> Let's take simple intervals, that is, intervals that are segments.
>>>>> Define less and greater in the obvious ways, that is, one segment
>>>>> lies
>>>>> strictly below the other (right endpoint of lesser is less than left
>>>>> endpoint of larger). Let us further define two intervals to be equal
>>>>> whenever they have nonempty intersection.
>>>>>
>>>>> With these definitions, which I think are sensible, the behavior you
>>>>> describe above is consistent with arithmetic on intervals. As the
>>>>> numbers involved, at least some of them, are fuzzballs, this strikes
>>>>> me
>>>>> as an appropriate behavior.
>>>>>
>>>>> Daniel Lichtblau
>>>>> Wolfram Research
>>>
>>
>>
>> --
>> DrMajorBob at yahoo.com
>>
>

--
DrMajorBob at yahoo.com

```

• Prev by Date: Re: Re: Journals dying?, apparently rather slowly (was ,
• Next by Date: Re: More memory-efficient inner product for large last
• Previous by thread: Re: Numerical Problem
• Next by thread: position of sequence of numbers in list