Possible bug in Floor function?

[psycho_dad]

Hi,

I think I may have stumbled upon a possible bug in Floor. Evaluating the following gives the correct result:

Floor[Log[10, 100.]]
2

Evaluating it with a replacement and //N gives a message and the wrong result:

Floor[Log[10, x]] /. x -> 100 // N

Floor::meprec: Internal precision limit $MaxExtraPrecision = 50.` reached while evaluating Floor[Log[100]/Log[10]]. >>

1

I'm on Math 9.0 + Win7, but Math 8 gives the same (wrong) result as well.

Cheers

[Matthias Bode]

Hola,

the "salient point":

In[1]:= Log[1000, 1000000]
Floor[Log[1000., x]] /. x -> 1000000
N[Floor[Log[1000., x]] /. x -> 1000000]
N[Floor[Log[1000, x]] /. x -> 1000000]
Floor[Log[1000, x]] /. x -> 1000000

Out[1]= 2

Out[2]= 2

Out[3]= 2.

During evaluation of In[1]:= Floor::meprec:Internal precision limit $MaxExtraPrecision = 50.` reached while evaluating Floor[Log[1000000]/Log[1000]]. >>

Out[4]= 2

During evaluation of In[1]:= Floor::meprec:Internal precision limit $MaxExtraPrecision = 50.` reached while evaluating Floor[Log[1000000]/Log[1000]]. >>

Out[5]= Floor[Log[1000000]/Log[1000]]

But not reliably so:

In[1]:= Log[100, 10000]
Floor[Log[100., x]] /. x -> 10000
N[Floor[Log[100., x]] /. x -> 10000]
N[Floor[Log[100, x]] /. x -> 10000]
Floor[Log[100, x]] /. x -> 10000

Out[1]= 2

Out[2]= 1

Out[3]= 1.

During evaluation of In[1]:= Floor::meprec:Internal precision limit $MaxExtraPrecision = 50.` reached while evaluating Floor[Log[10000]/Log[100]]. >>

Out[4]= 1

During evaluation of In[1]:= Floor::meprec:Internal precision limit $MaxExtraPrecision = 50.` reached while evaluating Floor[Log[10000]/Log[100]]. >>

Out[5]= Floor[Log[10000]/Log[100]]

In[7]:= $Version

Out[7]= "9.0 for Microsoft Windows (64-bit) (January 25, 2013)"

Best regards,

MATTHIAS BODE.
S 17.36398
W 66.218162'590 m. AMSL.
> From: s.nes...@gmail.com
> Subject: Possible bug in Floor function?
> To: math...@smc.vnet.net
> Date: Sat, 15 Feb 2014 04:02:14 -0500

[Bill Rowe]

On 2/15/14 at 4:02 AM, s.nes...@gmail.com (psycho_dad) wrote:

>I think I may have stumbled upon a possible bug in Floor. Evaluating
>the following gives the correct result:

>Floor[Log[10, 100.]]
>2

>Evaluating it with a replacement and //N gives a message and the
>wrong result:

>Floor[Log[10, x]] /. x -> 100 // N

>1

The problem isn't with Floor. The issue is simply the usage of
machine precision arithmetic. That is

In[11]:= RealDigits[Log[10, x] /. x -> 100 // N]

Out[11]= {{1,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9},1}

As you can see, the result is just slightly less than 2. So, the
result Floor returns is correct

[Bob Hanlon]

It is sometimes better to simplify expressions prior to using numerical
techniques.


$Version


"9.0 for Mac OS X x86 (64-bit) (January 24, 2013)"


Off[Floor::meprec] (* Supressing error messages. This does not change the
results. *)

Floor[Log[10, x]] /. x -> 100 //

FullSimplify // N


2.

Floor[Log[10, x] /. x -> 100 //

FullSimplify] // N


2.


Oddly, using PowerExpand results in an integer result despite the use of N

Floor[Log[10, x]] /. x -> 100 //

PowerExpand // N


2

Floor[Log[10, x] /. x -> 100 //

PowerExpand] // N


2



Bob Hanlon




On Sat, Feb 15, 2014 at 4:02 AM, psycho_dad <s.nes...@gmail.com> wrote:

> Hi,

>
> I think I may have stumbled upon a possible bug in Floor. Evaluating the
> following gives the correct result:
>
> Floor[Log[10, 100.]]
> 2
>
> Evaluating it with a replacement and //N gives a message and the wrong
> result:
>
> Floor[Log[10, x]] /. x -> 100 // N
>

[Richard Fateman]

The bug in not in Log, either.

4.605170185988092/2.302585092994046

appears to return 2, but
InputForm[%] is
1.9999999999999998

Those two numbers above are InputForm[Log[100.]] and
InputForm[Log[10.]], but that is incidental. They can be produced in
other ways, including just typing them in.

The problem seems to be not that Mathematica cannot compute Floor.
It appears the problem is that Mathematica cannot divide. :)

[John Doty]

The problematic function here is Log. While Log[x,y] with exact numeric arguments will transform to an exact numeric value if possible, in other cases it transforms to Log[y]/Log[x]. But then, nothing short of FullSimplify[] seems to be able to reverse this. So, Floor[] sees Log[100]/Log[10] and cannot reduce it to an exact numerical value. It falls back on interval arithmetic, but that can't work at a point where Floor[] is discontinuous.

Floor[] seems to have no trouble with other hairy expressions that happen to equal integers, for example "((-1)^(1/3) + (-1)^(2/3))/Sqrt[-3]". But a mere Simplify[] reduces that to 1. Perhaps that's where the real bug is. Does Floor[] try Simplify[]? Maybe Simplify[] should be transforming things like Log[100]/Log[10].

[Itai Seggev]

On Sat, Feb 15, 2014 at 04:02:14AM -0500, psycho_dad wrote:
> Hi,
>
> I think I may have stumbled upon a possible bug in Floor. Evaluating the following gives the correct result:
>
> Floor[Log[10, 100.]]
> 2
>
> Evaluating it with a replacement and //N gives a message and the wrong result:
>
> Floor[Log[10, x]] /. x -> 100 // N
>
> Floor::meprec: Internal precision limit $MaxExtraPrecision = 50.` reached while evaluating Floor[Log[100]/Log[10]]. >>
>
> 1
>
> I'm on Math 9.0 + Win7, but Math 8 gives the same (wrong) result as well.

It's not a bug per se, but it is a somewhat unfortunate edge case. No one has
really hit on the fundamental issue, so here it is:

In[37]:= Log[10, 100]

Out[37]= 2

In[38]:= Log[10, x]

Out[38]= Log[x]/Log[10]

Doing things symbollically has introduced an extra division. This will come up
when trying to evaluate things numerically.

If you introduce an arbitary precision x, it will compute to whatever precision
x is, round to 2 (of some precision), and give you that answer:

In[40]:= Floor[Log[x]/Log[10]] /. x -> 100`50

Out[40]= 2

If you give it a machine precision, it will perform the computation without
error checking, get a number slightly less than 2 due to rounding, and return 1:

In[39]:= Floor[Log[x]/Log[10]] /. x -> 100.

Out[39]= 1

When you substitue in 100, it attempts to calculate the answer to arbitrary
precision, reaches $MaxExtraPrecision, issues the message, and then returns
unevaluated:

In[41]:= Floor[Log[x]/Log[10]]

During evaluation of In[43]:= Floor::meprec: Internal precision limit $MaxExtraPrecision = 50.` reached while evaluating Floor[Log[100]/Log[10]]. >>

Out[41]= Floor[Log[100]/Log[10]]

When you then hit it with N, you get back to the In[39] case, and end up with 1.

One way to prevent this sort of premature evaluation which can lead to
confusing results is to use Block to temporarily reset variables at the
beginning of a computation, rather than substituting the values in at the end.
(Notice there's no mprec message, since we went streight to Log[10,100].)

In[44]:= Block[{x = 100}, Floor[Log[10, x]]]

Out[44]= 2

--
Itai Seggev
Mathematica Algorithms R&D
217-398-0700

[John Doty]

On Wednesday, February 19, 2014 1:43:20 AM UTC-5, Itai Seggev wrote:

> It's not a bug per se, but it is a somewhat unfortunate edge case. No one has
>
> really hit on the fundamental issue,

I hit on it in my post in this thread, and you didn't address one one the important details here. Let me repeat:

Floor[] seems to have no trouble with other hairy expressions that happen to equal integers, for example "((-1)^(1/3) + (-1)^(2/3))/Sqrt[-3]". But a mere Simplify[] reduces that to 1. Perhaps that's where the real bug is. Does Floor[] try Simplify[]? Maybe Simplify[] should be transforming things like Log[100]/Log[10].

[Itai Seggev]

On Sat, Feb 22, 2014 at 03:03:53AM -0500, John Doty wrote:
> On Wednesday, February 19, 2014 1:43:20 AM UTC-5, Itai Seggev wrote:
>
> > It's not a bug per se, but it is a somewhat unfortunate edge case. No one has
> >
> > really hit on the fundamental issue,
>
> I hit on it in my post in this thread, and you didn't address one one the

Yes you did, although your email made it to the list after I had sent my email.

> important details here. Let me repeat:
>
> Floor[] seems to have no trouble with other hairy expressions that happen to equal integers, for example "((-1)^(1/3) + (-1)^(2/3))/Sqrt[-3]". But a mere Simplify[] reduces that to 1. Perhaps that's where the real bug is. Does Floor[] try Simplify[]? Maybe Simplify[] should be transforming things like Log[100]/Log[10].

No, Floor doesn't use Simplify. It uses adaptive numerical approximation.
It's just that for your hidden integer, it gets an answer it can verify (on its
first attempt, no less), whereas for the Log case that started the threade it
can't verify its answer and defaults to raw machine arithmetic.

As to whether Simplify should undo Logs, I don't know. I don't know enough
about the internals for Simplify vs FullSimplify and where we draw the line to
comment intelligently on that point. I can certainly pass it along as
suggestion to the relevant developer.

[John Doty]

On Sunday, February 23, 2014 2:54:56 AM UTC-5, Itai Seggev wrote:
> No, Floor doesn't use Simplify. It uses adaptive numerical approximation.
>
> It's just that for your hidden integer, it gets an answer it can verify (on its
>
> first attempt, no less), whereas for the Log case that started the threade it
>
> can't verify its answer and defaults to raw machine arithmetic.

OK, so that leads to the next question: why doesn't this work for Log[100]/Log[10]? Somewhere it has a mechanism that allows it to verify Log[100]/Log[10]==2, as we see when we apply FullSimplify. Shouldn't it be using that mechanism in this case?