Mixing
Bamboozling Arithmetic!
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
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.
tikz-pgf pgfmath arithmetic
asked 5 hours ago
Dan Hoynoski
1517
New contributor
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
favorite
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.
tikz-pgf pgfmath arithmetic
asked 5 hours ago
Dan Hoynoski
1517
New contributor
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
All arithmetic is performed internally inpt, so the1cmis converted to28.45274pt.
– Phelype Oleinik
5 hours ago
The result is stored in unitpt; with*1cmyou get85.35823, without it is3.0; the quotient is28.45274, which is the number of points in 1cm.
– egreg
5 hours ago
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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.
tikz-pgf pgfmath arithmetic
asked 5 hours ago
Dan Hoynoski
1517
New contributor
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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.
tikz-pgf pgfmath arithmetic
tikz-pgf pgfmath arithmetic
asked 5 hours ago
Dan Hoynoski
1517
New contributor
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
Dan Hoynoski
1517
New contributor
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
Dan Hoynoski
1517
New contributor
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
Dan Hoynoski
1517
asked 5 hours ago
Dan Hoynoski
1517
1517
New contributor
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Dan Hoynoski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
All arithmetic is performed internally inpt, so the1cmis converted to28.45274pt.
– Phelype Oleinik
5 hours ago
The result is stored in unitpt; with*1cmyou get85.35823, without it is3.0; the quotient is28.45274, which is the number of points in 1cm.
– egreg
5 hours ago
add a comment |Â
All arithmetic is performed internally inpt, so the1cmis converted to28.45274pt.
– Phelype Oleinik
5 hours ago
The result is stored in unitpt; with*1cmyou get85.35823, without it is3.0; the quotient is28.45274, which is the number of points in 1cm.
– egreg
5 hours ago
All arithmetic is performed internally in
pt, so the 1cm is converted to 28.45274pt.– Phelype Oleinik
5 hours ago
All arithmetic is performed internally in
pt, so the 1cm is converted to 28.45274pt.– Phelype Oleinik
5 hours ago
The result is stored in unit
pt; with *1cm you get 85.35823, without it is 3.0; the quotient is 28.45274, which is the number of points in 1cm.– egreg
5 hours ago
The result is stored in unit
pt; with *1cm you get 85.35823, without it is 3.0; the quotient is 28.45274, which is the number of points in 1cm.– egreg
5 hours ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
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).
answered 5 hours ago
egreg
688k8518323080
add a comment |Â
up vote
2
down vote
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.
answered 5 hours ago
Werner
424k589281596
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
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).
answered 5 hours ago
egreg
688k8518323080
add a comment |Â
up vote
3
down vote
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).
answered 5 hours ago
egreg
688k8518323080
add a comment |Â
up vote
3
down vote
up vote
3
down vote
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).
answered 5 hours ago
egreg
688k8518323080
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).
answered 5 hours ago
egreg
688k8518323080
answered 5 hours ago
egreg
688k8518323080
answered 5 hours ago
egreg
688k8518323080
answered 5 hours ago
egreg
688k8518323080
688k8518323080
add a comment |Â
add a comment |Â
up vote
2
down vote
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.
answered 5 hours ago
Werner
424k589281596
add a comment |Â
up vote
2
down vote
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.
answered 5 hours ago
Werner
424k589281596
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.
answered 5 hours ago
Werner
424k589281596
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.
answered 5 hours ago
Werner
424k589281596
answered 5 hours ago
Werner
424k589281596
answered 5 hours ago
Werner
424k589281596
answered 5 hours ago
Werner
424k589281596
424k589281596
add a comment |Â
add a comment |Â
Dan Hoynoski is a new contributor. Be nice, and check out our Code of Conduct.
Dan Hoynoski is a new contributor. Be nice, and check out our Code of Conduct.
Dan Hoynoski is a new contributor. Be nice, and check out our Code of Conduct.
Dan Hoynoski is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f454835%2fbamboozling-arithmetic%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
All arithmetic is performed internally in
pt, so the1cmis converted to28.45274pt.– Phelype Oleinik
5 hours ago
The result is stored in unit
pt; with*1cmyou get85.35823, without it is3.0; the quotient is28.45274, which is the number of points in 1cm.– egreg
5 hours ago