18
$\begingroup$

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?

$\endgroup$
  • 5
    $\begingroup$ I got an approximate value 1.6195471442353... when I ran that code. $\endgroup$ – Daniel Lichtblau Jun 4 '18 at 14:22
  • 5
    $\begingroup$ It works for me at 2000, but stops working when prec > 2003. I would report this to support. $\endgroup$ – Carl Woll Jun 4 '18 at 14:24
  • 1
    $\begingroup$ Same for me with prec >= 2004 (version 11.3, macOS). $\endgroup$ – Henrik Schumacher Jun 4 '18 at 14:29
  • 2
    $\begingroup$ Tested up to 100000, and it works just fine for me (10.4.1 for Microsoft Windows (64-bit)). $\endgroup$ – AccidentalFourierTransform Jun 4 '18 at 15:14
  • 2
    $\begingroup$ Already fixed in the development version. $\endgroup$ – ilian Jun 5 '18 at 2:19
11
$\begingroup$

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.

$\endgroup$
5
$\begingroup$

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:enter image description here 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?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.