# Tag Info

53

Control the Precision and Accuracy of Numerical Results This is an excellent question. Of course everyone could claim highest accuracy for her product. To deal with this situation there exist benchmarks to test for accuracy. One such benchmark is from NIST. This specific benchmark deals with the accuracy of statistical software for instance. The NIST ...

21

What is wrong: a) you're using exact arithmetic. b) You keep iterating even if the point seems to be escaping. Try this ClearAll@prodOrb; prodOrb[c_, maxIters_: 100, escapeRadius_: 1] := NestWhileList[#^2 + c &, 0., Abs[#] < escapeRadius &, 1, maxIters ] prodOrb[0. + 10. I] prodOrb[0. + .1 I] (if you don't need the entire list but ...

16

Just a bit of fun with @acl's code: ArrayPlot[Table[ NestWhile[#^2 - (0. - 1 I) & , r + i I, Abs[#] < 2.0 &, 1, 10], {r, -2, 2, 0.005}, {i, -2, 2, 0.005}]]

13

This is how you manually invoke "LevinRule" when you know part of the integrand is a rapidly oscillatory function satisfying a linear ODE: First, a rapidly oscillatory function: In[25]:= osc = y /. NDSolve[{y''[x] - (x^2 - 3 x) y'[x] + 10000 y[x] == 0, y[0] == 3, y'[0] == 1}, y, {x, 0, 5}] // First Out[25]= InterpolatingFunction[{{0.,5.}},<>]...

13

The documentation states: N does not raise the precision of approximate numbers in its input 163.0 (or 163., or 163) is a machine precision number, and Mathematica will not fake a higher precision when a certain number of digits are requested with N. See this answer and this tutorial for more. These questions may also be of interest: Converting to ...

13

N does not round numbers or truncate them. The internal forms of N[Pi, 1] // FullForm N[Pi, 2] // FullForm are respectively (* 3.14159265358979323846264338327950288421. 3.14159265358979323846264338327950288422. *) Note that the numerical values are identical although the precisions differ. Their difference is zero and all significant digits ...

13

Numerics in Mathematica can be as precise as you like. However, precision comes at price; you pay for it in computation time and in additional coding effort. In Mathematica there are several computational classes of non-complex numbers, which form a tree like this. The computation you made was made with machine reals because you included 0.5 as a term. ...

12

Setting the Method option to "CofactorExpansion" results in the correct output. mat = {{2, 2.161209223472559 + 1.682941969615793 I}, {2.161209223472559 - 1.682941969615793 I, 2}} Inverse[mat, Method -> "CofactorExpansion"] $\$ {{-0.57092 + 0. I, 0.616939 + 0.480412 I}, {0.616939 - 0.480412 I, -0.57092 + 0. I}} As you want to perform ...

11

This is rather basic ,but since it helped you, I´ll post the answer and leave it to the other users to judge. The second argument to Chop (see Details section) defines the magnitude below which values will be replaced by 0. l = {{0.217548, -0.217548, -0.0373272, -9.83823*10^-18, \ -8.13807*10^-19}, {0.217548, 0.217548, 0.0373272, 7.54332*10^-18, 6....

9

With a compiled version you get it so fast, that you can manipulate it in real time. fc = Compile[{{in, _Complex, 0}, {c, _Complex, 0}}, Module[{iter = 0, max = 10, z = in}, While[iter++ < max, If[Abs[z = z^2 + c] > 2.0, Break[] ] ]; {Abs[z], iter} ], CompilationTarget -> "C", Parallelization -> True, ...

9

You can also use Threshold: l = {{0.217548, -0.217548, -0.0373272, -9.83823*10^-18, -8.13807*10^-19}, {0.217548, 0.217548, 0.0373272, 7.54332*10^-18, 6.23849*10^-19}, {0.183095, 0.0504041, 0.00207916, -0.214279, -0.0218996}, {0.985472, -0.193791, -0.461242, 4.17611*10^-20, 1.22184*10^-20}, {0.985472, 0.193791, 0.461242, -1.18329*10^-...

9

Mathematica does not, by default, act like most calculators that will spew out digits in a result whether or not they are "valid" or "real" digits. In most modes of usage, Mathematica keeps track of the precision of inputs, intermediate calculations, etc. and attempts to return results where the digits are correct, accurate, and "justified", that is, given ...

9

A nice trick to force Mathematica to use a given precision is to use Block and make $MinPrecision equal to$MaxPrecision. So you can write your result1 as: Block[{$MinPrecision = 10,$MaxPrecision = 10}, FixedPointList[N[1/2 Sqrt[10 - #^3] &, 10], 1.510]] {1.500000000, 1.286953768, 1.402540804, 1.345458374, 1.375170253, 1.360094193, 1....

9

I'll mimic the precision/accuracy handling for FindRoot as indicated in its documentation: The default settings for AccuracyGoal and PrecisionGoal are WorkingPrecision/2. The setting for AccuracyGoal specifies the number of digits of accuracy to seek in both the value of the position of the root, and the value of the function at the root. The ...

9

First, in general, I would advise you not to trust numerical algorithms. If there are doubts about the outcomes then solve the same problem with different (numerical or not) methods and see do their results agree. For the integral in the question I assume you can evaluate it with several different invocations of the Monte Carlo method and compare the ...

8

The problem is that the precision of a and b are set by the form of their input. a = 1234567891234567889998.5; b = 1234567891234567889999.5; Precision[a] 22.0915 And 0.5 by default has MachinePrecision, these days typically Log10[2^53] or just under 16 digits. Precision[0.5] MachinePrecision Neither setting the precision of 0.5 to 200 or ...

8

As @acl mentioned in chat, your question really indicates that you should read some fundamental sources. Two that I'd recommend are: A First Course in Chaotic Dynamical Systems by Bob Devaney for a good overview of the mathematical theory. Mathematica in Action by Stan Wagon, specifically Chapter 11, for a more condensed overview but with specific ...

8

This question probably will not receive a "real" answer because it is based on a misconception about what $MachineEpsilon actually is. But, since the question is upvoted, I suppose there is more than one person who is not yet clear on how this is defined. Therefore, here is a comment to try to clarify the definition and tie up the loose ends of the thread. ... 8 I think your problems are made by order of appling Re and N. Re@Bloch is not yet a state before the computation. So you have to apply the computation by Re@Norder. Block[{$MaxExtraPrecision = 500, ϵ = 10^-10}, Re@N@BlochΚ[-2 + ϵ, -1, -10]] Block[{$MaxExtraPrecision = 1000, ϵ = 10^-20}, Re@N@BlochΚ[-2 + ϵ, -1, -10]] Block[{$MaxExtraPrecision = 500, ϵ = 10^-...

8

According to Precision, the precision of a number x with absolute uncertainty dx is p -> -Log10[dx / x]. Conversely the uncertainty is given by dx -> x * 10^-p. For a calculation f[x, y, ...], the precision is estimated by Dt[f[x, y, ...] / f[x, y, ...], where Dt[x] represents the uncertainty of x and so on for any other variables. I'll show that ...

8

In V10 there has been added some symbolic processing of integrands containing an InterpolatingFunction. In particular if the interpolation grid divides the domain of integration into a number of subintervals, the number being at most the value of the option "MaxSubregions", the integrand will automatically be integrated over each subinterval. In V9, this is ...

8

I urge you not to use the answer you have been given, because it adds spurious precision (hence incorrect digits) to the result, which will be more obvious if you attempt to use a higher precision. The result you have is already precise (albeit not necessarily accurate) up to 15 digits; it's just that the front end won't display all of the digits by default,...

8

The loss of precision of this function by itself seems to be fairly modest: the big problem comes from the huge integers produced when expanding it. You can see that more clearly by changing the function to be tail recursive (so that larger values of n will be accessible without blowing the stack): ClearAll[z2]; z2[result_: 0, n_Integer, c_] := z2[result^2 +...

7

NumberForm can be used to control the number of decimal places. Plot[0, {x, 8.5, 9.3}, PlotRange -> {{7.9, 11}, {0, 0}}, Axes -> {True, False}, Ticks -> {({#, NumberForm[N@#, {Infinity, 1}]} & /@ Range[0, 11, 1/5]), {}}, PlotStyle -> {Red, Thickness[0.02]}]

7

This question feels familiar but I could not find a true duplicate. You can use the string replacement that Oleksandr proposed here and then use ToExpression to convert the numbers: string = "-5.100686209408900133332e+02 -1.294005398404007344443e+01 \ -2.59376479781563728887e-02 -1.3043629998334040122222e+02" ToExpression /@ StringReplace[StringSplit@...

7

Mathematica arrives at the particular precision that it does using significance arithmetic and associated propagation of precision. This answer describes how to double check that. Oleksandr's answer makes a good case for the assertion that significance arithmetic is insufficient for this problem as it fails to account for the correlation in error between ...

7

Update: I think this is a numeric precision problem rather than a matter of the behavior of Re. I don't know if I should leave my original answer below for reference or remove it. Consider: expr = MathieuC[MathieuCharacteristicA[-(19999999999/10000000000), -2], -2, 5]; N[expr] N[expr, 15] SetPrecision[expr, 15] -9.85323*10^-16 + 3.39211*10^-8 I -0....

7

If you wish to compute the correct values using the method you have chosen you could specify Method -> "Procedural" for Sum: CumDigitSum[x_, b_] := Sum[DigitSum[n, b], {n, 1, x}, Method -> "Procedural"] CumDigitSum[1000001, 10] 27000003 However, the problem comes form the fact that Sum attempts to speed the calculation by finding a symbolic ...

7

You can disable error tracking as below (effectively working in fixed precision). range = N[Range[0, 2 Pi - 0.0000001, 2 Pi/8192],20]; FFT[f_, wf_, range_] := Mean[Exp[I*(f - 1)*range]*(wf /@ range)]; Block[{$MinPrecision = 20,$MaxPrecision = 20}, FFT[#, wf, range] & /@ {257, 513} ] (* Out[360]= {-5.7615176179584663593*10^-40 + 0....

7

\$MachinePrecision is different from MachinePrecision. The former calls for an arbitrary precision calcluation, done at the same precision as the machine-precision one. The main reason one would want to use this is to enable precision tracking, which is absent for a true machine-precision calculation using MachinePrecision. And, there is your answer. ...

Only top voted, non community-wiki answers of a minimum length are eligible