Bug introduced in 8.0 or earlier and persisting through 12.0

TableForm[Partition[Range@9, 3], TableSpacing -> {0, 0.5}]


TableForm[Partition[Range@9, 3], TableSpacing -> {0, 1/2}]


Note that the second result has looser spacing than the first. These are images taken of those notebook cells. (This is more evident with larger arrays, but these are big enough to see the effect.)

So why is 0.5 not the same as 1/2?

I am running Mathematica on MacOS Sierra 10.12.3.

  • $\begingroup$ TableForm[Partition[Range@12, 4], TableSpacing -> {0, 0.5}] === TableForm[Partition[Range@12, 4], TableSpacing -> {0, 1/2}] returns False in my case too. $\endgroup$
    – Ali Hashmi
    Mar 20, 2017 at 3:48
  • 6
    $\begingroup$ That they're not equal is expected, since the forms you are comparing have the 0.5 and 1/2 in them. (You can use FullForm to look at what you're comparing.) What is odd is that the displayed tables look different. $\endgroup$
    – Mark Adler
    Mar 20, 2017 at 4:11
  • $\begingroup$ I see the same problem in MMA 11.1.0 on WIndows. $\endgroup$ Mar 20, 2017 at 4:15
  • $\begingroup$ The same problem is seen in GridBox with ColumnSpacings and RowSpacings attributes. Interestingly, Grid seems to have no problem with Spacings. $\endgroup$ Mar 20, 2017 at 4:26
  • $\begingroup$ @Mark Adler are not the structures of the two tableforms compared? I will check using FullForm. $\endgroup$
    – Ali Hashmi
    Mar 20, 2017 at 4:43

1 Answer 1


I see the same with versions 8.0.4, 10.4.1 and 11.1.0 on Windows 7 x64. Only with version 5.2 the outputs are formatted identically.

Let us look at the underlying box expression printed in the Notebook in each case (the following is the output from version 11.1.0):

CellPrint[ExpressionCell[TableForm[Partition[Range@4, 2], TableSpacing -> {0, #}], 
     "Output", CellTags -> "GridSpacings"]] & /@ {.5, 1/2};
cells = NotebookRead /@ Cells[CellTags -> "GridSpacings"];
Cases[#, Verbatim[Rule][GridBoxSpacings, _], -2] & /@ cells


{{GridBoxSpacings -> {"Columns" -> {Offset[0.28], {Offset[0.35]}, Offset[0.28]}, 
    "ColumnsIndexed" -> {}, "Rows" -> {Offset[0.2], {Offset[0.]}, Offset[0.2]}, 
    "RowsIndexed" -> {}}}, 
 {GridBoxSpacings -> {"Columns" -> {Offset[0.28], {1/2}, Offset[0.28]}, 
    "ColumnsIndexed" -> {}, "Rows" -> {Offset[0.2], {Offset[0.]}, Offset[0.2]}, 
    "RowsIndexed" -> {}}}}

One can see essential difference in the spacing specifications for "Columns"! These GridBox options are all undocumented, but if we assume that their forms are the same as for Spacings we are confused again because in our case the middle term shouldn't matter:

{s1,{c},sn}     use s1, then repeatedly use c, but use sn at the end

Oh, Gid has a lot of "oddities", probably this is just another one.

But what makes things even more painful is that the above oddity is due to a conversion performed solely by the FrontEnd, because the Kernel's ToBoxes creates numerically identical expressions:

N@ToBoxes@TableForm[Partition[Range@4, 2], TableSpacing -> {0, .5}] ===
 N@ToBoxes@TableForm[Partition[Range@4, 2], TableSpacing -> {0, 1/2}]

Hence we can't catch such an "oddity" without conversation with the FrontEnd.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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