While the comments already contain a complete answer by Daniel Lichtblau, this behavior is also documented on ref/Floor
, see the first example under 'Possible Issues':
Floor does not automatically resolve the value:
Floor[π^2 + 2 π + 1 - (π + 1)^2]
(* Floor::meprec: Internal precision limit
$MaxExtraPrecision = 50.` reached while evaluating Floor[1+2π+π^2-(1+π)^2]. *)
(* Floor[1 + 2 π + π^2 - (1 + π)^2] *)
Even though 1 + 2 π + π^2 - (1 + π)^2
is in fact the exact integer 0, it is a "hidden zero" which cannot be unmasked using purely numerical methods.
Unlike other functions like FullSimplify
and PossibleZeroQ
which may use symbolic algorithms, Floor
is limited to numerical methods, see also this documentation note
For exact numeric quantities, Floor
internally uses numerical approximations to establish its result.
and the numerical approximation will never yield an exact zero, no matter how much extra precision is allowed, e.g.
Block[{$MaxExtraPrecision = 1000}, N[π^2 + 2 π + 1 - (π + 1)^2, 50]]
Similarly, Log[9]/Log[3]
is a "hidden integer". Numerical approximation of the exact quantity Log[9]/Log[3] - 2
is difficult, while numerical approximation of the machine precision number N[Log[9]/Log[3]] - 2
is not.
Floor[Log[9]/Log[3]] // FullSimplify
. -- Interesting,N
also works:N[Floor[Log[9]/Log[3]]]
. $\endgroup$2
, it tries to determine whether it is greater than or less than2
. This gives a similar error:N[Log[9]/Log[3] - 2, 30]
. $\endgroup$Floor
is discontinuous at the integers. Any attempt to use numeric methods on an exact example will have trouble there.That's what the message indicates. $\endgroup$Floor[ Log[36]/Log[6] // N ] (*1*)
$\endgroup$