# Why this weird return value from N?

Bug introduced in 11.3 and fixed in 12.0.

Why does N just return the exact number below? I want a 2000 digit approximation...

N[
Root[
{ 750 + 5*E^((Log[3] - Log[5] + Log[13])*#1) - 300*#1 - 2*E^((Log[3] - Log[5] + Log[13])*#1)*#1 - 5*E^((Log[3] - Log[5] + Log[13])*#1)*(Log[3] - Log[5] + Log[13])*#1 + E^((Log[3] - Log[5] + Log[13])*#1)*(Log[3] - Log[5] + Log[13])*#1^2 &
, 1.6195471442353527733758434512960399168120.521825446421918
}
]
, 2000
]


It works if I ask less precision. Is this behavior correct and if it is, how is the upper limit of precision that mathematica will compute defined?

• I got an approximate value 1.6195471442353... when I ran that code. Commented Jun 4, 2018 at 14:22
• It works for me at 2000, but stops working when prec > 2003. I would report this to support. Commented Jun 4, 2018 at 14:24
• Same for me with prec >= 2004 (version 11.3, macOS). Commented Jun 4, 2018 at 14:29
• Tested up to 100000, and it works just fine for me (10.4.1 for Microsoft Windows (64-bit)). Commented Jun 4, 2018 at 15:14
• Already fixed in the development version. Commented Jun 5, 2018 at 2:19

As @t-smart seems to suspect, the change in V11.3 to let machine underflows to underflow to 0. is at the root of this bug. In the OP's problem, Mathematica isolates the roots with rational numbers to the desired precision. It then uses the interval length to determine the precision argument to N to get the final result. Unfortunately it uses machine precision to approximate the interval length, which underflows to 0.. The resulting precision, based on Log[0.] is Indeterminate, which is an invalid precision argument for N. This failure results in N returning unevaluated.

FWIW, a fix is to redefine N via the Villegas-Gayley trick:

InternalInheritedBlock[{N},
Unprotect[N];
N[e_] /; ! TrueQ[$in] := Block[{$in = True},
With[{ne = N[e]},
If[e != 0 && ne == 0.,
N[e, \$MachinePrecision],
ne
]
]];
Protect[N];
N[Root[{750 + 5*E^((Log[3] - Log[5] + Log[13])*#1) - 300*#1 -
2*E^((Log[3] - Log[5] + Log[13])*#1)*#1 -
5*E^((Log[3] - Log[5] + Log[13])*#1)*(Log[3] - Log[5] +
Log[13])*#1 +
E^((Log[3] - Log[5] + Log[13])*#1)*(Log[3] - Log[5] +
Log[13])*#1^2 &,
1.6195471442353527733758434512960399168120.521825446421918}],
2010]
]
(*
1.61954714423535277337906541500279581776848110660831546798133301726783\
...\
317430074329935276876493295501167507324563338238323
*)


I cannot explain the threshold precision (which seems to be Log10[2*^2003]) for the bug.

I suppose this is a problem involving the numeric precision with Mathematica. Since I don't have the source code, my best guess is that somehow the rules dealing with N changed in the past update. N[Khinchin, 2000] This code runs fine on Mathematica 11.2, giving a correct result. But on Mathematica 11.3, this is what it get: So in 11.3, MMA changed the rules and set a hard stop on the maximum digits. For your code, that is what happened, Root` gets onto the hard stop, thus putting an end to the calculation. The reason of this change is unknown. Speed improvements, I suppose?