Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.soft-sys.math.mathematica > #3468 > unrolled thread

Numerical accuracy/precision - this is a bug or a feature?

Back to article view | Back to comp.soft-sys.math.mathematica

Contents

  Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-04 10:47 +0000
    Re: Numerical accuracy/precision - this is a bug or a feature? "Kevin J. McCann" <kjm@KevinMcCann.com> - 2011-07-04 11:14 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-05 09:17 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? "Kevin J. McCann" <Kevin.McCann@umbc.edu> - 2011-07-06 09:35 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-07 11:40 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Daniel Lichtblau <danl@wolfram.com> - 2011-07-07 11:34 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com> - 2011-07-06 09:39 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-07 11:33 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-08 08:51 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-12 11:01 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com> - 2011-07-08 09:04 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-09 11:34 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-12 11:02 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com> - 2011-07-09 11:37 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-13 07:11 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-14 09:23 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-15 01:19 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? "W. Craig Carter" <ccarter@mit.edu> - 2011-07-15 01:25 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-15 08:12 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-16 09:45 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-16 09:40 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-13 07:12 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-15 01:23 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-15 08:10 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-16 09:41 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-17 10:02 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-18 10:14 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-18 10:17 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-19 10:55 +0000
    Re: Numerical accuracy/precision - this is a bug or a feature? "Kevin J. McCann" <kjm@KevinMcCann.com> - 2011-07-04 11:18 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-05 09:15 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-06 09:34 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Daniel Lichtblau <danl@wolfram.com> - 2011-07-07 11:35 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-08 08:53 +0000

Page 1 of 2  [1] 2  Next page →

#3468 — Numerical accuracy/precision - this is a bug or a feature?

Let Mathematica (6.x, 7.x) compute quite a simple product

In[1]:= N[N[2.0, 20] * N[Sqrt[2] , 20], 20]

Out[1]= 2.82843

This is a bug.

Why?

Now we analyze it in details:

1. N[2.0,20] should give 2 with accuracy/precision/whatsever about 20 
decimal digits, i.e. 2.00000000000000000000

2. Sqrt[2] should give... Sqrt[2]

3. N[Sqrt[2]] should give 1.4142135623730950488 (this is copy-paste from 
Mathematica output to N[Sqrt[2]] )

4. The product 2.00000000000000000000 * 1.4142135623730950488 is 
2.8284271247461900976 (again copy-paste)

5. BUT THE RESULT OF  N[2.0, 20] * N[Sqrt[2] , 20]  "truncated to 20 digits" 
is Out[1]= 2.82843

Where are missing digits?!

slawek

 

[toc] | [next] | [standalone]

#3480

The answer to this puzzle is that the N[2.0,20] is 2.0, not 
2.00000000... Try N[2,20] and all is well. I think that when you put 2.0 
in you have already limited yourself to machine precision, and N[2.0,20] 
is then just machine accuracy.

Kevin

On 7/4/2011 6:47 AM, slawek wrote:
> Let Mathematica (6.x, 7.x) compute quite a simple product
>
> In[1]:= N[N[2.0, 20] * N[Sqrt[2] , 20], 20]
>
> Out[1]= 2.82843
>
> This is a bug.
>
> Why?
>
> Now we analyze it in details:
>
> 1. N[2.0,20] should give 2 with accuracy/precision/whatsever about 20
> decimal digits, i.e. 2.00000000000000000000
>
> 2. Sqrt[2] should give... Sqrt[2]
>
> 3. N[Sqrt[2]] should give 1.4142135623730950488 (this is copy-paste from
> Mathematica output to N[Sqrt[2]] )
>
> 4. The product 2.00000000000000000000 * 1.4142135623730950488 is
> 2.8284271247461900976 (again copy-paste)
>
> 5. BUT THE RESULT OF  N[2.0, 20] * N[Sqrt[2] , 20]  "truncated to 20 digits"
> is Out[1]= 2.82843
>
> Where are missing digits?!
>
> slawek
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#3487

Użytkownik "Kevin J. McCann" <kjm@KevinMcCann.com> napisał w wiadomości grup 
dyskusyjnych:ius7b6$30t$1@smc.vnet.net...
> The answer to this puzzle is that the N[2.0,20] is 2.0, not
> 2.00000000... Try N[2,20] and all is well. I think that when you put 2.0
> in you have already limited yourself to machine precision, and N[2.0,20]
> is then just machine accuracy.

It is still a-bug-and-a-feature.
And this bug make Mathematica nearly useless in numerical computations. "MS 
Windows Calculator" is much more reliable!


The number of written digits IS NEITHER the precision NOR the accuracy. 
Mathematica treat 2.0 as a 2.0+-0.1, but it is not the proper way to handle 
numbers.

I know, that it is common mistake to treat 2.0 as "not an integer number" 
and/or "exact" number, but 2.0 is an integer number AND also it is a 
rational number AND also a real number AND also a complex number. And 2.0 is 
simply 1+1+ 0/10 . Therefore, as you see, there is no "roudning", "limited 
precision", "error" or "uncertinaity". It is only a matter of a notation of 
decimal fractions. And decimal fractions are exact. Any "tolerance" is not 
indicated in any way by this notation. Thus it is a bug. Nasty, big, fat bug 
in the core of Mathematica.

Even from "CS view" 2.0 is translated to IEEE representation with 56-bits of 
the mantisa. Nobody declare float x = 2.0000000000 to iniject the float 
point two into a code.

slawek
 

[toc] | [prev] | [next] | [standalone]

#3508

Well, I certainly disagree with your assessment. The rules regarding 
exact and machine precision numbers are straightforward and stated in 
the documentation. But if you feel that the MS Windows Calculator is a 
better option, by all means use that. It is free and easy to use.

2.0 is not an integer nor a rational, it is machine precision. On the 
other hand 2 is an integer and exact.

As far as whether or not 2.0 should be considered as 2.0+-0.1 or as 
2.000..., 2.0 is a machine precision number, which means 
2.000000000000000 or as close as you can get in about 16 places. Telling 
Mathematica that you want 20 places is somewhat like asking Mathematica to give more 
accuracy *after* the calculation is finished. At any rate my friend 
David Park reminded me that you can specify your 2.0 to 20 places with 
the following:

2.0`20
Precision[%]

20.

Kevin


On 7/5/2011 5:17 AM, slawek wrote:
> Użytkownik "Kevin J. McCann"<kjm@KevinMcCann.com>  napisał w wiadomości grup
> dyskusyjnych:ius7b6$30t$1@smc.vnet.net...
>> The answer to this puzzle is that the N[2.0,20] is 2.0, not
>> 2.00000000... Try N[2,20] and all is well. I think that when you put 2.0
>> in you have already limited yourself to machine precision, and N[2.0,20]
>> is then just machine accuracy.
>
> It is still a-bug-and-a-feature.
> And this bug make Mathematica nearly useless in numerical computations. "MS
> Windows Calculator" is much more reliable!
>
>
> The number of written digits IS NEITHER the precision NOR the accuracy.
> Mathematica treat 2.0 as a 2.0+-0.1, but it is not the proper way to handle
> numbers.
>
> I know, that it is common mistake to treat 2.0 as "not an integer number"
> and/or "exact" number, but 2.0 is an integer number AND also it is a
> rational number AND also a real number AND also a complex number. And 2.0 is
> simply 1+1+ 0/10 . Therefore, as you see, there is no "roudning", "limited
> precision", "error" or "uncertinaity". It is only a matter of a notation of
> decimal fractions. And decimal fractions are exact. Any "tolerance" is not
> indicated in any way by this notation. Thus it is a bug. Nasty, big, fat bug
> in the core of Mathematica.
>
> Even from "CS view" 2.0 is translated to IEEE representation with 56-bits of
> the mantisa. Nobody declare float x = 2.0000000000 to iniject the float
> point two into a code.
>
> slawek
>
>
>

[toc] | [prev] | [next] | [standalone]

#3544

U=BFytkownik "Kevin J. McCann" <Kevin.McCann@umbc.edu> napisa=B3 w wiadomo=B6ci
grup dyskusyjnych:iv1a86$sji$1@smc.vnet.net...
> 2.0 is not an integer nor a rational, it is machine precision. On the
> other hand 2 is an integer and exact.

The decimal fraction 2.0 is in mathematics (the science) exactly the same as
the sum 2 + 0/10

The convention that 2.0 is less accurate than 2.00 is applied ONLY in
Mathematica (the computer program).

[toc] | [prev] | [next] | [standalone]

#3533

On Jul 5, 4:17 am, "slawek" <sla...@host.pl> wrote:
> U ytkownik "Kevin J. McCann" <k...@KevinMcCann.com> napisa w wiadomo ci grup
> dyskusyjnych:ius7b6$30...@smc.vnet.net...
>
> > The answer to this puzzle is that the N[2.0,20] is 2.0, not
> > 2.00000000... Try N[2,20] and all is well. I think that when you put 2.0
> > in you have already limited yourself to machine precision, and N[2.0,20]
> > is then just machine accuracy.
>
> It is still a-bug-and-a-feature.
> And this bug make Mathematica nearly useless in numerical computations. "MS
> Windows Calculator" is much more reliable!

I have used Mathematica for numerical computation for nearly 20 years
and will say that on most days I do not find it to be useless. I am
not familiar with MS Windows Calculator so cannot comment on any
comparison between the two.


> The number of written digits IS NEITHER the precision NOR the accuracy.
> Mathematica treat 2.0 as a 2.0+-0.1, but it is not the proper way to handle
> numbers.

As written this is not correct. In Mathematica if you input 2.0 then
it is treated as a machine double, which on all platforms today has
around 16 decimal places. In any case it is 2. +-$MachineEpsilon.

The formatting of machine floats attempts (I believe always
successfully) to show the decimal approximating to the underlying
binary value (that is, within half an error-in-the-last place) that
has the least number of digits. So for example 2.1 will be printed as
2.1, even though the underlying binary representation is not
identically equal to 21/10.


> I know, that it is common mistake to treat 2.0 as "not an integer number"
> and/or "exact" number, but 2.0 is an integer number AND also it is a
> rational number AND also a real number AND also a complex number.

This is a matter to be determined by the language semantics (for any
language, not just Mathematica). A "design decision", if you will (and
as another response states). You may not like the design, and you may
have reasons for not liking it, or for preferring other programs. That
does not make this design intrinsically wrong.


> And 2.0 is
> simply 1+1+ 0/10 . Therefore, as you see, there is no "roudning", "limited
> precision", "error" or "uncertinaity". It is only a matter of a notation of
> decimal fractions. And decimal fractions are exact.

This is only true if the underlying representation is decimal. In some
programs that might be the case. In Mathematica underlying
representations are binary based. So a decimal such as 2.1 will not be
2 + 1/10 because that cannot be supported by finite binary
representation.

A different tack would be to translate, at parse time say, decimal
input such as 2.1 to exact input such as 21/10. I will spare anyone
who has read this far from all the reasons why that would be an
incredibly bad idea. Suffice it to say that if one wants to work with
exactly 21/10 then one should use 21/10, and not an approximate input
variant thereof.


> Any "tolerance" is not
> indicated in any way by this notation. Thus it is a bug. Nasty, big, fat bug
> in the core of Mathematica.
>
> Even from "CS view" 2.0 is translated to IEEE representation with 56-bits of
> the mantisa. Nobody declare float x = 2.0000000000 to iniject the float
> point two into a code.
>
> slawek


Daniel Lichtblau
Wolfram Research

[toc] | [prev] | [next] | [standalone]

#3510

On Tue, 05 Jul 2011 10:17:49 +0100, slawek <slawek@host.pl> wrote:

> U=BFytkownik "Kevin J. McCann" <kjm@KevinMcCann.com> napisa=B3 w wiadomo=B6ci  

> grup dyskusyjnych:ius7b6$30t$1@smc.vnet.net...
>> The answer to this puzzle is that the N[2.0,20] is 2.0, not
>> 2.00000000... Try N[2,20] and all is well. I think that when you put 2.0
>> in you have already limited yourself to machine precision, and N[2.0,20]
>> is then just machine accuracy.
>
> It is still a-bug-and-a-feature.
> And this bug make Mathematica nearly useless in numerical computations..  
> "MS Windows Calculator" is much more reliable!
>
> The number of written digits IS NEITHER the precision NOR the accuracy..
> Mathematica treat 2.0 as a 2.0+-0.1, but it is not the proper way to  
> handle numbers.
>

In fact:

In[1] :=
Interval[2.0] // InputForm

Out[1]//InputForm =
Interval[{1.9999999999999998, 2.0000000000000004}]

While:

In[2] :=
Interval[2.0``1] // InputForm

Out[2]//InputForm =
Interval[{1.875`1.2730012720637347, 2.125`1.327358934386329}]

Precision (which, as defined by Mathematica, means relative uncertainty) 
and accuracy (absolute uncertainty) are expressed as annotations after the  
number. In the special case of a number with a decimal point and no  
annotation, the number is taken to be a machine precision real. I agree 
that these definitions and the notational convention chosen by Mathematica  
are strange. However, there is nothing "improper" about it as a choice of  
formalism--at least, this is no worse a design choice than for Mathematica  
to have standardized on decimal notation for input and presentation of  
numerical values rather than binary as it uses internally.

The purpose of this approach is as a crude but often adequate  
approximation to interval arithmetic, whereby these (approximations of) 
errors are carried through arithmetic operations using first-order  
algebraic methods. When functions (such as N) that pay attention to  
Precision and Accuracy (by Mathematica's definitions) see them decreasing,  
they increase the working precision so as to avoid numerical instability
being expressed in the final result. This is by no means intended to be 
rigorous; it is merely a heuristic, but one that comes at little cost and  
works in many cases. Of course, if a user's own code treats this  
approximation as somehow sacrosanct and ignores the precision adjustments  
necessary during the calculation while taking the final answer as correct,  
it is more likely that the approximation will have fallen apart somewhere  
down the line.

If you don't like significance arithmetic, you have (at least) two other
options at hand: either work in fixed precision ($MinPrecision   
$MaxPrecision = prec) or use interval arithmetic. These have their own 
drawbacks, of course (most notably that Mathematica tacitly assumes all 
intervals are uncorrelated), but your hand isn't forced either way and you  
may even use all three methods simultaneously if you wish. Alternatively
you may program your own, more accurate algebraic or Monte Carlo error  
propagation methods if you prefer.

> I know, that it is common mistake to treat 2.0 as "not an integer number"
> and/or "exact" number, but 2.0 is an integer number AND also it is a
> rational number AND also a real number AND also a complex number. And 
> 2.0 is simply 1+1+ 0/10 . Therefore, as you see, there is no "roudning",  
> "limited
> precision", "error" or "uncertinaity". It is only a matter of a notation  
> of decimal fractions. And decimal fractions are exact. Any "tolerance"
> is not
> indicated in any way by this notation. Thus it is a bug. Nasty, big, fat  
> bug in the core of Mathematica.
>
> Even from "CS view" 2.0 is translated to IEEE representation with  
> 56-bits of
> the mantisa. Nobody declare float x = 2.0000000000 to iniject the float
> point two into a code.
>
> slawek

[toc] | [prev] | [next] | [standalone]

#3531

On 7/6/2011 2:39 AM, Oleksandr Rasputinov wrote:
> On Tue, 05 Jul 2011 10:17:49 +0100, slawek<slawek@host.pl>  wrote:
>
>> U=BFytkownik "Kevin J. McCann"<kjm@KevinMcCann.com>  napisa=B3 w wiadomo=B6ci
>
>> grup dyskusyjnych:ius7b6$30t$1@smc.vnet.net...
>>> The answer to this puzzle is that the N[2.0,20] is 2.0, not
>>> 2.00000000... Try N[2,20] and all is well. I think that when you put 2.0
>>> in you have already limited yourself to machine precision, and N[2.0, 20]
>>> is then just machine accuracy.
>>
>> It is still a-bug-and-a-feature.
>> And this bug make Mathematica nearly useless in numerical computations ..
>> "MS Windows Calculator" is much more reliable!
>>
>> The number of written digits IS NEITHER the precision NOR the accuracy ..
>> Mathematica treat 2.0 as a 2.0+-0.1, but it is not the proper way to
>> handle numbers.
>>
>
> In fact:
>
> In[1] :=
> Interval[2.0] // InputForm
>
> Out[1]//InputForm =
> Interval[{1.9999999999999998, 2.0000000000000004}]
>
> While:
>
> In[2] :=
> Interval[2.0``1] // InputForm
>
> Out[2]//InputForm =
> Interval[{1.875`1.2730012720637347, 2.125`1.327358934386329}]
>
> Precision (which, as defined by Mathematica, means relative uncertainty)
> and accuracy (absolute uncertainty) are expressed as annotations after the
> number. In the special case of a number with a decimal point and no
> annotation, the number is taken to be a machine precision real. I agree
> that these definitions and the notational convention chosen by Mathematica
> are strange. However, there is nothing "improper" about it as a choice of
> formalism--at least, this is no worse a design choice than for Mathematica
> to have standardized on decimal notation for input and presentation of
> numerical values rather than binary as it uses internally.
>
> The purpose of this approach is as a crude but often adequate
> approximation to interval arithmetic, whereby these (approximations of)
> errors are carried through arithmetic operations using first-order
> algebraic methods. When functions (such as N) that pay attention to
> Precision and Accuracy (by Mathematica's definitions) see them decreasing,
> they increase the working precision so as to avoid numerical instability
> being expressed in the final result. This is by no means intended to be
> rigorous; it is merely a heuristic, but one that comes at little cost and
> works in many cases. Of course, if a user's own code treats this
> approximation as somehow sacrosanct and ignores the precision adjustments
> necessary during the calculation while taking the final answer as correct,
> it is more likely that the approximation will have fallen apart somewhere
> down the line.
>
> If you don't like significance arithmetic, you have (at least) two other
> options at hand: either work in fixed precision ($MinPrecision
> $MaxPrecision = prec) or use interval arithmetic. These have their own
> drawbacks, of course (most notably that Mathematica tacitly assumes all
> intervals are uncorrelated), but your hand isn't forced either way and you
> may even use all three methods simultaneously if you wish. Alternatively
> you may program your own, more accurate algebraic or Monte Carlo error
> propagation methods if you prefer.
>
>....


>

This is an excellent summary of Mathematica's approach to arithmetic on
numbers.  Unfortunately many people come to use Mathematica with their
own notions of numbers, accuracy, precision, and equality. These words
are redefined in a non-standard way in Mathematica, leading to
unfortunate situations sometimes.  "unexplainable" behavior. confusion.
Or worse, erroneous results silently delivered and accepted as true by a
user, who "knows" about precision, accuracy, floating-point arithmetic, etc.

WRI argues that this is a winning proposition. Perhaps Wolfram still
believes that someday all the world will use Mathematica for all
programming purposes and everyone will accept his definition of terms
like Precision and Accuracy, and that (see separate thread on how to
write a mathematical paper) it will all be natural and consistent.
(or that people who want to hold to the standard usage will be forced to
use something like SetGlobalPrecision[prec_]:=
$MaxPrecision=MinPrecision=prec.
I believe this is routinely used by people who find Mathematica's
purportedly "user-friendly" amateurish error control to be hazardous.
)

.........

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it
means just what I choose it to mean =97 neither more nor less.'

'The question is,' said Alice, 'whether you can make words mean so many
different things.'

'The question is,' said Humpty Dumpty, 'which is to be master =97 that's
all.'

[toc] | [prev] | [next] | [standalone]

#3560

On Jul 7, 5:40 am, "slawek" <sla...@host.pl> wrote:

> The convention that 2.0 is less accurate than 2.00 is applied ONLY in
> Mathematica (the computer program).

Not true. This is a long-standing convention in experimental science.

[toc] | [prev] | [next] | [standalone]

#3682

Użytkownik "Noqsi" <noqsiaerospace@gmail.com> napisał w wiadomości grup 
dyskusyjnych:iv6gf9$ruo$1@smc.vnet.net...
> On Jul 7, 5:40 am, "slawek" <sla...@host.pl> wrote:
>
>> The convention that 2.0 is less accurate than 2.00 is applied ONLY in
>> Mathematica (the computer program).
>
> Not true. This is a long-standing convention in experimental science.

There is no such convention. There is always possible that 2.00 +- 0.53 .

Nobody should believe that 2.00 is more exact than 2.0 or even 2 . (If so, 
then 2 Pi have got 10% std. dev. ;)
 

[toc] | [prev] | [next] | [standalone]

#3586

On Thu, 07 Jul 2011 12:33:49 +0100, Richard Fateman  
<fateman@cs.berkeley.edu> wrote:

> On 7/6/2011 2:39 AM, Oleksandr Rasputinov wrote:
>>
>> Precision (which, as defined by Mathematica, means relative uncertainty)
>> and accuracy (absolute uncertainty) are expressed as annotations after  
>> the
>> number. In the special case of a number with a decimal point and no
>> annotation, the number is taken to be a machine precision real. I agree
>> that these definitions and the notational convention chosen by  
>> Mathematica
>> are strange. However, there is nothing "improper" about it as a choice  
>> of
>> formalism--at least, this is no worse a design choice than for  
>> Mathematica
>> to have standardized on decimal notation for input and presentation of
>> numerical values rather than binary as it uses internally.
>>
>> The purpose of this approach is as a crude but often adequate
>> approximation to interval arithmetic, whereby these (approximations of)
>> errors are carried through arithmetic operations using first-order
>> algebraic methods. When functions (such as N) that pay attention to
>> Precision and Accuracy (by Mathematica's definitions) see them  
>> decreasing,
>> they increase the working precision so as to avoid numerical instability
>> being expressed in the final result. This is by no means intended to be
>> rigorous; it is merely a heuristic, but one that comes at little cost  
>> and
>> works in many cases. Of course, if a user's own code treats this
>> approximation as somehow sacrosanct and ignores the precision  
>> adjustments
>> necessary during the calculation while taking the final answer as  
>> correct,
>> it is more likely that the approximation will have fallen apart  
>> somewhere
>> down the line.
>>
>> If you don't like significance arithmetic, you have (at least) two other
>> options at hand: either work in fixed precision ($MinPrecision
>> $MaxPrecision = prec) or use interval arithmetic. These have their own
>> drawbacks, of course (most notably that Mathematica tacitly assumes all
>> intervals are uncorrelated), but your hand isn't forced either way and  
>> you
>> may even use all three methods simultaneously if you wish. Alternatively
>> you may program your own, more accurate algebraic or Monte Carlo error
>> propagation methods if you prefer.
>>
>> ....
>>
>
> This is an excellent summary of Mathematica's approach to arithmetic on
> numbers.  Unfortunately many people come to use Mathematica with their
> own notions of numbers, accuracy, precision, and equality. These words
> are redefined in a non-standard way in Mathematica, leading to
> unfortunate situations sometimes.  "unexplainable" behavior. confusion.
> Or worse, erroneous results silently delivered and accepted as true by a
> user, who "knows" about precision, accuracy, floating-point arithmetic,  
> etc.

Apart from the curious definitions given to Precision and Accuracy (one  
imagines ApproximateRelativeError and ApproximateAbsoluteError were  
considered too verbose), I do not think Mathematica's way of doing things  
is particularly arbitrary or confusing in the broader context of  
multiprecision arithmetic. Mathematically, finite-precision numbers  
represent distributions over finite fields, and they therefore possess  
quantized upper and lower bounds, as well as quantized expectation values.  
Strictly, then, any two such distributions cannot be said to be equal if  
they represent numbers of different precision: they are then distributions  
over two entirely different fields, irrespective of whether their  
expectation values may be equal.

However, this definition is not very useful numerically and we are usually  
satisfied in practice that two finite-precision numbers equal if the  
expectation values are equal within quantization error. Note that the  
question of true equality for numbers of different precisions, i.e. the  
means of the distributions being equal, is impossible to resolve in  
general given that the means (which represent the exact values) are not  
available to us. Heuristically, the mean should be close, in a relative  
sense, to the expectation value, hence the tolerance employed by Equal;  
the exact magnitude of this tolerance may perhaps be a matter for debate  
but either way it is set using Internal`$EqualTolerance, which takes a  
machine real value indicating the number of decimal digits' tolerance that  
should be applied, i.e. Log[2]/Log[10] times the number of least  
significant bits one wishes to ignore. This setting has been discussed in  
this forum at least once in the past: see e.g.  
<http://forums.wolfram.com/mathgroup/archive/2009/Dec/msg00013.html>.

Note that if one wishes to be more rigorous when determining equality,  
SameQ operates in a similar manner to Equal for numeric comparands, except  
that its tolerance is 1 (binary) ulp. This is also adjustable, via  
Internal`$SameQTolerance.

In regard to erroneous results: undoubtedly it is a possibility. However,  
one would expect that an approximate first order method for dealing with  
error propagation should at least be better in the majority of cases than  
a zeroth-order method such as working in fixed precision. As stated  
previously, if one desires more accurate approximations then one is in any  
case free to implement them, although given the above it should be clear  
that all that is generally possible within the domain of finite-precision  
numbers is a reasonable approximation unless other information is  
available from which to make stronger deductions. I will also note that  
none of the example "problems" in this present topic are anything directly  
to do with significance arithmetic; they instead represent a combination  
of confusion due to Mathematica's (admittedly confusing) choice of  
notation, combined with an apparent misunderstanding of concepts related  
to multiprecision arithmetic in general.

>
> WRI argues that this is a winning proposition. Perhaps Wolfram still
> believes that someday all the world will use Mathematica for all
> programming purposes and everyone will accept his definition of terms
> like Precision and Accuracy, and that (see separate thread on how to
> write a mathematical paper) it will all be natural and consistent.
> (or that people who want to hold to the standard usage will be forced to
> use something like SetGlobalPrecision[prec_]:=
> $MaxPrecision=MinPrecision=prec.
> I believe this is routinely used by people who find Mathematica's
> purportedly "user-friendly" amateurish error control to be hazardous.
> )
>
> .........
>
> 'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it
> means just what I choose it to mean =97 neither more nor less.'
>
> 'The question is,' said Alice, 'whether you can make words mean so many
> different things.'
>
> 'The question is,' said Humpty Dumpty, 'which is to be master =97 that's
> all.'

[toc] | [prev] | [next] | [standalone]

#3605

On 7/8/2011 2:04 AM, Oleksandr Rasputinov wrote:

.. snip...

>
> Apart from the curious definitions given to Precision and Accuracy (one
> imagines ApproximateRelativeError and ApproximateAbsoluteError were
> considered too verbose), I do not think Mathematica's way of doing things
> is particularly arbitrary or confusing in the broader context of
> multiprecision arithmetic. Mathematically, finite-precision numbers
> represent distributions over finite fields, and they therefore possess
> quantized upper and lower bounds, as well as quantized expectation values.

This is one view, but one that is not especially useful computationally.
A much more useful view is that a finite-precision number is simply a 
single value. That's all.   The number 3 has no fuzz around it. The 
double-float number 0.1d0 has no fuzz around it either.  It is not 
exactly 1/10, but

7205759403792794 X 2 ^(-56).

exactly. It is a finite precision number because the fraction part, here 
7205759403792794, is limited to a fixed number of bits.  There is, I 
repeat, nothing that makes it a distribution.
Another way of writing it is

3602879701896397/36028797018963968

  The advantages of this view:
(1) arithmetic is well-defined and executable on a computer
(2) should you choose to implement some kind of distribution arithmetic 
-- intervals, Gaussian bell curves, significance arithmetic, 
fuzzy-set-theoretic whatever,  you can do so knowing that the underlying 
implementation of arithmetic is supportive of any model that can be 
reduced to ordinary mathematics.

> Strictly, then, any two such distributions cannot be said to be equal if
> they represent numbers of different precision: they are then distributions
> over two entirely different fields, irrespective of whether their
> expectation values may be equal.

This is something you are free to implement. I personally object to an 
arithmetic system and a notion of equality that does not support the 
fundamental properties of equivalence relations.  I much prefer that if 
a==b, then a-b==0.  This of course fails, in Mathematica.



>
> However, this definition is not very useful numerically and we are usually
> satisfied in practice that two finite-precision numbers equal if the
> expectation values are equal within quantization error.

No, I disagree.  It used to be that programmers were taught that one 
should never (or almost never)  compare floating point numbers for 
equality.  You can easily ask if two numbers are relatively or 
absolutely close.  That is not the same as being equal.


  Note that the
> question of true equality for numbers of different precisions, i.e. the
> means of the distributions being equal, is impossible to resolve in
> general given that the means (which represent the exact values) are not
> available to us.

The fault here is that you view numbers as distributions.  I have no 
problem telling if a number 0.1d0  is equal to 
3602879701896397/36028797018963968 .

It is. That is its value.  It is equal to all other objects with the 
same exact value. That's what equal means.

Is it equal to 0.099999999?  No, but it is relatively close by some measure.


  Heuristically, the mean should be close, in a relative
> sense, to the expectation value, hence the tolerance employed by Equal;

You may choose to believe this, but it is mathematical nonsense.

> the exact magnitude of this tolerance may perhaps be a matter for debate
> but either way it is set using Internal`$EqualTolerance, which takes a
> machine real value indicating the number of decimal digits' tolerance that
> should be applied, i.e. Log[2]/Log[10] times the number of least
> significant bits one wishes to ignore. This setting has been discussed in
> this forum at least once in the past: see e.g.
> <http://forums.wolfram.com/mathgroup/archive/2009/Dec/msg00013.html>.

I suspect there are more insightful discussions in the archives.

>
> Note that if one wishes to be more rigorous when determining equality,
> SameQ operates in a similar manner to Equal for numeric comparands, except
> that its tolerance is 1 (binary) ulp. This is also adjustable, via
> Internal`$SameQTolerance.

It is nice that one can try to scrape out all the garbage of the 
arithmetic by setting internal flags, but the way it is set up in 
Mathematica, the ordinary user with default system settings is exposed 
to a really defective arithmetic system.

>
> In regard to erroneous results: undoubtedly it is a possibility. However,
> one would expect that an approximate first order method for dealing with
> error propagation should at least be better in the majority of cases than
> a zeroth-order method such as working in fixed precision.
You might think that, but the choice is not so clear.
If you set $MinPrecision=$MaxPrecision
then
(i = 1.100000000000000000; Do[(i = 2*i - i; Print[i]), {4}])
gives Overflow[]  4 times.

In the default setting, $MinPRecision is 0.
then
(i = 1.100000000000000000; Do[(i = 2*i - i; Print[i]), {50}]

sets i to decreasingly precise values, ending in 0., 0., 0X10^1, ... 0X10^5

(try it.. it is only one line!)

What is the naive user to do?

If you think this example is a good result, imagine what would happen to 
a naive user (most are) who has a more elaborate program (most are) 
which internally produces an answer "  0. "  which is entirely bogus?


  As stated
> previously, if one desires more accurate approximations then one is in any
> case free to implement them, although given the above it should be clear
> that all that is generally possible within the domain of finite-precision
> numbers is a reasonable approximation unless other information is
> available from which to make stronger deductions.

Quite the opposite.  All numbers in a computer calculation should be 
considered exact unless other information is available from which to 
make WEAKER deductions.  Then the kind of deductions (based, perhaps, on 
knowledge of physical measurements or uncertainties) can be incorporated 
in the calculation.

  I will also note that
> none of the example "problems" in this present topic are anything directly
> to do with significance arithmetic; they instead represent a combination
> of confusion due to Mathematica's (admittedly confusing) choice of
> notation,

I think that is right.

  combined with an apparent misunderstanding of concepts related
> to multiprecision arithmetic in general.

  I think that the concepts of multiprecision arithmetic as implemented 
in Mathematica are different from other implementations in general. 
Bringing such outside knowledge to bear on an utterance in Mathematica 
is hazardous.


>
>>
>> WRI argues that this is a winning proposition. Perhaps Wolfram still
>> believes that someday all the world will use Mathematica for all
>> programming purposes and everyone will accept his definition of terms
>> like Precision and Accuracy, and that (see separate thread on how to
>> write a mathematical paper) it will all be natural and consistent.
>> (or that people who want to hold to the standard usage will be forced to
>> use something like SetGlobalPrecision[prec_]:=
>> $MaxPrecision=MinPrecision=prec.
>> I believe this is routinely used by people who find Mathematica's
>> purportedly "user-friendly" amateurish error control to be hazardous.
>> )
>>
>> .........
>>
>> 'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it
>> means just what I choose it to mean =97 neither more nor less.'
>>
>> 'The question is,' said Alice, 'whether you can make words mean so many
>> different things.'
>>
>> 'The question is,' said Humpty Dumpty, 'which is to be master =97 that's
>> all.'
>

[toc] | [prev] | [next] | [standalone]

#3666

Użytkownik "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com> napisał 
w wiadomości grup dyskusyjnych:iv6h68$s97$1@smc.vnet.net...
> considered too verbose), I do not think Mathematica's way of doing things
> is particularly arbitrary or confusing in the broader context of

If  1.4 is not the same as 14/10, then Mathematica should evaluate 1.4 == 
14/10 as False.

 

[toc] | [prev] | [next] | [standalone]

#3610

On Fri, 08 Jul 2011 09:51:53 +0100, Noqsi <noqsiaerospace@gmail.com> wrote:

> On Jul 7, 5:40 am, "slawek" <sla...@host.pl> wrote:
>
>> The convention that 2.0 is less accurate than 2.00 is applied ONLY in
>> Mathematica (the computer program).
>
> Not true. This is a long-standing convention in experimental science.
>

Unfortunately so, given that it is severely erroneous: see e.g.  
<http://www.av8n.com/physics/uncertainty.htm>. However, Mathematica's  
approximation of how these uncertainties propagate is first-order, not  
zeroth-order. This does not make it completely reliable, of course, but  
certainly it is not almost always wrong as is the significant digits  
convention. Within the bounds of its own applicability, Mathematica's  
approximation is reasonable, although it would still be a mistake to apply  
it to experimental uncertainty analysis given the much broader scope of  
the latter.

[toc] | [prev] | [next] | [standalone]

#3683

On Jul 9, 4:37 am, "Oleksandr Rasputinov"
<oleksandr_rasputi...@hmamail.com> wrote:
> On Fri, 08 Jul 2011 09:51:53 +0100, Noqsi <noqsiaerosp...@gmail.com> wrote:
> > On Jul 7, 5:40 am, "slawek" <sla...@host.pl> wrote:
>
> >> The convention that 2.0 is less accurate than 2.00 is applied ONLY in
> >> Mathematica (the computer program).
>
> > Not true. This is a long-standing convention in experimental science.
>
> Unfortunately so, given that it is severely erroneous:

Such an unqualified statement is unjustified. Whether this produces
troublesome error or not depends on what you're doing.

> see e.g.  
> <http://www.av8n.com/physics/uncertainty.htm>.

I have some sympathy with this point of view. But I recall a rather
vehement dispute between two colleagues in a tame case where recording
only significant digits was fine. That dispute poisoned human
relationships unnecessarily. The real folly is to be ideological about
this, instead of understanding what you're doing *from the perspective
of the problem domain*. One size does not fit all.

> However, Mathematica's  
> approximation of how these uncertainties propagate is first-order, not 
> zeroth-order. This does not make it completely reliable, of course, but 
> certainly it is not almost always wrong as is the significant digits  
> convention. Within the bounds of its own applicability, Mathematica's  
> approximation is reasonable, although it would still be a mistake to apply  
> it to experimental uncertainty analysis given the much broader scope of 
> the latter.

Experimental uncertainty analysis almost always involves
approximation. Avoiding shortcuts in the statistical formulation can
lead to extremely large calculations even when the data set is very
small. See, for example, Loredo and Lamb 1989, bibcode 1989NYASA.
571..601L. This example still required numerical approximation. In
this case, I think the enormous human and computational effort was
justified, but the appropriateness of any particular approach depends
on the problem to be solved.

[toc] | [prev] | [next] | [standalone]

#3705

On 7/13/2011 12:11 AM, Noqsi wrote:
..

>> see e.g.
>> <http://www.av8n.com/physics/uncertainty.htm>.
>
>
..
Learning mathematics from a physicist is hazardous.
Learning computer science from a physicist is hazardous too.
Numbers in a computer are different from experimental measurements.


nevertheless, I like this article.  It says, among other things,

	The technique of propagating the uncertainty from step to step 
throughout the calculation is a very bad technique. It might sometimes 
work for super-simple “textbook” problems but it is unlikely to work for 
real-world problems.

[toc] | [prev] | [next] | [standalone]

#3719

On 14 Jul 2011, at 11:21, Richard Fateman wrote:

> On 7/13/2011 12:11 AM, Noqsi wrote:
> ..
>
>>> see e.g.
>>> <http://www.av8n.com/physics/uncertainty.htm>.
>>
>>
> ..
> Learning mathematics from a physicist is hazardous.
> Learning computer science from a physicist is hazardous too.
> Numbers in a computer are different from experimental measurements.
>
>
> nevertheless, I like this article.  It says, among other things,
>
> 	The technique of propagating the uncertainty from step to step
> throughout the calculation is a very bad technique. It might sometimes
> work for super-simple textbook problems but it is unlikely to work for
> real-world problems.
>

Well, here is a quote from a very well known book on numerical analysis by a mathematician (Henrici, "Elements of Numerical Analysis").


> It is plain that, on a given machine and for a given problem, the local
> rounding errors are not, in fact, random variables. If the same problem
> is run on the same machine a number of times, there will result always the
> same local rounding errors, and therefore also the same accumulated
> error. We may, however, adopt a stochastic model of the propagation of
> rounding error, where the local errors are treated as if they were random
> variables. This stochastic model has been applied in the literature to a
> number of different numerical problems and has produced results that are
> in complete agreement with experimentally observed results in several
> important cases.


The book then describes the statistical method of error propagation of which Mathematica's approach can be regarded as a first order approximation (as pointed out by Oleksandr Rasputinov, who should not be confused with the OP of this thread so:

> Clearly Rasputinov thinks that if they are not equal they should not be
> Equal.  Thus the answer is False.

 is *clearly* False. In fact Oleksander expressed something closer to the opposite view.)

And if one quote is not enough, here is another, from another text on numerical analysis. (Conte, de Boor, ""Elementary Numerical Analysis).
It describes 4 approaches to error analysis, interval arithmetic, significant-digit arithmetic, the "statistical approach" and backward error analysis. Here is what it says about the second and the third one:

> A third approach is significant-digit arithmetic. As pointed out earlier, whenever two nearly equal machine numbers are subtracted, there is a danger that some significant digits will be lost. In significant-digit arithmetic an attempt is made to keep track of digits so lost. In one version
> only the significant digits in any number are retained, all others being discarded. At the end of a computation we will thus be assured that all digits retained are significant. The main objection to this method is that some information is lost whenever digits are discarded, and that the results obtained are likely to be much too conservative. Experimentation with this technique is still going on, although the experience to date is not too promising.
>
> A fourth method which gives considerable promise of providing an adequate mathematical theory of round-off-error propagation is based on a statistical approach. It begins with the assumption that round-off errors are independent. This assumption is, of course, not valid, because if the same problem is run on the same machine several times, the answers will always be the same. We can, however, adopt a stochastic model of the propagation of round-off errors in which the local errors are treated as if they were random variables. Thus we can assume that the local round-off errors are either uniformly or normally distributed between their extreme values. Using statistical methods, we can then obtain the standard devia- tion, the variance of distribution, and estimates of the accumulated round- off error. The statistical approach is considered in some detail by Ham- ming [1] and Henrici [2]. The method does involve substantial analysis and additional computer time, but in the experiments conducted to date it has obtained error estimates which are in remarkable agreement with experimentally available evidence.



The fundamental paper of Mathematica's error propagation is "Precise numerical computation" by Mark Sofroniou and  Giulia Spaletta in The Journal of Logic and Algebraic Programming 64 (2005) 113=96134. This paper describes Mathematica's "significance arithmetic" as a first order approximation to Interval Arithmetic. It makes no mention of distributions. Oleksandr Rasputionov, in an earlier post here, interpreted  "significance arithmetic" as a first order approximation to the fourth method above. I have not considered this very carefully, but it seems pretty clear that he is right, and that the two "first order" approximations are in fact isomorphic. The first order approach is, of course, justified on grounds of performance. It is perfectly "rigorous" in the same sense as any "first order" approach is (i.e. taking a linear approximation to the Taylor series of a non-linear function). It works fine under certain conditions and will produce nonsense when these conditions do not hold.

The fact that significance arithmetic is "useful" needs no justification other than the fact that it is used successfully by NSolve and Reduce in achieving validated symbolic results by numerical methods which are vastly faster than purely symbolic ones.

It is also useful, for users such as myself, who sometimes need fast first order error anlysis.

I have lots of posts by Richard on this topic (or perhaps it was the same post lots of time, it's so hard to tell), but I have never understood what his main point is. It seems to me that is because he himself has not yet decided this, although he has been posting on this topic for over 20 years (I think).

Sometimes he seems to be disparaging significance arithmetic itself. When Daniel points out how effective it is in his implementation of numerical Groebner basis, or in Adam Strzebonski's work on Reduce, he either ignores this altogether or claims that Groebner bases, etc.  are themselves not "useful".

On other occasions he takes on the role of the defender of the interest of the "naive user" (presumably like the OP, who however would be better described as "intentionally naive") who is going to be confused by the "quirky" nature of significance arithmetic (at low precision). In doing so he conveniently ignores that fact of the existence of thousands of "naive users" who never become confused (sometimes because they always work with machine precision numbers and only use significance arrhythmic unknowingly, e.g. when using Reduce). And moreover, for those who do find a need for some sort of error analysis he offers no alternative, except perhaps to learn backward error analysis. Except, of course, that should they do so they would no longer be "naive" and thus outside of Richard's area of concern.  And in any case, anyone who needs and understands backward error analysis can use it now, and can't imagine that even Richard would claim that reducing users' options is a good thing.

Finally, perhaps all that Richard is so upset about is simply Mathematica's habit of defining numbers as "fuzz balls" or "distributions". In other words, if Mathematica used a more usual "definition" of number, and used significance arithmetic for "error" propagation, that would be done by applying some separate function or turning on an option,  than everything would be fine? If that is all, than it seems to me that Richard has for years been making mountains of molehills.


Andrzej Kozlowski

[toc] | [prev] | [next] | [standalone]

#3730

On Jul 14, 2011, at 11:21 AM, Richard Fateman <fateman@cs.berkeley.edu> wrote:
> Learning mathematics from a physicist is hazardous.
> Learning computer science from a physicist is hazardous too.
> Numbers in a computer are different from experimental measurements.

I believe that I won't be the only one who objects to this hyperbole and limited world view. I've learned poor quality math from poor quality instructors---but this is not "hazardous.". I've learned  what I believe to be high quality math from excellent physics and mathematical physics instructors.

Every experimental measurement of a continuously varying quantity will have some imprecision. Entering that number into a computer may or may not add to the imprecision. Keeping track of the sources of imprecision is what good experimentalist does. 

Of course, an experiment is different from a number; but the experimentally d
etermined number and its sources of imprecision  in a computer is just another number on the computer. There is no difference in meaning unless the precision of the experiment exceeds that of the measurement.

WCC

[toc] | [prev] | [next] | [standalone]

#3739

You are clearly confusing significant digit arithmetic, which is not 
what Mathematica uses, with significance arithmetic, which is a first 
order approximation to interval arithmetic or distribution based 
approach. Obviously you don't read the posts you reply to and confuse 
both the posters and the contents of what they post. Here is a quote 
from Oleksandr Rasputionov that makes this completely clear:


Unfortunately so, given that it is severely erroneous: see e.g. 
<http://www.av8n.com/physics/uncertainty.htm>. However, Mathematica's 
approximation of how these uncertainties propagate is first-order, not 
zeroth-order. This does not make it completely reliable, of course, but 
certainly it is not almost always wrong as is the significant digits 
convention. Within the bounds of its own applicability, Mathematica's 
approximation is reasonable, although it would still be a mistake to apply 
it to experimental uncertainty analysis given the much broader scope of 
the latter.

Note the "first-order not zeroth-order". Also, do take a look at Sofroniou and Spaletta and then you may perhaps understand what "order" means and how "significance arithmetic" differs from the "significant digits" convention. Good grief, did you ever learn about the Taylor series? It must have been a long time ago, I take.


Andrzej Kozlowski


On 14 Jul 2011, at 19:55, Richard Fateman wrote:

> On 7/14/2011 6:27 AM, Andrzej Kozlowski wrote:
>> On 14 Jul 2011, at 11:21, Richard Fateman wrote:
>>
>>> On 7/13/2011 12:11 AM, Noqsi wrote:
>>> ..
>>>
>>>>> see e.g.
>>>>> <http://www.av8n.com/physics/uncertainty.htm>.
>>>>
>>> ..
>>> Learning mathematics from a physicist is hazardous.
>>> Learning computer science from a physicist is hazardous too.
>>> Numbers in a computer are different from experimental measurements.
>>>
>>>
>>> nevertheless, I like this article.  It says, among other things,
>>>
>>> 	The technique of propagating the uncertainty from step to step
>>> throughout the calculation is a very bad technique. It might sometimes
>>> work for super-simple textbook problems but it is unlikely to work for
>>> real-world problems.
>>>
>> Well, here is a quote from a very well known book on numerical 
analysis by a mathematician (Henrici, "Elements of Numerical Analysis").
>>
>>
>>> It is plain that, on a given machine and for a given problem, the local
>>> rounding errors are not, in fact, random variables. If the same problem
>>> is run on the same machine a number of times, there will result always the
>>> same local rounding errors, and therefore also the same accumulated
>>> error. We may, however, adopt a stochastic model of the propagation of
>>> rounding error, where the local errors are treated as if they were random
>>> variables. This stochastic model has been applied in the literature to a
>>> number of different numerical problems and has produced results that are
>>> in complete agreement with experimentally observed results in several
>>> important cases.
>>
>> The book then describes the statistical method of error propagation of which Mathematica's approach can be regarded as a first order approximation (as pointed out by Oleksandr Rasputinov, who should not be confused with the OP of this thread so:
>
> So are we to conclude that Henrici recommends this as a general  numerical computational method?
>
> I don't see that here.  I think what he is saying is that if you do some mathematics (see below), then
> you will get results consistent with what you will get if you actually run the experiment on the computer.
> This is not surprising. It is a result that says that "theoretical" numerical analysis agrees with
> "computer experiments" in arithmetic.  It doesn't say Henrici recommends running a computation this way.
>
> When Henrici says "adopt a stochastic model ...."  he doesn't mean to write a program. He means to
> think about each operation like this..  (I show for multiplication of numbers P and Q with errors a b resp.)
>
> P*(1+a)  times Q*(1+b)   P*Q *(1+a)*(1+b)* (1+c)   where c is a new "error" bounded by roundoff, e.g. half unit in last place.
>
> For each operation in the calculation, make up another error letter... a,b,c,d,e,f,g...
> assume they are uncorrelated.
>
> The fact that this theoretical approach and numerically running "several important cases" is a statement
> about correlation of roundoff in these cases, not a statement of advisability of whatever for a model of
> how to write a computer system.
>
> By the way, I think that Henrici was an extremely fine theoretical numerical analyst, and a fine writer too.
>
>
>
>>> Clearly Rasputinov thinks that if they are not equal they should not be
>>> Equal.  Thus the answer is False.
>>  is *clearly* False. In fact Oleksander expressed something closer to the opposite view.)
> This thread is too long.   I don't know at this point if you are agreeing that it is false or contradicting that "is False" is false.
>> And if one quote is not enough, here is another, from another text on numerical analysis. (Conte, de Boor, ""Elementary Numerical Analysis).
>> It describes 4 approaches to error analysis, interval arithmetic, significant-digit arithmetic, the "statistical approach" and backward error analysis. Here is what it says about the second and the third one:
> Huh, if we are talking about the second and third one, why does he say third and fourth?
> Are you using 0-based indexing and deBoor is using 1-based indexing????
>
>
>>> A third approach is significant-digit arithmetic. As pointed out earlier, whenever two nearly equal machine numbers are subtracted, there is a danger that some significant digits will be lost. In significant-digit arithmetic an attempt is made to keep track of digits so lost. In one version
>>> only the significant digits in any number are retained, all others being discarded. At the end of a computation we will thus be assured that all digits retained are significant. The main objection to this method is that some information is lost whenever digits are discarded, and that the results obtained are likely to be much too conservative. Experimentation with this technique is still going on, although the experience to date is not too promising.
>>>
> OK, so deBoor (who is retired and therefore not likely to revise the "experience to date")  says this method  "is not too promising".
> This sounds to me like he is not endorsing what Mathematica does.
>
>>> A fourth method which gives considerable promise of providing an adequate mathematical theory of round-off-error propagation is based on a statistical approach. It begins with the assumption that round-off errors are independent. This assumption is, of course, not valid, because if the same problem is run on the same machine several times, the answers will always be the same. We can, however, adopt a stochastic model of the propagation of round-off errors in which the local errors are treated as if they were random variables. Thus we can assume that the local round-off errors are either uniformly or normally distributed between their extreme values. Using statistical methods, we can then obtain the standard devia- tion, the variance of distribution, and estimates of the accumulated round- off error. The statistical approach is considered in some detail by Ham- ming [1] and Henrici [2]. The method does involve substantial analysis and additional computer time, but in the experiments conducted to date it has obtained error estimates which are in remarkable agreement with experimentally available evidence.
> deBoor is essentially quoting Henrici, and this statistical approach is to say that all those error terms I mentioned above,  a,b,c,d,e,f,...
> can be chosen from some distribution   (the way I've written it,  a ,....,z ....   would essentially be chosen from {-u,u} where u  = 2^(-W) where the fraction part of the floating-point number is W bits.  )   and you can compute the final expression as ANSWER+<somehorrendousfunctionof>(a,b,c,....).
>
>  What deBoor says is that this (theoretical numerical analysis) "method" promises to provide
> a theory of round-off error propagation.   He is not saying this is a practical method for scientific computing.  When he uses the work "method"
> he means a mathematical method for analyzing roundoff.
>
> In any case, Mathematica does not do this.  I would further argue that Mathematica makes it hard to carry out the experiments that might be done to demonstrate that  this theory applied in any particular sample computation.
>>
>> The fundamental paper of Mathematica's error propagation is "Precise numerical computation" by Mark Sofroniou and  Giulia Spaletta in The Journal of Logic and Algebraic Programming 64 (2005) 113=96134. This paper describes Mathematica's "significance arithmetic" as a first order approximation to Interval Arithmetic. It makes no mention of distributions.
> I thought I read this paper in some Mathematica documentation or conference proceedings.
>> Oleksandr Rasputionov, in an earlier post here, interpreted  "significance arithmetic" as a first order approximation to the fourth method above.
> Huh? First of all, the original poster was slawek.  Rasputinov seems to think that Mathematica numbers are like Intervals  (basically a good intuition until you think about equality.) and refers to them as distributions.  This is not deBoor's 4th "method" of theoretically analyzing round-off.
> In fact it is deBoor's 1st method, interval arithmetic.  This has the advantage of being maybe 4 to 8 times slower than regular arithmetic, and also has a huge literature  (see "Reliable Computation") describing variations, advantages, disadvantages, etc.
>
>>  I have not considered this very carefully, but it seems pretty clear that he is right, and that the two "first order" approximations are in fact isomorphic.
> Uh, this is unclear, unless you mean that Mathematica's number system is essentially interval arithmetic, but with a confusing front end.
>>  The first order approach is, of course, justified on grounds of performance. It is perfectly "rigorous" in the same sense as any "first order" approach is (i.e. taking a linear approximation to the Taylor series of a non-linear function). It works fine under certain conditions and will produce nonsense when these conditions do not hold.
>>
>> The fact that significance arithmetic is "useful" needs no justification other than the fact that it is used successfully by NSolve and Reduce in achieving validated symbolic results by numerical methods which are vastly faster than purely symbolic ones.
> Really?
>
> 1. This does not mean that other methods, e.g. validated methods for accurately evaluating polynomials (etc)  NOT based on significance arithmetic would not be faster and better.  DanL claims it is used and useful there, so that's nice.  BUT..
>
> 2. This does not mean that this arithmetic should be used by default by user arithmetic.
>> It is also useful, for users such as myself, who sometimes need fast first order error anlysis.
> OK, If you find it useful yourself, fine. I daresay you are not a typical user.
>
>> I have lots of posts by Richard on this topic (or perhaps it was the same post lots of time, it's so hard to tell), but I have never understood what his main point is.
>
> Main points:  Mathematica's number system is non-standard, peculiar, hard to explain,  capable of returning mysterious non-answers without indications of error to innocent users, a bad foundation for building higher-level functionality.
>
> I have other criticisms of Mathematica, but I think that the sentence above is enough for you to process today.
>
>>  It seems to me that is because he himself has not yet decided this, although he has been posting on this topic for over 20 years (I think).
>
>> Sometimes he seems to be disparaging significance arithmetic itself.
> I think deBoor did that.
>
>>  When Daniel points out how effective it is in his implementation of numerical Groebner basis, or in Adam Strzebonski's work on Reduce, he either ignores this altogether or claims that Groebner bases, etc.  are themselves not "useful".
> I think Reduce is a very nice program when it works. If I am not mistaken, all work on numerical Groebner basis should be reducible to the evaluation of polynomials, for which there are faster and more accurate methods available not using significance arithmetic.  On the other hand, I might be mischaracterizing DanL work, since I admit to not having studied it.
>
>
>> On other occasions he takes on the role of the defender of the interest of the "naive user" (presumably like the OP, who however would be better described as "intentionally naive") who is going to be confused by the "quirky" nature of significance arithmetic (at low precision).
> No, I don't think that slawek was a "troll".  I think he was genuinely confused, as might anyone be who has some prior computer arithmetic exposure and for the first time encounters a system with exact rational arithmetic.
>>  In doing so he conveniently ignores that fact of the existence of thousands of "naive users" who never become confused (sometimes because they always work with machine precision numbers and only use significance arrhythmic unknowingly, e.g. when using Reduce).
> Most naive users don't tread near the dangerous spots. Some naive users never notice that their answers are nonsense.
> Every so often we get a naive user who DOES notice, and he/she sends email to this newsgroup.
>>  And moreover, for those who do find a need for some sort of error analysis he offers no alternative, except perhaps to learn backward error analysis.
> Actually, there's a whole bunch of libraries of methods with error estimates for common computations, where backward error analysis or some other method was used to provide extra information.
>
>>  Except, of course, that should they do so they would no longer be "naive" and thus outside of Richard's area of concern.
> They would probably not be writing in Mathematica.
>> And in any case, anyone who needs and understands backward error analysis can use it now, and can't imagine that even Richard would claim that reducing users' options is a good thing.
> I have no problem with Mathematica providing as an option, some other arithmetic.  It is WRI that has made it rather hard for the user to
> figure out how to  "use the arithmetic of the rest of the world".
>
>> Finally, perhaps all that Richard is so upset about is simply Mathematica's habit of defining numbers as "fuzz balls" or "distributions".
> I'm not sure that "upset" is the right term.  After all, I don't have to use Mathematica for numerical computation. And I rarely do.
>> In other words, if Mathematica used a more usual "definition" of number, and used significance arithmetic for "error" propagation, that would be done by applying some separate function or turning on an option,  than everything would be fine?
> Actually, that's pretty close to correct.
>> If that is all, than it seems to me that Richard has for years been making mountains of molehills.
> So why are you (and WRI)  so opposed to this notion?  Note that it would also have to affect other parts of the system including of course,
> Equal and friends.
>
>
>>
>> Andrzej Kozlowski
>>
>>
>>
>>
>
>

[toc] | [prev] | [next] | [standalone]

#3752

On 15 Jul 2011, at 16:49, Richard Fateman wrote:

> On 7/14/2011 11:55 PM, Andrzej Kozlowski wrote:
>
> Gee, Andrzej, all I can think of is the childhood playground chant  (I don't know where you might have been a child, so this may not
> bring back memories...)
>
> "I'm rubber, you're glue; everything You say sticks to YOU!"

Yes, I can also think of a few playground chants that would apply nicely, but unfortunately you would not understand them. So let's  have something English instead, like "Sticks and stones...".

Now, I really have no time or patience to go over all your misrepresentations in detail. But let me point out (or remind you perhaps) that the already mentioned paper of Sofroniou and Spaletta makes the following remark:

> The choice of significance arithmetic as the default in Mathematica has not been universally favorable (see for example [9]) although some of these criticisms relate to early deficiencies in the implementation.


Reference [9] is, of course:

[9] R.J. Fateman, A review of Mathematica, J. Symbolic Comput. 13 (1992) 545=96579.

In fact the "early" version was much more like "significant digits convention", while the current version is quite a lot more sophisticated, as described in the article. Somehow you don't seem to have noticed it since that is the "early version" that you always seem to be describing. (Significant digits is something that used to be taught in primary school, if I recall correctly).

As for difference between theoretical analysis of the propagation of round-off error  and  practical  scientific computations, I am well aware of it, but was it not you who gleefully quoted the statement:

The technique of propagating the uncertainty from step to step
throughout the calculation is a very bad technique. It might sometimes
work for super-simple textbook problems but it is unlikely to work for
real-world problems.

So if agree with this (as you seem to), are you implying that the entire chapter 16 of Henrici's book is concerned with something that only applies to "super-simple text book problems"?

The point is, of course, that you never make it clearly what exactly you are talking about probably because you find it convenient for rhetorical purposes (90% of these discussions are really just rhetorics).

I should add that I myself long ago and more then once wrote on this forum that I do not think Mathematica's "approximate numbers" are a good model for empirical errors, but they are very good tools for solving certain purely mathematical problems. Often it can be accomplished in 100% provably correct way (barring bugs of course).

As for things like numerical Groebner basis etc, you keep arguing that it probably can be done in some other way (without significance arithmetic) and in a certain, rather trivial, sense you undoubtedly right. But the fact is, as Daniel has pointed out, that, in practice, nobody seems to have done it in another way, and not for want of trying. So again here we have the distinction between "theory" and "practical application" but except that this time the shoe is on the other foot.

Andrzej




>> You are clearly confusing significant digit arithmetic, which is not what Mathematica uses, with significance arithmetic, which is a first order approximation to interval arithmetic or distribution based approach.
>
> I view significant digit arithmetic, if by digit you allow binary digit or "bit", to be a crude version of interval arithmetic where the endpoints of the interval are not numbers of (essentially) arbitrary precision, but where the endpoints must be represented by the central point plus or minus some power of two.   It is an approximation to interval arithmetic.  I think it is a reasonable idea to restrict the =
number of digits carried in the value of the interval endpoints  (making =
them "cruder" than you might really know) in the interests of efficiency =
in time and space. Thus using properly rounded machine floats is =
appropriate, at least when the range is suitable and the difference =
between upper and lower bounds is large.  Using just one bit makes the =
width of the interval grow faster than using more bits...
>
> Since you do not understand the context of the paragraphs you have =
quoted, nor do you seem to acknowledge the difference between =
theoretical analysis of the propagation of round-off error in =
well-chosen standard examples, and somehow running interval arithmetic =
all the time, it is hard to know how to educate you.  How comforting is =
your proud quote, below?  Mathematica's arithmetic is "not ... =
completely reliable".   Rasputinov says,
> further,  "it is not almost always wrong".  I'm not sure why he says =
the significant digit convention is almost always wrong unless he means =
almost always too pessimistic.  I'm also not aware of why Rasputinov's =
opinion should sway the discussion especially (sorry Oleksandr).
>
>
> My point remains:
> WRI could have a much more direct notion of number, and equality, that =
would make it easy to implement my choice of arithmetic or theirs or =
yours.
> They didn't.  The default is not completely reliable. People write to =
this newsgroup, periodically, saying Huh? what's going on? I found a =
bug!
>
> As for the experimental and computational notions of (im)precision, I =
think there is an issue of using the same words with different meanings. =
Similar but unfortunately different. Precision of a floating point =
number F is simply the number of bits in the fraction.  If you impute =
some uncertainty to F, you can store that in another piece of data D in =
the computer. If you want to assert that F and D together represent a =
distribution of a certain kind  you can also compute with that.
>
> RJF
>
>>  Obviously you don't read the posts you reply to and confuse both the =
posters and the contents of what they post. Here is a quote from =
Oleksandr Rasputionov that makes this completely clear:
>>
>>
>> Unfortunately so, given that it is severely erroneous: see e.g.
>> <http://www.av8n.com/physics/uncertainty.htm>. However, Mathematica's
>> approximation of how these uncertainties propagate is first-order, =
not
>> zeroth-order. This does not make it completely reliable, of course, =
but
>> certainly it is not almost always wrong as is the significant digits
>> convention. Within the bounds of its own applicability, Mathematica's
>> approximation is reasonable, although it would still be a mistake to =
apply
>> it to experimental uncertainty analysis given the much broader scope =
of
>> the latter.
>>
>> Note the "first-order not zeroth-order". Also, do take a look at =
Sofroniou and Spaletta and then you may perhaps understand what "order" =
means and how "significance arithmetic" differs from the "significant =
digits" convention. Good grief, did you ever learn about the Taylor =
series? It must have been a long time ago, I take.
>>
>>
>> Andrzej Kozlowski
>>
>>
>> On 14 Jul 2011, at 19:55, Richard Fateman wrote:
>>
>>> On 7/14/2011 6:27 AM, Andrzej Kozlowski wrote:
>>>> On 14 Jul 2011, at 11:21, Richard Fateman wrote:
>>>>
>>>>> On 7/13/2011 12:11 AM, Noqsi wrote:
>>>>> ..
>>>>>
>>>>>>> see e.g.
>>>>>>> <http://www.av8n.com/physics/uncertainty.htm>.
>>>>> ..
>>>>> Learning mathematics from a physicist is hazardous.
>>>>> Learning computer science from a physicist is hazardous too.
>>>>> Numbers in a computer are different from experimental =
measurements.
>>>>>
>>>>>
>>>>> nevertheless, I like this article.  It says, among other things,
>>>>>
>>>>> 	The technique of propagating the uncertainty from step to step
>>>>> throughout the calculation is a very bad technique. It might =
sometimes
>>>>> work for super-simple =84textbook=89 problems but it is unlikely =
to work for
>>>>> real-world problems.
>>>>>
>>>> Well, here is a quote from a very well known book on numerical =
analysis by a mathematician (Henrici, "Elements of Numerical Analysis").
>>>>
>>>>
>>>>> It is plain that, on a given machine and for a given problem, the =
local
>>>>> rounding errors are not, in fact, random variables. If the same =
problem
>>>>> is run on the same machine a number of times, there will result =
always the
>>>>> same local rounding errors, and therefore also the same =
accumulated
>>>>> error. We may, however, adopt a stochastic model of the =
propagation of
>>>>> rounding error, where the local errors are treated as if they were =
random
>>>>> variables. This stochastic model has been applied in the =
literature to a
>>>>> number of different numerical problems and has produced results =
that are
>>>>> in complete agreement with experimentally observed results in =
several
>>>>> important cases.
>>>> The book then describes the statistical method of error propagation =
of which Mathematica's approach can be regarded as a first order =
approximation (as pointed out by Oleksandr Rasputinov, who should not be =
confused with the OP of this thread so:
>>> So are we to conclude that Henrici recommends this as a general  =
numerical computational method?
>>>
>>> I don't see that here.  I think what he is saying is that if you do =
some mathematics (see below), then
>>> you will get results consistent with what you will get if you =
actually run the experiment on the computer.
>>> This is not surprising. It is a result that says that "theoretical" =
numerical analysis agrees with
>>> "computer experiments" in arithmetic.  It doesn't say Henrici =
recommends running a computation this way.
>>>
>>> When Henrici says "adopt a stochastic model ...."  he doesn't mean =
to write a program. He means to
>>> think about each operation like this..  (I show for multiplication =
of numbers P and Q with errors a b resp.)
>>>
>>> P*(1+a)  times Q*(1+b)  = P*Q *(1+a)*(1+b)* (1+c)   where c is a =
new "error" bounded by roundoff, e.g. half unit in last place.
>>>
>>> For each operation in the calculation, make up another error =
letter...  a,b,c,d,e,f,g...
>>> assume they are uncorrelated.
>>>
>>> The fact that this theoretical approach and numerically running =
"several important cases" is a statement
>>> about correlation of roundoff in these cases, not a statement of =
advisability of whatever for a model of
>>> how to write a computer system.
>>>
>>> By the way, I think that Henrici was an extremely fine theoretical =
numerical analyst, and a fine writer too.
>>>
>>>
>>>
>>>>> Clearly Rasputinov thinks that if they are not equal they should =
not be
>>>>> Equal.  Thus the answer is False.
>>>>  is *clearly* False. In fact Oleksander expressed something closer =
to the opposite view.)
>>> This thread is too long.   I don't know at this point if you are =
agreeing that it is false or contradicting that "is False" is false.
>>>> And if one quote is not enough, here is another, from another text =
on numerical analysis. (Conte, de Boor, ""Elementary Numerical =
Analysis).
>>>> It describes 4 approaches to error analysis, interval arithmetic, =
significant-digit arithmetic, the "statistical approach" and backward =
error analysis. Here is what it says about the second and the third one:
>>> Huh, if we are talking about the second and third one, why does he =
say third and fourth?
>>> Are you using 0-based indexing and deBoor is using 1-based =
indexing????
>>>
>>>
>>>>> A third approach is significant-digit arithmetic. As pointed out =
earlier, whenever two nearly equal machine numbers are subtracted, there =
is a danger that some significant digits will be lost. In =
significant-digit arithmetic an attempt is made to keep track of digits =
so lost. In one version
>>>>> only the significant digits in any number are retained, all others =
being discarded. At the end of a computation we will thus be assured =
that all digits retained are significant. The main objection to this =
method is that some information is lost whenever digits are discarded, =
and that the results obtained are likely to be much too conservative. =
Experimentation with this technique is still going on, although the =
experience to date is not too promising.
>>>>>
>>> OK, so deBoor (who is retired and therefore not likely to revise the =
"experience to date")  says this method  "is not too promising".
>>> This sounds to me like he is not endorsing what Mathematica does.
>>>
>>>>> A fourth method which gives considerable promise of providing an =
adequate mathematical theory of round-off-error propagation is based on =
a statistical approach. It begins with the assumption that round-off =
errors are independent. This assumption is, of course, not valid, =
because if the same problem is run on the same machine several times, =
the answers will always be the same. We can, however, adopt a stochastic =
model of the propagation of round-off errors in which the local errors =
are treated as if they were random variables. Thus we can assume that =
the local round-off errors are either uniformly or normally distributed =
between their extreme values. Using statistical methods, we can then =
obtain the standard devia- tion, the variance of distribution, and =
estimates of the accumulated round- off error. The statistical approach =
is considered in some detail by Ham- ming [1] and Henrici [2]. The =
method does involve substantial analysis and additional computer time, =
but in the experiments conducted to date it has obtained error estimates =
which are in remarkable agreement with experimentally available =
evidence.
>>> deBoor is essentially quoting Henrici, and this statistical approach =
is to say that all those error terms I mentioned above,  a,b,c,d,e,f,...
>>> can be chosen from some distribution   (the way I've written it,  a =
,....,z ....   would essentially be chosen from {-u,u} where u = =
2^(-W) where the fraction part of the floating-point number is W bits.  =
)   and you can compute the final expression as =
ANSWER+<somehorrendousfunctionof>(a,b,c,....).
>>>
>>>  What deBoor says is that this (theoretical numerical analysis) =
"method" promises to provide
>>> a theory of round-off error propagation.   He is not saying this is =
a practical method for scientific computing.  When he uses the work =
"method"
>>> he means a mathematical method for analyzing roundoff.
>>>
>>> In any case, Mathematica does not do this.  I would further argue =
that Mathematica makes it hard to carry out the experiments that might =
be done to demonstrate that  this theory applied in any particular =
sample computation.
>>>> The fundamental paper of Mathematica's error propagation is =
"Precise numerical computation" by Mark Sofroniou and  Giulia Spaletta =
in The Journal of Logic and Algebraic Programming 64 (2005) 113=96134. =
This paper describes Mathematica's "significance arithmetic" as a first =
order approximation to Interval Arithmetic. It makes no mention of =
distributions.
>>> I thought I read this paper in some Mathematica documentation or =
conference proceedings.
>>>> Oleksandr Rasputionov, in an earlier post here, interpreted  =
"significance arithmetic" as a first order approximation to the fourth =
method above.
>>> Huh? First of all, the original poster was slawek.  Rasputinov seems =
to think that Mathematica numbers are like Intervals  (basically a good =
intuition until you think about equality.) and refers to them as =
distributions.  This is not deBoor's 4th "method" of theoretically =
analyzing round-off.
>>> In fact it is deBoor's 1st method, interval arithmetic.  This has =
the advantage of being maybe 4 to 8 times slower than regular =
arithmetic, and also has a huge literature  (see "Reliable Computation") =
describing variations, advantages, disadvantages, etc.
>>>
>>>>  I have not considered this very carefully, but it seems pretty =
clear that he is right, and that the two "first order" approximations =
are in fact isomorphic.
>>> Uh, this is unclear, unless you mean that Mathematica's number =
system is essentially interval arithmetic, but with a confusing front =
end.
>>>>  The first order approach is, of course, justified on grounds of =
performance. It is perfectly "rigorous" in the same sense as any "first =
order" approach is (i.e. taking a linear approximation to the Taylor =
series of a non-linear function). It works fine under certain conditions =
and will produce nonsense when these conditions do not hold.
>>>>
>>>> The fact that significance arithmetic is "useful" needs no =
justification other than the fact that it is used successfully by NSolve =
and Reduce in achieving validated symbolic results by numerical methods =
which are vastly faster than purely symbolic ones.
>>> Really?
>>>
>>> 1. This does not mean that other methods, e.g. validated methods for =
accurately evaluating polynomials (etc)  NOT based on significance =
arithmetic would not be faster and better.  DanL claims it is used and =
useful there, so that's nice.  BUT..
>>>
>>> 2. This does not mean that this arithmetic should be used by default =
by user arithmetic.
>>>> It is also useful, for users such as myself, who sometimes need =
fast first order error anlysis.
>>> OK, If you find it useful yourself, fine. I daresay you are not a =
typical user.
>>>
>>>> I have lots of posts by Richard on this topic (or perhaps it was =
the same post lots of time, it's so hard to tell), but I have never =
understood what his main point is.
>>> Main points:  Mathematica's number system is non-standard, peculiar, =
hard to explain,  capable of returning mysterious non-answers without =
indications of error to innocent users, a bad foundation for building =
higher-level functionality.
>>>
>>> I have other criticisms of Mathematica, but I think that the =
sentence above is enough for you to process today.
>>>
>>>>  It seems to me that is because he himself has not yet decided =
this, although he has been posting on this topic for over 20 years (I =
think).
>>>> Sometimes he seems to be disparaging significance arithmetic =
itself.
>>> I think deBoor did that.
>>>
>>>>  When Daniel points out how effective it is in his implementation =
of numerical Groebner basis, or in Adam Strzebonski's work on Reduce, he =
either ignores this altogether or claims that Groebner bases, etc.  are =
themselves not "useful".
>>> I think Reduce is a very nice program when it works. If I am not =
mistaken, all work on numerical Groebner basis should be reducible to =
the evaluation of polynomials, for which there are faster and more =
accurate methods available not using significance arithmetic.  On the =
other hand, I might be mischaracterizing DanL work, since I admit to not =
having studied it.
>>>
>>>
>>>> On other occasions he takes on the role of the defender of the =
interest of the "naive user" (presumably like the OP, who however would =
be better described as "intentionally naive") who is going to be =
confused by the "quirky" nature of significance arithmetic (at low =
precision).
>>> No, I don't think that slawek was a "troll".  I think he was =
genuinely confused, as might anyone be who has some prior computer =
arithmetic exposure and for the first time encounters a system with =
exact rational arithmetic.
>>>>  In doing so he conveniently ignores that fact of the existence of =
thousands of "naive users" who never become confused (sometimes because =
they always work with machine precision numbers and only use =
significance arrhythmic unknowingly, e.g. when using Reduce).
>>> Most naive users don't tread near the dangerous spots. Some naive =
users never notice that their answers are nonsense.
>>> Every so often we get a naive user who DOES notice, and he/she sends =
email to this newsgroup.
>>>>  And moreover, for those who do find a need for some sort of error =
analysis he offers no alternative, except perhaps to learn backward =
error analysis.
>>> Actually, there's a whole bunch of libraries of methods with error =
estimates for common computations, where backward error analysis or some =
other method was used to provide extra information.
>>>
>>>>  Except, of course, that should they do so they would no longer be =
"naive" and thus outside of Richard's area of concern.
>>> They would probably not be writing in Mathematica.
>>>> And in any case, anyone who needs and understands backward error =
analysis can use it now, and can't imagine that even Richard would claim =
that reducing users' options is a good thing.
>>> I have no problem with Mathematica providing as an option, some =
other arithmetic.  It is WRI that has made it rather hard for the user =
to
>>> figure out how to  "use the arithmetic of the rest of the world".
>>>
>>>> Finally, perhaps all that Richard is so upset about is simply =
Mathematica's habit of defining numbers as "fuzz balls" or =
"distributions".
>>> I'm not sure that "upset" is the right term.  After all, I don't =
have to use Mathematica for numerical computation. And I rarely do.
>>>> In other words, if Mathematica used a more usual "definition" of =
number, and used significance arithmetic for "error" propagation, that =
would be done by applying some separate function or turning on an =
option,  than everything would be fine?
>>> Actually, that's pretty close to correct.
>>>> If that is all, than it seems to me that Richard has for years been =
making mountains of molehills.
>>> So why are you (and WRI)  so opposed to this notion?  Note that it =
would also have to affect other parts of the system including of course,
>>> Equal and friends.
>>>
>>>
>>>> Andrzej Kozlowski
>>>>
>>>>
>>>>
>>>>
>>>
>
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.soft-sys.math.mathematica

csiph-web