Table iteration error with non-perfect-square max

Question

Just now when trying to produce equally spaced numbers, there's a warning message for

n = 3; 
Mx = Sqrt[6];
Table[ j, {j, Mx/n, Mx, Mx/n}]

The desired list involving $\sqrt{3}$ is still produced, yet the warning message is complaining "... $MaxExtraPrecision was encountered ... upper estimate will be used for the number of iterations...", along with a small segment of internal code shows flooring.

The warning message appears for $M_x$ being multiples of 3. The same goes for $n=7$ while $M_x$ is a multiple of 7.

So far it appears that as long as the max $M_x = \sqrt{k\, n}~$ is not an integer (i.e. $kn$ is not a perfect sqaure, there's still a square root ), even though it's algebraically exact, Mathematica cannot correctly deduce that the number of iteration is exactly $n$ when the starting value $\frac{M_x}{n}$ and ending value $M_x$ is set like that.

I haven't tried but it's likely that other forms of input (that are mathematically equivalent) will result in the same warning.

It doesn't affect other things, but seems like a tiny bug?

What's your opinion? Thank you.

Answer 1

I would not call this a bug.

You say,

Mathematica cannot correctly deduce that the number of iteration

but I guess you mean that it cannot deduce the exact result. The approximate result it produces happens to be correct. I get the following output:

{Sqrt[2/3], 2 Sqrt[2/3], Sqrt[6]}

Do you not get the correct result?

---

The reason why this happens is made clear by the warning message. Mathematica computes the number of elements in the list as follows:

Floor[(upperbound - lowerbound) / step + 1]

which in this case is

Floor[(Mx - Mx/n)/(Mx/n) + 1]

and evaluates to

Floor[1 + Sqrt[3/2] (-Sqrt[(2/3)] + Sqrt[6])]

Floor appears to use numerical methods to compute its result even for exact arguments. I assume (I may be wrong) that if its argument is not an explicit integer, then it simply computes it with sufficient precision to detect a deviation from an integer. In this case however, Sqrt[3/2] (-Sqrt[(2/3)] + Sqrt[6]) is an exact integer, so no matter how many digits we compute, we never get a deviation. Floor thus fails, and Table decides to use an approximate calculation instead of an exact one. The approximate calculation gets lucky and still gives the correct exact answer (not one less or one more).

All this happens because of how things like Sqrt[6]/3 evaluate automatically to Sqrt[2/3]. I don't think this sort of thing is fully avoidable. It will always be possible to construct complicated expressions which are really exact integers in disguise. Symbolic methods won't work for everything, and they are also slow. So Floor doesn't even seem to attempt them, and resorts to numerics instead (side note: this allows Floor and similar functions to be very general and work with constants like these). And in these special cases numerical methods fails to produce an provably exact result.

Of course this works:

Floor[1 + Sqrt[3/2] (-Sqrt[(2/3)] + Sqrt[6])] // Simplify

3

But personally I think it was a good decision not to invoke functions like Simplify from Table. I think of Table (and even Floor) as something simple and predictable (especially performance-wise). Simplify is not predictable and may run even for several minutes in unlucky cases.

To sum up: I would not call this a bug because it will always be possible to construct pathological expressions on which Floor would not work well.

---

A possible workaround:

Table[..., {, Subdivide[Mx/n, Mx, n - 1]}]

Subdivide is new in v10.1, but it is trivial to implement as Mx/n + (Mx - Mx/n)/(n - 1) Range[0, n - 1].