mjhjmtu

While creating some pgfmathsetmacro arithmetic macros, I stumbled upon a very perplexing result. Take the following example:

documentclassarticle
usepackagetikz
usepackagexstring

begindocument

begintikzpicture
 newcommandboxWidth6cm;
 newcommandboxHeight1cm;

 pgfmathsetmacroboxOffsetboxWidth / 2cm * 1cm %%%wtf
 coordinate (Title) at (1cm + boxOffset,0);

 draw [red] (0,0) -- (1,0);

 node[draw, rounded corners=.3cm, color=red, minimum width=boxWidth, minimum height=boxHeight, text=black] at (Title) Hello;
 endtikzpicture
enddocument

This outputs a very predictable result:

However, if you remove * 1cm from my boxOffset macro, a totally unexpected result occurs:

What?! On the surface, this appears to be saying that 2 * 1 != 2 is a true statement!

To add to this, while I was playing around with creating an example LaTeX script for the following question on this forum, I stumbled upon a similar bamboozling arithmetic:

documentclassarticle
usepackagetikz
usepackagexstring

begindocument
begintikzpicture
 newcommandstrhello;

 pgfmathsetmacronumOnewidth("str") * 1pt / 4cm; %%%wtf

 node at (0, 0) str;
 draw [color=black] (numOne, 0cm) -- (numOne,-1cm);

endtikzpicture
enddocument

The following example creates the very predictable output:

However, if I change the numOne to compute the following width("str") * 1pt / 2cm / 2cm, then I get a very unpredictable output:

What?! This is telling me that the ridiculous statement x / 2 / 2 != x / 4 is true.

Can anyone shed some light on what is happening here? This is not the only time I have run into this bamboozling arithmetic and I am lost at what is happening.

^This is how I feel right now.

Your assumption that multiplying by 1cm is the same as multiplying by 1 is wrong.

What about multiplying by 1in or 1mm?

The function pgfmathresult returns a number, not a dimension. For implementation reasons, the number 1 is stored as a length, precisely 1pt.

Therefore 3*1 is 3, but 3*1cm is 85.35823, because 1cm=28.45275pt (and then TeX’s rounding applies).

The easiest way to address this is to see what the difference between the two calculations yield for boxOffset:

documentclassarticle

usepackagetikz

begindocument

newcommandboxWidth6cm
newcommandboxHeight1cm

pgfmathsetmacroboxOffsetboxWidth / 2cm%
verb|boxOffset| 1: boxOffset

pgfmathsetmacroboxOffsetboxWidth / 2cm * 1cm%
verb|boxOffset| 2: boxOffset

enddocument

In performing the division 6cm / 2cm, tikz converts the quantities to a uniform unit of measure (pts). However, in this case with similar measurements in the division, it results in merely "striping" the measurement, yielding in 3. This is understandable. Multiplying this result by 1cm, the value is first converted to pts (there are 28.45274 pts in every cm; see newlengthtemplen setlengthtemplen1cm thetemplen), yielding the desired result (3 x 28.45274 = 85.35822), with some floating point error.

A similar argument would hold for your other calculations as lengths are converted to pts before performing the arithmetic.