Why this weird return value from `N`?

Question

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.61954714423535277337584345129603991681`20.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. — Daniel Lichtblau, Jun 04 '18 at 14:22
It works for me at 2000, but stops working when prec > 2003. I would report this to support. — Carl Woll, Jun 04 '18 at 14:24
Tested up to 100000, and it works just fine for me (10.4.1 for Microsoft Windows (64-bit)). — AccidentalFourierTransform, Jun 04 '18 at 15:14
N[...., 100000] works fine on 10.4.1 for Linux x86 (64-bit), but fails for $\geq$ 2003 on 11.3.0 for Linux x86 (64-bit). — corey979, Jun 04 '18 at 15:36
Bug not present in Mma 11.2 for Windows 64bits, at least for up to 10000 digits precision. Confirmed in Mma 11.3 for Windows for 2004 digits precision and more. — rhermans, Jun 04 '18 at 17:39
Works for up to 2003 on Mathematica 11.3 on a Windows 10 computer. prec>=2004 yields only precise results — t-smart, Jun 05 '18 at 00:13

Michael E2 · Accepted Answer · 2018-06-05T10:52:07.797

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:

Internal`InheritedBlock[{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.61954714423535277337584345129603991681`20.521825446421918}], 
  2010]
 ]
(*
1.61954714423535277337906541500279581776848110660831546798133301726783\
...\
317430074329935276876493295501167507324563338238323  
*)

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

score 5 · Answer 2 · answered Jun 05 '18 at 00:24

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?

Why this weird return value from `N`?

2 Answers2

Linked