How to increase Working Precision?
Paul J Salmon
I hope this is the best medium (I tried another newgroup, but the
message has not appeared).
I wish to perform a number of calculations but need about 25 digits of
precision
I can use WorkingPrecision
http://reference.wolfram.com/mathematica/ref/WorkingPrecision.html
to increase the precision of some numerical operations, but how can I
perform all calculations to 25 digits and display all 25? So for
example if I enter
[In 1] Pi + 2.0
it returns
5.141592653589793238462643
rather than 5.14159
Nasser Abbasi
"Paul J Salmon" <paulj...@yahoo.com> wrote in message
news:8b028ca7-4e58-4167...@e6g2000prf.googlegroups.com...
(I do not understand your input above, the [Ln 1]? )
Any way, I am no expert on this subject of Mathematica, but I think you can
tell Mathematica what your desired precision on an overall computation by
wrapping the whole expression with the function SetPrecision[] (see help on
this function).
http://reference.wolfram.com/mathematica/ref/SetPrecision.html
(from the above it says
"yields a version of expr in which all numbers have been set to have
precision p."
so may be this is what you want)
Nasser
rjf
> "Paul J Salmon" <pauljsal...@yahoo.com> wrote in messagenews:8b028ca7-4e58-4167...@e6g2000prf.googlegroups.com...
2.0 is low precision. try N[Pi+2,1000]. You could try reading the
manual.
Nasser Abbasi
"rjf" <fat...@gmail.com> wrote in message
news:c742b996-12f0-471a...@s13g2000prd.googlegroups.com...
Using N[] that way seems to be the same as using SetPrecision:
In[43]:= r = N[Pi + 2, 1000];
Precision[r]
Out[44]= 1000.
In[45]:= r = SetPrecision[Pi + 2, 1000];
Precision[r]
Out[46]= 1000.
What exactly is the difference you show by using N[] vs. SetPrecision[] as I
said?
Nasser
sashap
> "rjf" <fate...@gmail.com> wrote in message
Try
In[63]:= Zeta[18, 3]
Out[63]= -(262145/262144) + (43867 \[Pi]^18)/38979295480125
In[64]:= SetPrecision[%, 25]
Out[64]= 2.59599937483986*10^-9
In[65]:= N[%%, 25]
Out[65]= 2.595999374839856461644622*10^-9
you could see that N internally increased settings of SetPrecision
so that the result was correct to 25 requested digits:
In[67]:= SetPrecision[-(262145/262144) + (43867 \[Pi]^18)/
38979295480125, 35]
Out[67]= 2.595999374839856461644622*10^-9
Hope this helps,
Oleksandr Pavlyk
Wolfram Research
rjf
difference between the Mathematica notions of precision and accuracy.
A very precise value for pi is 3.15000000000000000000000000000000
which happens not to be very accurate.
In fact the notions of Precision and Accuracy in Mathematica are, in
my opinion, rather bogus. Numerical analysts have the well-defined
notions of relative and absolute error, as well as precision. These
do not correspond to Mathermatica.
ma...@wolfram.com
> Again, I suggest you read the manual, and in particular note the
> difference between the Mathematica notions of precision and accuracy.
>
> A very precise value for pi is 3.15000000000000000000000000000000
> which happens not to be very accurate.
x has a small relative error (high precision)
In[1]:= x = 3.15000000000000000000000000000000;
In[2]:= Precision[x]
Out[2]= 32.4983
But it is not a good approximation to Pi, as you can
see by subtraction:
In[3]:= d = x - Pi
Out[3]= 0.0084073464102067615373566167205
In[4]:= Precision[d]
Out[4]= 29.9247
The difference in Precision between x and d indicates that
only about 2 of the displayed digits are close to Pi.
Regarding the original question, I'm unable to reproduce the
behaviour.
Here is the result from all versions back as far as Version 4.2
on a 32 bit Linux machine.
In[1]:= Pi + 2.0
Out[1]= 5.14159
In[2]:= MachineNumberQ[%]
Out[2]= True
If you instead meant that you want all results to a fixed Precision
of 25 digits then this can be accomplished as follows:
In[1]:= Block[{$MinPrecision = 25, $MaxPrecision = 25},
x = 2.`25;
Pi + x
]
Out[1]= 5.141592653589793238462643
Note in particular that x must be defined as a software float:
x = SetPrecision[2, 25];
x = 2.`25;
etc
and not:
x = 2.
which is a machine precision number.
Mark Sofroniou
Wolfram Research
m...@inbox.ru
Yes they do. Take
In[1]:= x = 3.15000000000000000000000000000000
It has 32 digits after the decimal point, so the absolute error is
taken to be 10^-32 (closeness to Pi is irrelevant here). Then Accuracy/
Precision equals minus decimal logarithm of the absolute/relative
error:
In[2]:= Accuracy[x] == -Log[10, 10^-32]
Out[2]= True
In[3]:= Precision[x] == -Log[10, 10^-32/Abs[x]]
Out[3]= True
Maxim Rytin
m...@inbox.ru
Christopher Creutzig
> x has a small relative error (high precision)
>
> In[1]:= x = 3.15000000000000000000000000000000;
>
> In[2]:= Precision[x]
>
> Out[2]= 32.4983
Sorry, but the standard notion of “relative error” is always “relative
to the exact result approximated.” As an approximation to pi, x has a
relative error of 0.0027, which is not all that small. The relative
error of a number does not change in the least when you add more zeroes
at the end, after the decimal point. Actually, in standard notation,
3.15000000000000000000000000000000 is exactly the same number as 3.15.
At least in pure math. A subset of engineers disagrees, of course, as do
most programs having multi-precision floats, and for good reason.
--
if all this stuff was simple, we'd
probably be doing something else. -- Daniel Lichtblau, s.m.symbolic
rjf
absolute error of a result is the (absolute value) of the difference
between the result and the correct value. The number of decimal or
binary places used to represent the result is something else.
The notions of relative error and absolute error, as well as
precision, should be defined in any text on numerical analysis.
Mathematica's notions of Precision and Accuracy are not found in
contemporary NA books; they are related to significance arithmetic, no
longer in use except in Mathematica.
Why?
I came across this .. http://www.av8n.com/physics/uncertainty.htm#sec-abomination
which might be of some interest.
The point is, "ambiguity is not an advantage".
RJF
Daniel Lichtblau
> Just to add to C Creutzig's note; it should be clear that the
> absolute error of a result is the (absolute value) of the difference
> between the result and the correct value. The number of decimal or
> binary places used to represent the result is something else.
I think we are all in vehement agreement that
3.15000000000000000000000000000000
is fairly a precise number, but one which is not terribly accurate as
an estimate of pi.
> The notions of relative error and absolute error, as well as
> precision, should be defined in any text on numerical analysis.
>
> Mathematica's notions of Precision and Accuracy are not found in
> contemporary NA books; they are related to significance arithmetic, no
> longer in use except in Mathematica.
> Why?
Why is significance arithmetic used in Mathematica?
Because we find that it works quite well. Most or all of bignum
Mathematica code is written to use this underlying arithmetic. To
change that model would incur a considerable burden of code overhaul,
with no gain that I can discern.
If you are asking why significance arithmetic is not used elsewhere, I
can point out that it takes serious code infrastructure to work in
anything approaching a full-fledged manner. I guess I can also note
that I am not certain it is unused elswhere; I can only say I am
unaware of other such usage.
To refine a statement you make, Mathematica's Precision and Accuracy
are features of a number, corresponding approximately to number of
digits and number of digits to right of radix. How they change, and
more generally, how error propagates in Mathematica arithmetic, is a
feature of significance arithmetic. I think textbooks tend to
associate precision/accuracy with computations rather than with
numbers. But I do not see a profound inconsistency in using these
notions on numbers themselves.
> I came across this ..http://www.av8n.com/physics/uncertainty.htm#sec-abomination
> which might be of some interest.
>
> The point is, "ambiguity is not an advantage".
>
> RJF
I'll show some Mathematica code and results to emulate that example.
Significance arithmetic gives what I claim to be quite reasonable
results.
The example involves finding the quotient 10.065/9.95. I will first
indicate what interval arithmetic has to say. We are to assume all
values in the example above are correct to the last shown digit; the
intervals below are formulated with that in mind.
e1 = 10065/1000;
e2 = 995/100;
ee1 = e1 + Interval[{-5/10000, 5/10000}];
ee2 = e2 + Interval[{-5/1000, 5/1000}];
The interval values are as we expect.
In[182]:= N[{ee1, ee2}]
Out[182]= {Interval[{10.0645, 10.0655}], Interval[{9.945, 9.955}]}
So let's take a look at the quotient.
In[183]:= int = ee1/ee2;
N[int]
Out[184]= Interval[{1.011, 1.01212}]
Now we do similarly but with significance arithmetic. First I show the
numbers we will use.
In[185]:= {10.065`5, 9.95`3}
Out[185]= {10.065, 9.95}
Here is the quotient, both as it displays and in Mathematica's
InputForm.
In[186]:= quot = 10.065`5/9.95`3;
{quot, InputForm[quot]}
Out[187]= {1.01, 1.0115577889447236183`2.9956786262173565}
We see that around three digits are "correct", and this agrees quite
well with the interval analysis (which indicates fairly clearly that
the next digit is not known).
Notice we have, to small precision, an idea of how far the result is
from the exact 101/100:
In[190]:= InputForm[quot-101/100]
Out[190]//InputForm=
0.0015577889447236183`0.1831965451629747
As best I can tell, significance arithmetic is giving a perfectly good
result.
Daniel Lichtblau
Wolfram Research
mcmc...@unca.edu
> Mathematica's notions of Precision and Accuracy are
> not found in contemporary NA books; they are related
> to significance arithmetic
Richard,
You've been criticizing significance arithmetic since
at least your very detailed review of 1990. I don't
really care to join that debate, as I'm not a numerical
analyst. Given that at least two teams with perfect
scores in Trefethen's SIAM 100 digit challenge used
Mathematica exclusively, I'll go ahead and assume that
Mathematica's numerics aren't terrible. (Incidentally,
the second of Trefethen's challenge problems most
definitely required the use of high-precision
arithmetic.)
There is one point I'd like to make however. Most of
your writings on significance arithmetic include
examples where the user enters a number as a very long
string of digits or iterates a function many times or
performs some such trick to trigger Mathematica's
arbitrary precision routines, evidently baffling the
confused user. Here's the thing, though: I've been
teaching undergraduate students to solve numerical
problems in calculus, differential equations, linear
algebra, and more recently numerical analysis using
Mathematica since version 1.2 and I don't believe I've
ever seen the types of problems you describe arise in
that setting.
That's not to say that these problems can't arise in
that setting but it's easy to see why they would be
rare. The simple fact of the matter is that exact
computations (like (Pi^2)/6) or machine precision
computations (like (Pi^2.0)/6.0) are simply much more
common. High precision computation is typically used
when one needs, well, high precision. It's not
unreasonable to expect a bit more of the user at that
point. As even you admit in your posts to this group
on July 12 of 2007, significance arithmetic "isn't an
entirely silly idea" in that context.
I wouldn't say that your complaints are completely
baseless. Personally, I'd like the user to be
able to control when arbitrary precision kicks in.
But I find your overall arguments against significance
arithmetic and indeed against Mathematica in general
to be uncompelling.
Mark
rjf
> There is one point I'd like to make however. Most of
> your writings on significance arithmetic include
> examples where the user enters a number as a very long
> string of digits or iterates a function many times or
> performs some such trick to trigger Mathematica's
> arbitrary precision routines, evidently baffling the...
In freshman physics class I learned to do signficance arithmetic when
combining measurements done with a meter stick, a thermometer, and
other inherently low precision devices. Maybe two adds and a
multiply, and you get an answer whose number of digits is
appropriate; you get penalized on the lab if you write down too many
digits. That is probably what you have observed with your calculus
(or other) undergraduate students.
If CAS are to be used for long sequences of calculations typical of
some kinds of scientific calculation, which are, I contend, more like
the iterations I've suggested than the 1-2 or 3 arithmetic ops I've
done in physics labs, then the arithmetic must be appropriate for such
calculations. That's where we disagree on what is appropriate.
As far as providing adequate arithmetic for Trefethen's challenges, I
suspect it is an additional credit to the providers of solutions in
Mathematica that they were not tripped up by Mathematica's
arithmetic; of course exact rational arithmetic is unaffected by the
issues here.
Furthermore I should point out that it is not impossible to simulate
better arithmetic in Mathematica: after each relevant arithmetic
operation one can re-set the accuracy of the result. This is the way
one can induce a convergent iterative process to converge when it
otherwise would not, using Mathematica. Thus anything that can be
phrased as a fixed-point problem or root-finding can be fed into a
clever program that resets accuracy, which presumably clever people
(like Dan L) would do, but J. Random User would not. Which is why
significance arithmetic is , in my view, hazardous for J. Random User.
RJF
mcmc...@unca.edu
> As far as providing adequate arithmetic for Trefethen's
> challenges, I suspect it is an additional credit to the
> providers of solutions in Mathematica that they were
> not tripped up by Mathematica's arithmetic;
On the contrary, this goes straight to my main point.
Nine of the ten Trefethen challenge problems require
only machine precision in the solution; the need for
arbitrary precision in applied situations is quite
rare in practice. You can look through Stan Wagon's
solutions:
http://stanwagon.com/wagon/Misc/SIAMchallenge.html
On several of the problems he used WorkingPrecision
option of NDSolve in a second, check solution or to
obtain even more digits than requested. On only one
problem (#2) was arbitrary precision required to get
the correct solution. That particular problem
involved a photon bouncing off a succession of circular
mirrors; a small error accumulates with each reflection.
Stan solved the problem by simply starting with high
precision input and allowing Mathematica's significance
arithmetic to keep track of the Precision. Via
experimentation, he discovered that a starting
Precision of 50 was sufficient to guarantee a 10
correct digits at the finish. I think this is
exactly what we want significance arithmetic to do.
> If CAS are to be used for long sequences of
> calculations typical of some kinds of scientific
> calculation, which are, I contend, more like the
> iterations I've suggested than the 1-2 or 3 arithmetic
> ops I've done in physics labs, then the arithmetic must
> be appropriate for such calculations.
You can iterate the logistic function a million times
if you want. If you start with a machine number, all
subsequent computations will be done in machine
arithmetic; you might as well be using Matlab or C.
High precision has nothing to do with it. Of course,
the results are completely meaningless after 50
iterations or so, since you lose about one bit of
Precision with each step. If you first set the
Precision of the starting point, you'll find that
Mathematica correctly deduces that fewer and fewer
digits of the result are correct.
Now, depending on the function, it certainly can happen
that high precision kicks in. I don't particularly
care for this feature and I suspect that you would
agree. Here's one of my least favorite examples:
f = Compile[x, x^2];
Precision /@ NestList[f, 2.0, 12]
In this example, the first 9 results are machine
precision numbers. Subsequent terms are larger
than $MaxMachineNumber on my 32 bit machine.
Mathematica automatically switches to arbitrary
precision to evaluate the result. Now, why
would I go to the trouble to use Compile, if I
wanted to use arbitrary precision? I would prefer
to catch an error and deal with the problem on my
own.
I think we disagree on the big picture. I find
the above example to be a small annoyance in what
is a very large and generally outstanding system.
Mark
rjf
> On Mar 9, 6:23 pm, rjf <fate...@gmail.com> wrote:
>
> > As far as providing adequate arithmetic for Trefethen's
> > challenges, I suspect it is an additional credit to the
> > providers of solutions in Mathematica that they were
> > not tripped up by Mathematica's arithmetic;
>
> On the contrary, this goes straight to my main point.
> Nine of the ten Trefethen challenge problems require
> only machine precision in the solution; the need for
> arbitrary precision in applied situations is quite
> rare in practice.
I had misremembered the challenge -- I thought it was to get 100
digits of the solution,
not 10 problems, each 10 digits.
The need for arbitrary precision is, I agree, unusual in current
scientific computing practice. And so the need for Mathematica's
arithmetic -- other than ordinary machine arithmetic -- is rare. It
is, of course, a problem doing certain kinds of mathematics with
floats -- exact rationals are sometimes required. Wolfram's first
foray into computer algebra system building, SMP, made the substantial
mistake of approximating rationals with floats, and printing as though
they were rationals. That is, 1/3 was converted to 0.333333...4
but was printed as 1/3. Taylor series with exact coefficients could
not be believed.
So if you and the solvers are simply touting their own cleverness plus
the machine-arithmetic subroutine library of Mathematica, it doesn't
say much about significance arithmetic.
> You can look through Stan Wagon's
> solutions:http://stanwagon.com/wagon/Misc/SIAMchallenge.html
>
> On several of the problems he used WorkingPrecision
> option of NDSolve in a second, check solution or to
> obtain even more digits than requested. On only one
> problem (#2) was arbitrary precision required to get
> the correct solution. That particular problem
> involved a photon bouncing off a succession of circular
> mirrors; a small error accumulates with each reflection.
> Stan solved the problem by simply starting with high
> precision input and allowing Mathematica's significance
> arithmetic to keep track of the Precision. Via
> experimentation, he discovered that a starting
> Precision of 50 was sufficient to guarantee a 10
> correct digits at the finish. I think this is
> exactly what we want significance arithmetic to do.
Well, if he had NOT had significance arithmetic, he could have done
the problem a certain number of times with increasing initial
precision, ( a heuristic recommended to me was to use N digits then N
+sqrt(N), etc) and when two (or maybe more) successive answers were
the same to 10 digits, he could stop.
Now which method would be faster? I would expect the significance
arithmetic would be slower both because each arithmetic operation
would be cluttered with extra computation, and also because the
significance arithmetic, if done "correctly" would be somewhat
pessimistic about how many digits are right, so perhaps more trials
would be needed.
I think you miss the point. When an iteration (say a Newton-like
iteration) is programmed using ordinary arithmetic, there is a chance
that it will converge when the Mathematica significance version will
not. You do not need some kind of diabolical computation to make
Mathematica fail. You need to be keenly aware of Mathematica's
arithmetic to prevent some (not all) iterations from going awry -- by
erasing all significance erroneously. You have to reset Accuracy "by
hand".
>
> I think we disagree on the big picture. I find
> the above example to be a small annoyance in what
> is a very large and generally outstanding system.
A large system that messes up arithmetic?
RJF
>
> Mark
Dave
>> [In 1] Pi + 2.0
>>
>> it returns
>>
>> 5.141592653589793238462643
>>
>> rather than 5.14159
>
> (I do not understand your input above, the [Ln 1]? )
I suspect he means:
In[1]:=
which is the standard prompt.
> Any way, I am no expert on this subject of Mathematica, but I think you can
> tell Mathematica what your desired precision on an overall computation by
> wrapping the whole expression with the function SetPrecision[] (see help on
> this function).
>
> http://reference.wolfram.com/mathematica/ref/SetPrecision.html
>
> (from the above it says
>
> "yields a version of expr in which all numbers have been set to have
> precision p."
>
> so may be this is what you want)
>
>
> Nasser
Whilst that works, it is a pain if one wanted to do a lot of
calculations like this. Do you know if there is any way to set a *whole
notebook* so that all computations are done with x significant digits (x
> machine precision)?
The fact the original poster said he wanted to "perform a number of
calculations but need about 25 digits of precision" suggests to it would
be preferable if a whole notebook could be done with 25 digits.
Slightly related, does Mathematica support the use of less than machine
precision floats? There might be odd instances where one wishes to see
the effect of using lower precision. For example, whether one could save
memory in a C program by using floats rather than doubles. I've in the
past needed to approximate floats with rational numbers to implement
filters on processors without floating point support. I would accept the
instances where one wants < machine precision are rare, but if the
Mathematica code could do it, it might just be useful, even if it is
slow (which it would be I suspect, as it would have to do the
calculations in software).
rjf
....
. Do you know if there is any way to set a *whole
> notebook* so that all computations are done with x significant digits (x
> > machine precision)?
You mean YOU want to determine how many digits are significant? My
reaction:
Mathematica's significance arithmetic determines that, and if you want
to
disagree, you must change the Accuracy of the result after each
operation.
Perhaps a rule like
a_+b_:=SetAccuracy[a+b,Q] /;..suitable conditions on a and b
etc for other arithmetic.
Maybe someone at WRI could find a neater way.
>
> The fact the original poster said he wanted to "perform a number of
> calculations but need about 25 digits of precision" suggests to it would
> be preferable if a whole notebook could be done with 25 digits.
>
> Slightly related, does Mathematica support the use of less than machine
> precision floats?
I think you could use rationals and Chop, but perhaps explicitly
setting Precision.
Why don't you borrow a copy of Mathematica and try these things out
instead of asking?
RJF
Daniel Lichtblau
> [...]
> Whilst that works, it is a pain if one wanted to do a lot of
> calculations like this. Do you know if there is any way to set a *whole
> notebook* so that all computations are done with x significant digits (x
> > machine precision)?
Pretty much as Mark Sofroniou noted, for n digit fixed precision
arithmetic you can do
$MinPrecision = n;
$MaxPrecision = n;
The same caveat as Mark mentioned will apply: you need to input your
values using software floats.
> The fact the original poster said he wanted to "perform a number of
> calculations but need about 25 digits of precision" suggests to it would
> be preferable if a whole notebook could be done with 25 digits.
>
> Slightly related, does Mathematica support the use of less than machine
> precision floats?
As above, with n < $MachinePrecision.
> There might be odd instances where one wishes to see
> the effect of using lower precision. For example, whether one could save
> memory in a C program by using floats rather than doubles. I've in the
> past needed to approximate floats with rational numbers to implement
> filters on processors without floating point support. I would accept the
> instances where one wants < machine precision are rare, but if the
> Mathematica code could do it, it might just be useful, even if it is
> slow (which it would be I suspect, as it would have to do the
> calculations in software).
Correct, it would be slow relative to machine arithmetic.
Daniel Lichtblau
Wolfram Research
Daniel Lichtblau
> On Mar 9, 5:41 pm, mcmcc...@unca.edu wrote:
>
> > On Mar 9, 6:23 pm, rjf <fate...@gmail.com> wrote:
>
> > > As far as providing adequate arithmetic for Trefethen's
> > > challenges, I suspect it is an additional credit to the
> > > providers of solutions in Mathematica that they were
> > > not tripped up by Mathematica's arithmetic;
>
> > On the contrary, this goes straight to my main point.
> > Nine of the ten Trefethen challenge problems require
> > only machine precision in the solution; the need for
> > arbitrary precision in applied situations is quite
> > rare in practice.
>
> I had misremembered the challenge -- I thought it was to get 100
> digits of the solution,
> not 10 problems, each 10 digits.
People have done these problems to 100 and more digits. Actually I
think all but one have been done to 10,000 digits.
Problem 2 benefits nicely from significance arithmetic.
Problem 7, if done with a conjugate gradient solver, will benefit from
fixed precision. A few of the others (6,8,10) can also be approached
via linear algebra solvers and, when done in that way, are probably
better off using fixed precision. But frankly I'd be surprised if any
of them can be solved to more than a few dozen correct digits via
numerical linear algebra.
Problem 4 solutions can be verified via interval arithmetic. Offhand I
am not certain whether such a verification can be attempted using
significance arithmetic. I am quite sure fixed precision would be
helpless here.
> The need for arbitrary precision is, I agree, unusual in current
> scientific computing practice. And so the need for Mathematica's
> arithmetic -- other than ordinary machine arithmetic -- is rare. It
> is, of course, a problem doing certain kinds of mathematics with
> floats -- exact rationals are sometimes required[...]
> So if you and the solvers are simply touting their own cleverness plus
> the machine-arithmetic subroutine library of Mathematica, it doesn't
> say much about significance arithmetic.
When going to higher precision, some of the software assistance of
importance is in numerical evaluation of various special functions to
high precision. This does not involve significance arithmetic per se,
but rather the capability to obtain correct high precision results
from such evaluations. One might attempt this using fixed precision
code, along with the tactic you espouse (below), of raising precision
and checking for stabilization of digits. This usually works (though
there are interesting, if pathological, counterexamples in the
literature). But if Mathematica is used directly, internal algorithms
that use precision ratcheting and various expansions tend to be quite
reliable, at least for those special function evaluations required to
do several of the Trefethen's SIAM challenge problems to high
recision. I regard these methods of function evaluation to be an
extension of significance arithmetic; I will grant you that is simply
an opinion.
This sort of computation tends not to be terribly pessimistic. I'm not
sure the speed hit for significance arithmetic was terribly high
either. (I have seen computations where I believe it is high, but this
was not one of them.)
> > [...]
> > Now, depending on the function, it certainly can happen
> > that high precision kicks in. I don't particularly
> > care for this feature and I suspect that you would
> > agree. Here's one of my least favorite examples:
> > f = Compile[x, x^2];
> > Precision /@ NestList[f, 2.0, 12]
>
> > In this example, the first 9 results are machine
> > precision numbers. Subsequent terms are larger
> > than $MaxMachineNumber on my 32 bit machine.
> > Mathematica automatically switches to arbitrary
> > precision to evaluate the result. Now, why
> > would I go to the trouble to use Compile, if I
> > wanted to use arbitrary precision? I would prefer
> > to catch an error and deal with the problem on my
> > own.
I will point out (you both probably realize this) that the issue here
is unrelated to use of significance arithmetic. It is a part of the
effort to have "seamless" arithmetic, so when machine arithmetic fails
Mathematica resorts to arbitrary precision.
The fact that significance arithmetic is used for the arbitrary
precision computations could be viewed as a further degradation of
what the user wants. One sees this effect in the gradual lowering of
precision in the last few results of that NestList. As I imagine you
both realize, tehre are fairly straightforward workarounds. But I
agree there may be cases where the automatic behavior is not to
everyone's liking.
> I think you miss the point. When an iteration (say a Newton-like
> iteration) is programmed using ordinary arithmetic, there is a chance
> that it will converge when the Mathematica significance version will
> not. You do not need some kind of diabolical computation to make
> Mathematica fail. You need to be keenly aware of Mathematica's
> arithmetic to prevent some (not all) iterations from going awry -- by
> erasing all significance erroneously. You have to reset Accuracy "by
> hand".
I assume by "ordinary" you mean fixed precision, that is, no error
tracking. Yes, there are iterations where resetting precision, or use
of a fixed precision block, as pointed out a few notes back in this
thread, is required. I will say that I do not run across them too
often, but then I tend not to get the most hard core of numerical
programming queries.
> > I think we disagree on the big picture. I find
> > the above example to be a small annoyance in what
> > is a very large and generally outstanding system.
>
> A large system that messes up arithmetic?
>
> RJF
Ummmm, that last would be an opinion, no? I really do not think you
have presented a case whereby everyone will automatically agree with
that assessment.
Daniel Lichtblau
Wolfram Research
Richard J. Fateman
>
>
>>> (Dave) I think we disagree on the big picture. I find
>>> the above example to be a small annoyance in what
>>> is a very large and generally outstanding system.
>> (RJF) A large system that messes up arithmetic?
>
> (DanL)Ummmm, that last would be an opinion, no? I really do not think you
> have presented a case whereby everyone will automatically agree with
> that assessment.
I don't get credit for letting "generally outstanding" slip by?
Why I think I am entitled to my opinion:
Certainly a system that provides a scientific library in which any
expression can be evaluated to any requested accuracy would be very nice.
Even a system that does this for many or "most" expressions would be
nice. (Mathematica, I think, claims to fit here)
For readers of this newsgroup who might not know the history of my
stated concern, let me point out that in Mathematica it is possible to
produce something that looks like 0. but acts quite strangely. This
object can be produced as the result of a long (or perhaps short)
computation, or you can create it directly by r=SetAccuracy[1.0,0].
r has the property that it prints as 0.
r has the property that r+1 also prints as 0.
r has the property that r+1 == r evaluates as True.
There are many more properties that anyone with a copy of the program
can explore. Like r is a solution to the equation sin(x)=cos(x).
It is too easy for a number like r to be produced by a naive user, or
even a sophisticated one who doesn't understand the arithmetic.
Herman Rubin
>> There is one point I'd like to make however. Most of
>> your writings on significance arithmetic include
>> examples where the user enters a number as a very long
>> string of digits or iterates a function many times or
>> performs some such trick to trigger Mathematica's
>> arbitrary precision routines, evidently baffling the...
I consider using data precision to be generally
poor; the accuracy of the result may well be
far beyond what will be available if the
intermediate steps are calculated to a fixed
precision.
In doing numerical analysis, it is necessary
to consider the source of temporary values.
Yes, there may be procedures to reduce this
problem, but often not.
>In freshman physics class I learned to do signficance arithmetic when
>combining measurements done with a meter stick, a thermometer, and
>other inherently low precision devices. Maybe two adds and a
>multiply, and you get an answer whose number of digits is
>appropriate; you get penalized on the lab if you write down too many
>digits. That is probably what you have observed with your calculus
>(or other) undergraduate students.
The raw data may not be worth too many digits, but
often not including a few more than expected may
be a poor idea. When it comes to the calculations,
all such bets are off; analyze first.
>If CAS are to be used for long sequences of calculations typical of
>some kinds of scientific calculation, which are, I contend, more like
>the iterations I've suggested than the 1-2 or 3 arithmetic ops I've
>done in physics labs, then the arithmetic must be appropriate for such
>calculations. That's where we disagree on what is appropriate.
What is appropriate is what is appropriate. Do
not try to give fixed rules.
>As far as providing adequate arithmetic for Trefethen's challenges, I
>suspect it is an additional credit to the providers of solutions in
>Mathematica that they were not tripped up by Mathematica's
>arithmetic; of course exact rational arithmetic is unaffected by the
>issues here.
> Furthermore I should point out that it is not impossible to simulate
>better arithmetic in Mathematica: after each relevant arithmetic
>operation one can re-set the accuracy of the result. This is the way
>one can induce a convergent iterative process to converge when it
>otherwise would not, using Mathematica. Thus anything that can be
>phrased as a fixed-point problem or root-finding can be fed into a
>clever program that resets accuracy, which presumably clever people
>(like Dan L) would do, but J. Random User would not. Which is why
>significance arithmetic is , in my view, hazardous for J. Random User.
Agreed.
>RJF
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hru...@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558
Herman Rubin
>> As far as providing adequate arithmetic for Trefethen's
>> challenges, I suspect it is an additional credit to the
>> providers of solutions in Mathematica that they were
>> not tripped up by Mathematica's arithmetic;
>On the contrary, this goes straight to my main point.
>Nine of the ten Trefethen challenge problems require
>only machine precision in the solution; the need for
>arbitrary precision in applied situations is quite
>rare in practice. You can look through Stan Wagon's
>solutions:
>http://stanwagon.com/wagon/Misc/SIAMchallenge.html
For "arbitrary", I will generally, but not always,
agree. There are many problems where I conjecture
that three times the desired precision in the result
will be adequate in the calculations, but poor
conditioning, which is unavoidable, may make this
not enough. In situations in which one makes
statistical tests, a few more digits than the
results are good for is useful.
Herman Rubin
>>> it returns
>>> 5.141592653589793238462643
>>> rather than 5.14159
>I suspect he means:
>In[1]:=
>> http://reference.wolfram.com/mathematica/ref/SetPrecision.html
>> Nasser
This used to be possible in machine arithmetic on machines
which did not have separate integer and float registers.
I recall an old talk in which, to get an idea of the
accuracy of results, they were computed using the full
accuracy of the machine, one less bit, two less bits,
and some more, and using this to estimate the accuracy.
Alas, today's machines are difficult to use for
multiple precision "floats". Separate integer
and floating registers and forced normalization
are the sources of this problem.
Christopher Creutzig
> r has the property that it prints as 0.
> r has the property that r+1 also prints as 0.
> r has the property that r+1 == r evaluates as True.
> There are many more properties that anyone with a copy of the program
> can explore. Like r is a solution to the equation sin(x)=cos(x).
>
> It is too easy for a number like r to be produced by a naive user, or
> even a sophisticated one who doesn't understand the arithmetic.
While I don't agree with (most of) your earlier critique in this
thread, this one I feel genuine. (I regard testing for equality on
floats in general a user error, but the behavior of Mathematica when the
user does so anyway is one of the points where I regard the design of
the system to be completely off mark. Then again, in the end, it boils
down to a clear specification, although I still find it makes putting
floating point numbers into generic code (which usually handles just
about anything except floats properly) and either being lucky and
getting an obviously false result or an error or being unlucky and
having the same thing appear only at your customer all too easy.
Equality should be just that, and different floats simply are not equal,
even if they only disagree in a guard digit.
Daniel Lichtblau
wrote:
> Daniel Lichtblau wrote:
>
> >>> (Dave) I think we disagree on the big picture. I find
> >>> the above example to be a small annoyance in what
> >>> is a very large and generally outstanding system.
> >> (RJF) A large system that messes up arithmetic?
(I think it was actually Mark M. who wrote that bit about the "big
picture".)
> > (DanL)Ummmm, that last would be an opinion, no? I really do not think you
> > have presented a case whereby everyone will automatically agree with
> > that assessment.
>
> I don't get credit for letting "generally outstanding" slip by?
Yeah, you get some. That is to say, I agree with Mark that it is a
generally outstanding program, but also recognize I don't get to claim
that as a fact.
> Why I think I am entitled to my opinion:
>
> Certainly a system that provides a scientific library in which any
> expression can be evaluated to any requested accuracy would be very nice.
>
> Even a system that does this for many or "most" expressions would be
> nice. (Mathematica, I think, claims to fit here)
>
> For readers of this newsgroup who might not know the history of my
> stated concern, let me point out that in Mathematica it is possible to
> produce something that looks like 0. but acts quite strangely. This
> object can be produced as the result of a long (or perhaps short)
> computation, or you can create it directly by r=SetAccuracy[1.0,0].
>
> r has the property that it prints as 0.
> r has the property that r+1 also prints as 0.
> r has the property that r+1 == r evaluates as True.
> There are many more properties that anyone with a copy of the program
> can explore. Like r is a solution to the equation sin(x)=cos(x).
>
> It is too easy for a number like r to be produced by a naive user, or
> even a sophisticated one who doesn't understand the arithmetic.
This raises some reasonable points.
I am happy and surprised to notice there are at least a few people
giving this thread some serious reading. So I thought I would say a
bit more about this issue you raise. For one, some people may be
unfamiliar with what you mean. I also think it would be useful to show
a bit of how this arithmetic is functioning (or disfunctioning,
depending on your take).
We'll go back to the example from a few notes ago.
http://groups.google.com/group/sci.math.symbolic/msg/e0b31cb1a4c085b2
I'll skip the interval computations and get to the main part. The gist
was to investigate the quotient of 10.065, with five digits "correct",
and 9.95, with three correct digits.
In[1]:= quot = 10.065`5/9.95`3;
In[2]:= {quot, InputForm[quot]}
Out[2]= {1.01, 1.0115577889447236183`2.9956786262173565}
To repeat from that other post, we have 1.01 to about three digits
precision. So what does this have to do with those zeros you mention?
Well, let's subtract various values that one might claim to be the
quotient, and thereby produce some zeros.
In[4]:= diff = quot-101/100;
In[5]:= {diff,InputForm[diff]}
-2
Out[5]= {0. 10 , 0.0015577889447236183`0.1831965451629747}
Is it really zero? Well, no, not quite. It printed as zero because it
is deemed to have too little precision to print otherwise
(specifically, what would one print? There is not enough precision to
be certain of even one digit.) Let's go for a "closer" approximation.
In[6]:= diff2 = quot-1011/1000;
In[7]:= {diff2,InputForm[diff2]}
-2
Out[7]= {0. 10 , 0``2.9906879277383736}
At this point we have no significant bits, just a zero to three digits
accuracy.
What about adding things and getting no change? Here is an example of
that. We'll add 1/1000, a value smaller than the accuracy of our zero,
and see that it remains zero.
In[13]:= sum1 = 1/1000+diff2;
In[14]:= {sum1,InputForm[sum1]}
-2
Out[14]= {0. 10 , 0``2.9906879277383736}
Whether this is good or bad behavior probably depends on ones
perspective. I think it is the right result.
Let's move up a bit. We'll add 1/100 to that zero.
In[16]:= {sum2,InputForm[sum2]}
-2
Out[16]= {0. 10 , 0.01`0.9906879277383746}
Still prints as a zero, but actually it seems to be 1/100, to almost
one digit of precision. Indeed, if we instead had added 1/99, we'd see
that digit printed without recourse to InputForm.
In[17]:= 1/99+diff2
Out[17]= 0.01
Me, I think it would have been better had sum2 printed like this. But
that is something of a formatting issue as opposed to a math issue.
What matters from the latter perspective is the underlying value, and
how it combines with other values in arithmetic. Let's add another
1/1000.
In[19]:= sum2plus = sum2+1/1000;
In[20]:= {sum2plus,InputForm[sum2plus]}
Out[20]= {0.01, 0.011`1.0320806128965996}
So we get that first digit printed in the default output format, and
we see that we have that last 1/1000 tucked away inside.
Now sum2, while formatted (in OutputForm) the same as diff2, is by no
means equal to it.
In[21]:= sum2==diff2
Out[21]= False
But it is deemed equal to sum2plus, because that last 1/1000 is not
appearing as significant.
In[22]:= sum2==sum2plus
Out[22]= True
To understand this in detail one would need to see the underlying
representation of the two values. NumericalMath`$NumberBits will give
us the lsit of "known" (or "good") bits, the bits we have stored but
that are not deemed significant ("bad" bits, or guard bits if you
prefer), and the exponent of the first significant bit. We see that
the two values that were deemed equal have the same good bits.
In[27]:= NumericalMath`$NumberBits[sum2]
Out[27]= {1, {1, 0, 1}, {0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 0,
0, 0,
1, 0, 1, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 0, 0, 0, 1, 0,
1, 0,
0, 0, 1, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 0}, -6}
In[28]:= NumericalMath`$NumberBits[sum2plus]
Out[28]= {1, {1, 0, 1}, {1, 0, 1, 0, 0, 0, 0, 1, 1, 1, 0, 0, 1, 0, 1,
0, 1,
1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 1,
0, 0,
1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0}, -6}
I will reiterate that I think this handling is all quite reasonable (I
realize we do not have consensus here); moreover I find it to be
fairly useful. Possibly all the more as Wolfram Research expands the
curated data collection introduced in version 6, since a significant
portion of it involves physical constants known only to modest
precision. That is to say, I think it is helpful to know when
computations with such values might have stopped being meaningful
because all precision was lost.
Daniel Lichtblau
Wolfram Research
G. A. Edgar
Christopher Creutzig <chris...@creutzig.de> wrote:
> I regard testing for equality on
> floats in general a user error
It follows that 0^0.0 should not be simplified to 1.0
Even if 0^0 *is* simplified to 1
--
G. A. Edgar http://www.math.ohio-state.edu/~edgar/
Christopher Creutzig
> In article <47d9a9b1$0$6735$9b4e...@newsspool3.arcor-online.net>,
> Christopher Creutzig <chris...@creutzig.de> wrote:
>
>> I regard testing for equality on
>> floats in general a user error
>
> It follows that 0^0.0 should not be simplified to 1.0
> Even if 0^0 *is* simplified to 1
>
Good point, but I did leave the gap of “in general.” I'll have to think
about this point more thoroughly (and won't be near Usenet for a couple
of days).
Martin Rubey
> G. A. Edgar wrote:
> > In article <47d9a9b1$0$6735$9b4e...@newsspool3.arcor-online.net>,
> > Christopher Creutzig <chris...@creutzig.de> wrote:
> >
> >> I regard testing for equality on
> >> floats in general a user error
> >
> > It follows that 0^0.0 should not be simplified to 1.0
> > Even if 0^0 *is* simplified to 1
> >
GCL (GNU Common Lisp) 2.6.8 CLtL1 Mar 12 2008 11:26:34
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
openServer result 0
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-02-09
Timestamp: Wednesday March 12, 2008 at 11:31:13
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
(1) -> )se me au of
(1) -> 0^0
(1) 1
Type: PositiveInteger
(2) -> 0^0.0
>> Error detected within library code:
0**0 is undefined
(2) -> 0.0^0
(2) 1.0
Type: Float
Martin
Christopher Creutzig
> In article <47d9a9b1$0$6735$9b4e...@newsspool3.arcor-online.net>,
> Christopher Creutzig <chris...@creutzig.de> wrote:
>
>> I regard testing for equality on
>> floats in general a user error
>
> It follows that 0^0.0 should not be simplified to 1.0
> Even if 0^0 *is* simplified to 1
Yes and no. There *are* floats which are identical. After all, we would
not want an object o for which o == o was false. (In terms of numerical
analysis, I have to admit I disagree with IEEE for NaN here.) This is
why I said “in general”. But I would only want this simplification for
an exponent that is *exactly* a floating point zero.
It is, in my opinion, acceptable (though certainly not the preferred
way) to use something like s == s+t as a stopping condition when summing
up a series of decreasing numbers numerically. but I only have
experience with multi-precision numerics in terms of fixed precision, I
never worked with significance arithmetics myself. What I regard as
problematic, however, is to have two objects o1 and o2 which some system
claims to be identical, yet invoking some function such as SetPrecision
with exactly the same parameters on them results in two definitely
different objects.
Christopher Creutzig
> In[4]:= diff = quot-101/100;
>
> In[5]:= {diff,InputForm[diff]}
> -2
> Out[5]= {0. 10 , 0.0015577889447236183`0.1831965451629747}
>
> Is it really zero? Well, no, not quite. It printed as zero because it
> is deemed to have too little precision to print otherwise
Why is printing a zero then better than printing a 1, 42, or just about
anything else? If it is deemed to have too little precision to be
printed as 1, shouldn't it be deemed to have too little precision to be
printed as 0, as well? Shouldn't it print some form of “don't know”
instead, say, question marks? After all, “relative error” is usually
much more important (and, I believe, much closer to significance) than
“absolute error” and therefore, printing a zero should require much more
confidence in actually seeing a zero (because the relative error would
otherwise be extremely huge) than printing just about any other value.
> What about adding things and getting no change? Here is an example of
Happens with floats all the time. Take some huge value. Adding a small
value, such as 1, an arbitrary number of times won't change the value.
(I know this reads a bit different from my point expressed yesterday. I
guess what I'm questioning mostly is to have floating point values with
essentially no bit of precision and allow calculations with these. Does
Mathematica have an option to abort a computation with an error if this
occurs?)
Christopher Creutzig
> (I know this reads a bit different from my point expressed yesterday. I
> guess what I'm questioning mostly is to have floating point values with
> essentially no bit of precision and allow calculations with these. Does
Sorry to follow up on myself: Setting $MinPrecision to some positive
value would stop that from happening, right?
Daniel Lichtblau
wrote:
> G. A. Edgar wrote:
> > In article <47d9a9b1$0$6735$9b4e6...@newsspool3.arcor-online.net>,
> > Christopher Creutzig <christop...@creutzig.de> wrote:
>
> >> I regard testing for equality on
> >> floats in general a user error
>
> > It follows that 0^0.0 should not be simplified to 1.0
> > Even if 0^0 *is* simplified to 1
>
> Yes and no. There *are* floats which are identical. After all, we would
> not want an object o for which o == o was false. (In terms of numerical
> analysis, I have to admit I disagree with IEEE for NaN here.) This is
> why I said "in general". But I would only want this simplification for
> an exponent that is *exactly* a floating point zero.
It might be my general conditioning, but I'd also not want to see
0^0.0 to be 1.0 or anything other than either unevaluated or a flavor
of NaN. I have the impression there is agreement on this, even if we
might come to the conclusion for different reasons.
> It is, in my opinion, acceptable (though certainly not the preferred
> way) to use something like s == s+t as a stopping condition when summing
> up a series of decreasing numbers numerically. but I only have
> experience with multi-precision numerics in terms of fixed precision, I
> never worked with significance arithmetics myself. What I regard as
> problematic, however, is to have two objects o1 and o2 which some system
> claims to be identical, yet invoking some function such as SetPrecision
> with exactly the same parameters on them results in two definitely
> different objects.
>
> --
> if all this stuff was simple, we'd
> probably be doing something else. -- Daniel Lichtblau, s.m.symbolic
I'm not convinced this is a bad thing, so much as a bad usage of
SetPrecision (in Mathematica; I suspect there are similar functions in
other programs). What it can do is to expose guard bits, in the sense
of claiming "regard these bad bits as good bits". Returning to the
example I have used:
diff = quot-101/100;
diff2 = quot-1011/1000;
I had inadvertantly forgotten to display this next one.
sum2 = 1/100+diff2;
sum2plus = sum2+1/1000;
In[27]:= sum2plus==sum2
Out[27]= True
Next we see an example of the phenomenon you mention.
In[28]:= SetPrecision[sum2plus,5] == SetPrecision[sum2,5]
Out[28]= False
But these new objects really ARE different, because we promoted bad
bits to become good bits.
In[29]:= InputForm[{SetPrecision[sum2,5],SetPrecision[sum2plus,5]}]
Out[29]//InputForm= {0.01`5., 0.011`5.}
I do not see the behavior as wrong, so much as a problematic (and, I
hope, unlikely) usage of SetPrecision.
Daniel Lichtblau
Wolfram Research
Daniel Lichtblau
wrote:
Depends on what you have in mind. It would force usage of fixed
precision once a computation's precision hit the low water mark. So
you would not be computing with values that have no precision. But you
would also have jettisoned significance arithmetic in this situation,
so the "significance" Mathematica was attaching to the numbers would
not correspond to any actual error aproximation.
For some purposes, e.g. the sort of convergent iterative computations
that Richard Fateman has mentioned, I'd think this is a good thing.
For other purposes, e.g. (approximate) zero recognition, it would
generally be bad.
Daniel Lichtblau
Wolfram Research
Daniel Lichtblau
wrote:
> Daniel Lichtblau wrote:
> > In[4]:= diff = quot-101/100;
>
> > In[5]:= {diff,InputForm[diff]}
> > -2
> > Out[5]= {0. 10 , 0.0015577889447236183`0.1831965451629747}
>
> > Is it really zero? Well, no, not quite. It printed as zero because it
> > is deemed to have too little precision to print otherwise
>
> Why is printing a zero then better than printing a 1, 42, or just about
> anything else? If it is deemed to have too little precision to be
> printed as 1, shouldn't it be deemed to have too little precision to be
> printed as 0, as well? Shouldn't it print some form of "don't know"
> instead, say, question marks?
I prefer the current status (discounting borderline cases where maybe
a digit could/should be regarded as "known"). What it says, in effect,
is "your number is zero to xxx many decimal places).
> After all, "relative error" is usually
> much more important (and, I believe, much closer to significance) than
> "absolute error"
Well, usually more important: I'm not so sure about that "much more".
Yes, relative error corresponds to significance and absolute error
does not.
> and therefore, printing a zero should require much more
> confidence in actually seeing a zero (because the relative error would
> otherwise be extremely huge) than printing just about any other value.
I find accuracy to be useful information, particularly in this
situation where precision is either miniscule or nonexistent (and so
relative error is large or infinite). The notation of zero to some
power conveys that (approximated) accuracy. When the power is a large
negative, that's usually a good thing (assuming you wanted to get
zero). When positive, that tells you maybe your computation got into
trouble. Again, often this is useful information.
> > What about adding things and getting no change? Here is an example of
>
> Happens with floats all the time. Take some huge value. Adding a small
> value, such as 1, an arbitrary number of times won't change the value.
> (I know this reads a bit different from my point expressed yesterday. I
> guess what I'm questioning mostly is to have floating point values with
> essentially no bit of precision and allow calculations with these. Does
> Mathematica have an option to abort a computation with an error if this
> occurs?)
[Somehow I cannot bring myself to place a response right above that
signature line...]
> --
> if all this stuff was simple, we'd
> probably be doing something else. -- Daniel Lichtblau, s.m.symbolic
I do not know of a one-size-fits-all option. A typical way to handle
this situation is to write code that checks the precision, and aborts
when it gets below some threshold. The internal GroebnerBasis code
does this, when working with finite precision coefficients.
Daniel Lichtblau
Wolfram Research
Christopher Creutzig
> I'm not convinced this is a bad thing, so much as a bad usage of
> SetPrecision (in Mathematica; I suspect there are similar functions in
> other programs). What it can do is to expose guard bits, in the sense
> of claiming "regard these bad bits as good bits". Returning to the
When writing some iterative numerical method, where you know that the
iteration converges, but significance arithmetics won't be able to
detect this fact (*), you'd use SetPrecision to tell the system to
regard those bits as good, or do I miss something again? That would lead
to a genuine usage of that function where it would cause things like o1
== o2, yet f(o1) != f(o2), as I mentioned.
(*) This is not a critique on significance arithmetics. It has been a
rather long time until interval numerical analysts found out why some of
the rather basic linear algebra algorithms actually return much more
precise results than could be expected from analyzing individual steps.
This is even true for non-iterative algorithms such as Gaussian
elimination. I would expect direct application of significance
arithmetics to yield equally pessimistic estimates for the result precision.
> In[28]:= SetPrecision[sum2plus,5] == SetPrecision[sum2,5]
> Out[28]= False
>
> But these new objects really ARE different, because we promoted bad
> bits to become good bits.
And, in my interpretation, that implies that the old objects are
different, too. After all, there is a way to tell them apart. But I
realize that different programming languages have different operators
for equality, equivalence, identity, etc.
Daniel Lichtblau
wrote:
> Daniel Lichtblau wrote:
> > I'm not convinced this is a bad thing, so much as a bad usage of
> > SetPrecision (in Mathematica; I suspect there are similar functions in
> > other programs). What it can do is to expose guard bits, in the sense
> > of claiming "regard these bad bits as good bits". Returning to the
>
> When writing some iterative numerical method, where you know that the
> iteration converges, but significance arithmetics won't be able to
> detect this fact (*), you'd use SetPrecision to tell the system to
> regard those bits as good, or do I miss something again?
Correct, in Mathematica one would typically use SetPrecision if coding
an algorithm with some a priori known rate of convergence (linear or
quadratic, say). I think something similar would be done in other
languages as well. For languages that work in fixed precision (I think
this means all computational math programs other than Mathematica, at
least for default behavior) this might be done simply by interjecting
code to raise the internal "working precision"
> That would lead
> to a genuine usage of that function where it would cause things like o1
> == o2, yet f(o1) != f(o2), as I mentioned.
Yes, I guess this can happen in legitimate usage, more or less. But I
think typically one would, at the finish of an iterative algorithm,
use some method to adjust and perhaps slightly downgrade final
precision.
So yes, you can have o1==o2 and f(o1)!=f(o2), and I suspect this can
happen without any interjection of SetPrecision. But this is sort of
independent of handling of convergent iterative algorithms. And at the
end of the day, what you want from such an algorithm is some idea of
what are the significant digits in the result. The fact that you might
have a "nearby" number that looks like yours, but disagrees when
evaluated by your function of interest, is, I think not so serious a
matter. We might be in disagreement on this. I suspect we at least
agree it is a "finer" point and takes a back seat to getting the
result to some desired precision.
> (*) This is not a critique on significance arithmetics. It has been a
> rather long time until interval numerical analysts found out why some of
> the rather basic linear algebra algorithms actually return much more
> precise results than could be expected from analyzing individual steps.
> This is even true for non-iterative algorithms such as Gaussian
> elimination. I would expect direct application of significance
> arithmetics to yield equally pessimistic estimates for the result precision.
Yes indeed, at least for Gaussian elimination with partial pivoting. I
tried this in the Mathematica kernel, back around 1994. I quickly went
back to fixed precision with error approximation based on condition
number. Significance arithmetic was woefully too conservative a model/
tactic for (over)estimating error.
This is one reason I have not been too eager to get Mathematica's
symbolic/exact Gaussian elimination to work too hard on matrices with
intervals. I believe the pivot selection currently in place at least
attempts to enforce that pivots not be intervals containing zero. But
I do not think we try to do anything tantamount to partial pivoting
(with intervals, I'd imagine such a pivot selection would then be
based on smallest relative error rather than largest magnitude,
amongst contending matrix entries).
> > In[28]:= SetPrecision[sum2plus,5] == SetPrecision[sum2,5]
> > Out[28]= False
>
> > But these new objects really ARE different, because we promoted bad
> > bits to become good bits.
>
> And, in my interpretation, that implies that the old objects are
> different, too. After all, there is a way to tell them apart. But I
> realize that different programming languages have different operators
> for equality, equivalence, identity, etc.
Yes to all this. Mathematica has a fuzzy equality and also enforces
trichotomy, that is to say, we cannot have x<y and x==y
simultaneously. I am sure this makes for pathological examples. I do
not see a way around this; we all must pick from amongst imperfect
scenarios.
> --
> if all this stuff was simple, we'd
> probably be doing something else. -- Daniel Lichtblau, s.m.symbolic
Daniel Lichtblau
Wolfram Research