# Tag Info

30

The first example seems to intentionally set Mathematica up to "fail" by specifying insufficient input accuracy. With additional precision: ClearAll[s] s[i_] := s[i] = 2*s[i - 1] - 3*s[i - 1]^2 s[0] = 0.330; s[40] 0.333333 And Mathematica is capable of far greater precision if necessary: ClearAll[s] $RecursionLimit = ∞ s[i_] := s[i] = 2*s[i - 1] - ... 21 Without commenting on how much attention one should pay to marketing literature: the second example is somewhat relevant. Mathematica's polynomial factoring algorithm is known to be at least fifteen years behind the state of the art, and things that Maple will factor in seconds will go away (literally) forever in Mathematica. This is, of course, not too ... 20 The critical issue in the first example is that Mathematica is using significance arithmetic to track precision. This is certainly billed as a feature by Wolfram Research. As we see in this example though, it can be portrayed as a weakness. In truth, you might need to know what you're doing to use it correctly. In this answer, I mentioned that significance ... 11 You can see how accurate a number is represented using the Accuracy[] function. For the OPs example: a = N[Sqrt[2], 20]; {Accuracy[a], Accuracy[a^2], Accuracy[N[a^2,100]]} {19.8495, 19.3979, 19.3979} Hence, when printing out N[a^2,100], only the first 20 (or so) digits are significant and are printed. This is also true in general, for example: b = ... 10 You can compare the precision empirically: prec[f_, x_] := Abs[SetPrecision[f[x], 30] - f[SetPrecision[x, 30]]]/ Abs@f[SetPrecision[x, 30]]; LogPlot[{prec[f, x],$MachineEpsilon}, {x, -10, 10}] LogPlot[{prec[g, x], $MachineEpsilon}, {x, -10, 10}] So g has better numerical precision (around$MachineEpsilon). It is because f contains the ...

10

As was pointed out above, this is a good summary of Mathematica's constrained optimization methods. Read through this if you want to know a lot more. A quick answer is below: The answer to your question is strongly dependent on the function you want to maximize. Convex functions can be maximized quite easily, with the error controlled by the PrecisionGoal ...

8

ybeltukov showed empirically that $g(x)$ is numerically more precise than $f(x)$, despite the two expressions being formally mathematically equal. Why is this the case? In your original question, you guessed that If you could explain why, that would really help me out, I have a feeling it's f(x) as there isn't a denominator but I'm not 100% certain. ...

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

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 ...

7

If you look at the documentation for Precision, it says that if x is the value and dx the "absolute uncertainty", Precision[x] is -Log[10,dx/x]. This, whenever the estimated error is larger than the value, Mathematica will give a negative precision. Thus, for an estimated error $dx$ and a value $x$ such that $dx/x<1$ here is how the precision as defined ...

6

To make the result of NSum more precise you can use also the NSumTerms option (15 by default, see e.g. Numerical Evaluation of Sums and Products) appropriately increased. Let's try e.g. : a1 = NSum[ HarmonicNumber[2 m]/m^3, {m, 1, Infinity}, WorkingPrecision -> 140, PrecisionGoal -> 70, NSumTerms -> 2000] ...

5

Try the following, N[NestList[Cos, 15/10, 10], 10] {* {1.500000000,0.07073720167,0.9974991672,0.5424049923,0.8564697089,0.6551088018, 0.7929816458,0.7017241683,0.7637303113,0.7222610821,0.7503128857} *} SetAccuracy[NestList[Cos, 1.5, 10], 10]; SetPrecision[NestList[Cos, 1.5, 10], 10]; NumberForm[NestList[Cos, 1.5, 10], {10, 10}] {* ...

5

Thanks for the report, @rasher. This was a bug and it is already fixed in the development version. In[1]:= Table[intleg = tleg/2; sa = SparseArray[{{i_, i_} :> 1 - (intleg - i + 1)/tleg, {i_, j_} /; j == i + 1 :> (1 - i + intleg)/tleg}, {intleg + 1, intleg + 1}]; saN = N[sa, 50]; mp = DiscreteMarkovProcess[1, sa]; mpN = ...

5

The problem has to do with the sample points used to contruct the plot, and not with NDSolve. Mathematica automatically subdivides segments when the angle is greater than some limit, but it will do so only MaxRecursion times. One can increase PlotPoints to increase the number of initial sample points and increase MaxRecursion to let Mathematica subdivide ...

5

I would say that the answer to the first question is, no, if Mathematica does not give any errors when evaluating an expression, then we cannot be absolutely certain that its answer is reliable up to a decent precision. This is shown in the section Examples of Pathological Behavior in the tutorial NIntegrate Integration Rules. Given that the previous ...

5

Gamma is an extremely quickly increasing function, so you're dealing with the ratio of huge numbers here. Something similar to catastrophic cancellation can happen. Fortunately, Mathematica is very good at dealing with this situation if you let it use arbitrary precision instead of machine precision. Change 0.5 to 1/2 and add something like ...

5

While @Szabolcs has provided the correct work-around, the actual issue has to do with automatic use of Compile for function evaluation. The affected range is such that the value of Gamma[1+n] is still a machine real, but their product is out-of-bound. The issue comes, because the default setting of Compile's RuntimeOptions is to tolerate machine arithmetic ...

4

Numerical integration in Mma is a big topic. I suggest reading at least this. The following gives the correct answer: NExpectation[(-(x*y) + z^2) Boole[x*y - z^2 <= 0], {x, z, y} \[Distributed] MultinormalDistribution[{0, 0, 0}, {{3/8, 0, 1/8}, {0, 1/8, 0}, {1/8, 0, 3/8}}], Method -> {"NIntegrate", {Exclusions -> True}}]

4

If you Rationalize all your finite precision numbers and add WorkingPrecision -> 50 to FindRoot the messages go away. For example: /. {Mn -> Rationalize[0.08], cn -> Rationalize[0.25]} and: Table[Vnuc[x, y, 0] + Vdisk[x, y, 0] + Vbar[1, Rationalize[0.1], 7, Rationalize[1.5], Rationalize[0.6], x, y, 0], {x, -10, 10, 1/2}, {y, -10, 10, ...

4

Is the following a better result? (I'm not an expert.) Block[{\$MaxExtraPrecision = 100}, N[-PolyLog[5/2, -E^500], 20] ] (* Out: 1.6821298518320559359*10^6 + 0.*10^-14 I *)

4

FractionalPart@N[Sqrt[2], 7] 10^7 // Round (* 4142136*)

3

Simply increase PlotPoints: Plot[Cos[.3 x] Exp[-0.01 x], {x, 0, 1000}, PlotRange -> {{300, 500}, {-0.05, 0.05}}, ImageSize -> 600, PlotPoints -> 2000] Increasing PlotPoints would also draw a smooth ellipse in your orbit example

3

Please first take a look at http://reference.wolfram.com/language/tutorial/ExactAndApproximateResults.html Eigenvalues uses entirely different methods when working with exact or inexact quantities. mat = {{1, 1/2, 4}, {2, 1, 2}, {1/4, 1/2, 1}}; First notice that the eigenvalues are the same and returned in the same order in the two cases: ...

3

Arbitrary precision can be a tricky thing, particularly when you start to mix numbers at various levels of precision. As the was pointed out in the comments, if you mix quantities Mathematica will coerce the results to be of the lower precision. For example: {Sin[Pi/4], Sin[0.25 Pi]} (* Out: {1/Sqrt[2], 0.707107} *) Note that Sin[Pi/4] returns the ...

3

Regarding your last question: in the docs for FindRoot it says that FindRoot continues until either of the goals specified by AccuracyGoal or PrecisionGoal is achieved. The same thing is mentioned in the docs for NMinimize. On the other hand, the docs for NDSolve say AccuracyGoal effectively specifies the absolute local error allowed at each ...

3

Initially I forgot to specifically address Manipulate. In addition to this post see also: Manipulating an arbitrary-precision ContourPlot This question may qualify as a duplicate (I'll let the community votes decide) but it has been asked in a different way so I'll answer it anew. There are two issues that may be confounded here: input syntax and ...

3

A way to work with RealDigits, if desired: Drop @@ RealDigits[Round[Sqrt[2], 1*^-7]] // FromDigits 4142136

2

Clearly, you can factor out the tiny portion of your constant, so: NSum[1/Pochhammer[m^2 + 1, 2 m], {m, 1, ∞}, WorkingPrecision -> 50] 1*^-26 1.6726218229590580987863882056891582636342622102204*10^-27 OTOH, ...products of all the numbers between consecutive squares. Product[j, {j, (k - 1)^2, k^2}] Pochhammer[(-1 + k)^2, 2 k] This doesn't ...

2

The comments by image_doctor led me to the answer I was looking for: StandardForm@NumberForm[1.2, {20, 4}, ExponentFunction -> (Null &)] (* 1.2000 *) StandardForm@NumberForm[1., {20, 4}, ExponentFunction -> (Null &)] (* 1.0000 *) StandardForm@NumberForm[0.2, {20, 4}, ExponentFunction -> (Null &)] (* 0.2000 *) StandardForm@NumberForm[0., ...

2

Might want to have a look at the InputForm of these. SetAccuracy[0., 5] // InputForm (*Out[38]//InputForm = 05.*) SetAccuracy[1.2, 5] // InputForm (*Out[39]//InputForm=1.199999999999999955591079014993738383055.079181246047625*) I doubt either gives the behavior you are after. As was suggested in a comment, maybe NumberForm or PaddedForm will meet ...

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