Mixing
Wrong calculation in Tikz foreach
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I've a misunderstanding about the method Tikz compute some numbers. I draw a graph with some scale. Here is a MWE :
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
foreach t in 0, 0.08, ..., 0.48%
draw (t,1) -- (t,-1) node[below]t;
endtikzpicture
enddocument
I thought 0.08 x 5 = 0.40 and not 0.40001. And why the number 0.48 does not appear ?
I guess the xscale factor is not foreign by this problem but i can't address the problem by changing this factor. Otherwise i have a coefficient in all the following graphplots.
I read on this post that pgf has a uniform relative precision of about 4–5 correct digits. Is it the same for Tikz ? Is there a way to increase the precision of Tikz ?
Thx for you help !
tikz-pgf foreach
asked 33 mins ago
Piroooh
558
add a comment |Â
up vote
3
down vote
favorite
I've a misunderstanding about the method Tikz compute some numbers. I draw a graph with some scale. Here is a MWE :
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
foreach t in 0, 0.08, ..., 0.48%
draw (t,1) -- (t,-1) node[below]t;
endtikzpicture
enddocument
I thought 0.08 x 5 = 0.40 and not 0.40001. And why the number 0.48 does not appear ?
I guess the xscale factor is not foreign by this problem but i can't address the problem by changing this factor. Otherwise i have a coefficient in all the following graphplots.
I read on this post that pgf has a uniform relative precision of about 4–5 correct digits. Is it the same for Tikz ? Is there a way to increase the precision of Tikz ?
Thx for you help !
tikz-pgf foreach
asked 33 mins ago
Piroooh
558
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I've a misunderstanding about the method Tikz compute some numbers. I draw a graph with some scale. Here is a MWE :
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
foreach t in 0, 0.08, ..., 0.48%
draw (t,1) -- (t,-1) node[below]t;
endtikzpicture
enddocument
I thought 0.08 x 5 = 0.40 and not 0.40001. And why the number 0.48 does not appear ?
I guess the xscale factor is not foreign by this problem but i can't address the problem by changing this factor. Otherwise i have a coefficient in all the following graphplots.
I read on this post that pgf has a uniform relative precision of about 4–5 correct digits. Is it the same for Tikz ? Is there a way to increase the precision of Tikz ?
Thx for you help !
tikz-pgf foreach
asked 33 mins ago
Piroooh
558
I've a misunderstanding about the method Tikz compute some numbers. I draw a graph with some scale. Here is a MWE :
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
foreach t in 0, 0.08, ..., 0.48%
draw (t,1) -- (t,-1) node[below]t;
endtikzpicture
enddocument
I thought 0.08 x 5 = 0.40 and not 0.40001. And why the number 0.48 does not appear ?
I guess the xscale factor is not foreign by this problem but i can't address the problem by changing this factor. Otherwise i have a coefficient in all the following graphplots.
I read on this post that pgf has a uniform relative precision of about 4–5 correct digits. Is it the same for Tikz ? Is there a way to increase the precision of Tikz ?
Thx for you help !
tikz-pgf foreach
tikz-pgf foreach
asked 33 mins ago
Piroooh
558
asked 33 mins ago
Piroooh
558
asked 33 mins ago
Piroooh
558
asked 33 mins ago
Piroooh
558
asked 33 mins ago
Piroooh
558
558
add a comment |Â
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
4
down vote
accepted
The Tikz manual states that this is normal, and I quote (p 902):
Normally, when a list item
...is encountered, there should already
have been two list items before it, which where numbers. Examples of
numbers are 1, -10, or -0.24. Let us call these numbersxandyand
letd := y − xbe their difference. Next, there should also be one
number following the three dots, let us call this numberz.
In this situation, the part of the list reading
x,y,...,zis replaced byx, x + d, x + 2d, x + 3d, ..., x + mdwhere the last dots are semantic
dots, not syntactic dots. The value m is the largest number such that
x + md ≤ zif d is positive or such thatx + md ≥ zif d is negative.
Perhaps it is best to explain this by some examples: The following
<list>have the same effects:
foreach x in 1,2,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,2,3,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,3,...,11 x, yields 1, 3, 5, 7, 9, 11
foreach x in 1,3,...,10 x, yields 1, 3, 5, 7, 9
foreach x in 0,0.1,...,0.5 x, yields 0, 0.1, 0.20001, 0.30002, 0.40002
foreach x in a,b,9,8,...,1,2,2.125,...,2.5 x, yields a, b, 9, 8, 7, 6, 5, 4, 3, 2, 1, 2, 2.125, 2.25, 2.375, 2.5
Like you, I asked myself the question and @egreg answered it excellently here: Why does pgffor estimate that 0.1-0=0.100005 in a foreach loop?
answered 19 mins ago
AndréC
3,661729
Very nice, in fact it's due to the decimal values and not thescalefactor ! I read the p.675 in the pgf-tikz manual who is the same than what you have quoted and the answer of @egreg. A way is simply to erase the dots and to write the numbers one-by-one. Easy for 5 values, less convenient for a bigger sample. Thx to quote the Tikz manual and the corresponding topic !
– Piroooh
7 mins ago
Yes, and @RuixiZhang gives a way to keep the accuracy of calculations with aforeachloop in his answer here: tex.stackexchange.com/a/446027/138900
– AndréC
4 mins ago
add a comment |Â
up vote
2
down vote
The limited precision is the obstacle.
You can get much greater accuracy using expl3.
documentclassstandalone
usepackagetikz
usepackagexparse
ExplSyntaxOn
NewDocumentCommandfpforeachmmmm
% #1 = start, #2 = step, #3 = end, #4 = what to do
fp_step_inline:nnnn #1 #2 #3 #4
ExplSyntaxOff
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
fpforeach00.080.48
draw (#1,1) -- (#1,-1) node[below]#1;
endtikzpicture
enddocument
Beware of divisions, though, because the problems are still there and the final step might be missing due to accuracy issues nonetheless, but this is a problem with all floating point computations.
answered 11 mins ago
egreg
688k8518323080
add a comment |Â
up vote
1
down vote
You can fix this by first working with integers and then reformatting the numbers to be the decimal representation you'd like to have:
First, I set the precision for the floating point
pgfkeys/pgf/number format/precision=2
Then in the foreach loop I parse the integers to become the desired decimals using the following code
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
Here's the full code:
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
pgfkeys/pgf/number format/precision=2
foreach t in 0, 8, ..., 48
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
draw (t,1) -- (t,-1)
node[below]
t;
endtikzpicture
enddocument
answered 7 mins ago
A.Ellett
35.4k1064164
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
The Tikz manual states that this is normal, and I quote (p 902):
Normally, when a list item
...is encountered, there should already
have been two list items before it, which where numbers. Examples of
numbers are 1, -10, or -0.24. Let us call these numbersxandyand
letd := y − xbe their difference. Next, there should also be one
number following the three dots, let us call this numberz.
In this situation, the part of the list reading
x,y,...,zis replaced byx, x + d, x + 2d, x + 3d, ..., x + mdwhere the last dots are semantic
dots, not syntactic dots. The value m is the largest number such that
x + md ≤ zif d is positive or such thatx + md ≥ zif d is negative.
Perhaps it is best to explain this by some examples: The following
<list>have the same effects:
foreach x in 1,2,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,2,3,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,3,...,11 x, yields 1, 3, 5, 7, 9, 11
foreach x in 1,3,...,10 x, yields 1, 3, 5, 7, 9
foreach x in 0,0.1,...,0.5 x, yields 0, 0.1, 0.20001, 0.30002, 0.40002
foreach x in a,b,9,8,...,1,2,2.125,...,2.5 x, yields a, b, 9, 8, 7, 6, 5, 4, 3, 2, 1, 2, 2.125, 2.25, 2.375, 2.5
Like you, I asked myself the question and @egreg answered it excellently here: Why does pgffor estimate that 0.1-0=0.100005 in a foreach loop?
answered 19 mins ago
AndréC
3,661729
Very nice, in fact it's due to the decimal values and not thescalefactor ! I read the p.675 in the pgf-tikz manual who is the same than what you have quoted and the answer of @egreg. A way is simply to erase the dots and to write the numbers one-by-one. Easy for 5 values, less convenient for a bigger sample. Thx to quote the Tikz manual and the corresponding topic !
– Piroooh
7 mins ago
Yes, and @RuixiZhang gives a way to keep the accuracy of calculations with aforeachloop in his answer here: tex.stackexchange.com/a/446027/138900
– AndréC
4 mins ago
add a comment |Â
up vote
4
down vote
accepted
The Tikz manual states that this is normal, and I quote (p 902):
Normally, when a list item
...is encountered, there should already
have been two list items before it, which where numbers. Examples of
numbers are 1, -10, or -0.24. Let us call these numbersxandyand
letd := y − xbe their difference. Next, there should also be one
number following the three dots, let us call this numberz.
In this situation, the part of the list reading
x,y,...,zis replaced byx, x + d, x + 2d, x + 3d, ..., x + mdwhere the last dots are semantic
dots, not syntactic dots. The value m is the largest number such that
x + md ≤ zif d is positive or such thatx + md ≥ zif d is negative.
Perhaps it is best to explain this by some examples: The following
<list>have the same effects:
foreach x in 1,2,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,2,3,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,3,...,11 x, yields 1, 3, 5, 7, 9, 11
foreach x in 1,3,...,10 x, yields 1, 3, 5, 7, 9
foreach x in 0,0.1,...,0.5 x, yields 0, 0.1, 0.20001, 0.30002, 0.40002
foreach x in a,b,9,8,...,1,2,2.125,...,2.5 x, yields a, b, 9, 8, 7, 6, 5, 4, 3, 2, 1, 2, 2.125, 2.25, 2.375, 2.5
Like you, I asked myself the question and @egreg answered it excellently here: Why does pgffor estimate that 0.1-0=0.100005 in a foreach loop?
answered 19 mins ago
AndréC
3,661729
Very nice, in fact it's due to the decimal values and not thescalefactor ! I read the p.675 in the pgf-tikz manual who is the same than what you have quoted and the answer of @egreg. A way is simply to erase the dots and to write the numbers one-by-one. Easy for 5 values, less convenient for a bigger sample. Thx to quote the Tikz manual and the corresponding topic !
– Piroooh
7 mins ago
Yes, and @RuixiZhang gives a way to keep the accuracy of calculations with aforeachloop in his answer here: tex.stackexchange.com/a/446027/138900
– AndréC
4 mins ago
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
The Tikz manual states that this is normal, and I quote (p 902):
Normally, when a list item
...is encountered, there should already
have been two list items before it, which where numbers. Examples of
numbers are 1, -10, or -0.24. Let us call these numbersxandyand
letd := y − xbe their difference. Next, there should also be one
number following the three dots, let us call this numberz.
In this situation, the part of the list reading
x,y,...,zis replaced byx, x + d, x + 2d, x + 3d, ..., x + mdwhere the last dots are semantic
dots, not syntactic dots. The value m is the largest number such that
x + md ≤ zif d is positive or such thatx + md ≥ zif d is negative.
Perhaps it is best to explain this by some examples: The following
<list>have the same effects:
foreach x in 1,2,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,2,3,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,3,...,11 x, yields 1, 3, 5, 7, 9, 11
foreach x in 1,3,...,10 x, yields 1, 3, 5, 7, 9
foreach x in 0,0.1,...,0.5 x, yields 0, 0.1, 0.20001, 0.30002, 0.40002
foreach x in a,b,9,8,...,1,2,2.125,...,2.5 x, yields a, b, 9, 8, 7, 6, 5, 4, 3, 2, 1, 2, 2.125, 2.25, 2.375, 2.5
Like you, I asked myself the question and @egreg answered it excellently here: Why does pgffor estimate that 0.1-0=0.100005 in a foreach loop?
answered 19 mins ago
AndréC
3,661729
The Tikz manual states that this is normal, and I quote (p 902):
Normally, when a list item
...is encountered, there should already
have been two list items before it, which where numbers. Examples of
numbers are 1, -10, or -0.24. Let us call these numbersxandyand
letd := y − xbe their difference. Next, there should also be one
number following the three dots, let us call this numberz.
In this situation, the part of the list reading
x,y,...,zis replaced byx, x + d, x + 2d, x + 3d, ..., x + mdwhere the last dots are semantic
dots, not syntactic dots. The value m is the largest number such that
x + md ≤ zif d is positive or such thatx + md ≥ zif d is negative.
Perhaps it is best to explain this by some examples: The following
<list>have the same effects:
foreach x in 1,2,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,2,3,...,6 x, yields 1, 2, 3, 4, 5, 6
foreach x in 1,3,...,11 x, yields 1, 3, 5, 7, 9, 11
foreach x in 1,3,...,10 x, yields 1, 3, 5, 7, 9
foreach x in 0,0.1,...,0.5 x, yields 0, 0.1, 0.20001, 0.30002, 0.40002
foreach x in a,b,9,8,...,1,2,2.125,...,2.5 x, yields a, b, 9, 8, 7, 6, 5, 4, 3, 2, 1, 2, 2.125, 2.25, 2.375, 2.5
Like you, I asked myself the question and @egreg answered it excellently here: Why does pgffor estimate that 0.1-0=0.100005 in a foreach loop?
answered 19 mins ago
AndréC
3,661729
answered 19 mins ago
AndréC
3,661729
answered 19 mins ago
AndréC
3,661729
answered 19 mins ago
AndréC
3,661729
3,661729
Very nice, in fact it's due to the decimal values and not thescalefactor ! I read the p.675 in the pgf-tikz manual who is the same than what you have quoted and the answer of @egreg. A way is simply to erase the dots and to write the numbers one-by-one. Easy for 5 values, less convenient for a bigger sample. Thx to quote the Tikz manual and the corresponding topic !
– Piroooh
7 mins ago
Yes, and @RuixiZhang gives a way to keep the accuracy of calculations with aforeachloop in his answer here: tex.stackexchange.com/a/446027/138900
– AndréC
4 mins ago
add a comment |Â
Very nice, in fact it's due to the decimal values and not thescalefactor ! I read the p.675 in the pgf-tikz manual who is the same than what you have quoted and the answer of @egreg. A way is simply to erase the dots and to write the numbers one-by-one. Easy for 5 values, less convenient for a bigger sample. Thx to quote the Tikz manual and the corresponding topic !
– Piroooh
7 mins ago
Yes, and @RuixiZhang gives a way to keep the accuracy of calculations with aforeachloop in his answer here: tex.stackexchange.com/a/446027/138900
– AndréC
4 mins ago
Very nice, in fact it's due to the decimal values and not the
scale factor ! I read the p.675 in the pgf-tikz manual who is the same than what you have quoted and the answer of @egreg. A way is simply to erase the dots and to write the numbers one-by-one. Easy for 5 values, less convenient for a bigger sample. Thx to quote the Tikz manual and the corresponding topic !– Piroooh
7 mins ago
Very nice, in fact it's due to the decimal values and not the
scale factor ! I read the p.675 in the pgf-tikz manual who is the same than what you have quoted and the answer of @egreg. A way is simply to erase the dots and to write the numbers one-by-one. Easy for 5 values, less convenient for a bigger sample. Thx to quote the Tikz manual and the corresponding topic !– Piroooh
7 mins ago
Yes, and @RuixiZhang gives a way to keep the accuracy of calculations with a
foreach loop in his answer here: tex.stackexchange.com/a/446027/138900– AndréC
4 mins ago
Yes, and @RuixiZhang gives a way to keep the accuracy of calculations with a
foreach loop in his answer here: tex.stackexchange.com/a/446027/138900– AndréC
4 mins ago
add a comment |Â
up vote
2
down vote
The limited precision is the obstacle.
You can get much greater accuracy using expl3.
documentclassstandalone
usepackagetikz
usepackagexparse
ExplSyntaxOn
NewDocumentCommandfpforeachmmmm
% #1 = start, #2 = step, #3 = end, #4 = what to do
fp_step_inline:nnnn #1 #2 #3 #4
ExplSyntaxOff
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
fpforeach00.080.48
draw (#1,1) -- (#1,-1) node[below]#1;
endtikzpicture
enddocument
Beware of divisions, though, because the problems are still there and the final step might be missing due to accuracy issues nonetheless, but this is a problem with all floating point computations.
answered 11 mins ago
egreg
688k8518323080
add a comment |Â
up vote
2
down vote
The limited precision is the obstacle.
You can get much greater accuracy using expl3.
documentclassstandalone
usepackagetikz
usepackagexparse
ExplSyntaxOn
NewDocumentCommandfpforeachmmmm
% #1 = start, #2 = step, #3 = end, #4 = what to do
fp_step_inline:nnnn #1 #2 #3 #4
ExplSyntaxOff
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
fpforeach00.080.48
draw (#1,1) -- (#1,-1) node[below]#1;
endtikzpicture
enddocument
Beware of divisions, though, because the problems are still there and the final step might be missing due to accuracy issues nonetheless, but this is a problem with all floating point computations.
answered 11 mins ago
egreg
688k8518323080
add a comment |Â
up vote
2
down vote
up vote
2
down vote
The limited precision is the obstacle.
You can get much greater accuracy using expl3.
documentclassstandalone
usepackagetikz
usepackagexparse
ExplSyntaxOn
NewDocumentCommandfpforeachmmmm
% #1 = start, #2 = step, #3 = end, #4 = what to do
fp_step_inline:nnnn #1 #2 #3 #4
ExplSyntaxOff
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
fpforeach00.080.48
draw (#1,1) -- (#1,-1) node[below]#1;
endtikzpicture
enddocument
Beware of divisions, though, because the problems are still there and the final step might be missing due to accuracy issues nonetheless, but this is a problem with all floating point computations.
answered 11 mins ago
egreg
688k8518323080
The limited precision is the obstacle.
You can get much greater accuracy using expl3.
documentclassstandalone
usepackagetikz
usepackagexparse
ExplSyntaxOn
NewDocumentCommandfpforeachmmmm
% #1 = start, #2 = step, #3 = end, #4 = what to do
fp_step_inline:nnnn #1 #2 #3 #4
ExplSyntaxOff
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
fpforeach00.080.48
draw (#1,1) -- (#1,-1) node[below]#1;
endtikzpicture
enddocument
Beware of divisions, though, because the problems are still there and the final step might be missing due to accuracy issues nonetheless, but this is a problem with all floating point computations.
answered 11 mins ago
egreg
688k8518323080
answered 11 mins ago
egreg
688k8518323080
answered 11 mins ago
egreg
688k8518323080
answered 11 mins ago
egreg
688k8518323080
688k8518323080
add a comment |Â
add a comment |Â
up vote
1
down vote
You can fix this by first working with integers and then reformatting the numbers to be the decimal representation you'd like to have:
First, I set the precision for the floating point
pgfkeys/pgf/number format/precision=2
Then in the foreach loop I parse the integers to become the desired decimals using the following code
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
Here's the full code:
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
pgfkeys/pgf/number format/precision=2
foreach t in 0, 8, ..., 48
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
draw (t,1) -- (t,-1)
node[below]
t;
endtikzpicture
enddocument
answered 7 mins ago
A.Ellett
35.4k1064164
add a comment |Â
up vote
1
down vote
You can fix this by first working with integers and then reformatting the numbers to be the decimal representation you'd like to have:
First, I set the precision for the floating point
pgfkeys/pgf/number format/precision=2
Then in the foreach loop I parse the integers to become the desired decimals using the following code
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
Here's the full code:
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
pgfkeys/pgf/number format/precision=2
foreach t in 0, 8, ..., 48
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
draw (t,1) -- (t,-1)
node[below]
t;
endtikzpicture
enddocument
answered 7 mins ago
A.Ellett
35.4k1064164
add a comment |Â
up vote
1
down vote
up vote
1
down vote
You can fix this by first working with integers and then reformatting the numbers to be the decimal representation you'd like to have:
First, I set the precision for the floating point
pgfkeys/pgf/number format/precision=2
Then in the foreach loop I parse the integers to become the desired decimals using the following code
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
Here's the full code:
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
pgfkeys/pgf/number format/precision=2
foreach t in 0, 8, ..., 48
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
draw (t,1) -- (t,-1)
node[below]
t;
endtikzpicture
enddocument
answered 7 mins ago
A.Ellett
35.4k1064164
You can fix this by first working with integers and then reformatting the numbers to be the decimal representation you'd like to have:
First, I set the precision for the floating point
pgfkeys/pgf/number format/precision=2
Then in the foreach loop I parse the integers to become the desired decimals using the following code
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
Here's the full code:
documentclassstandalone
usepackage[french]babel
usepackagetikz
begindocument
begintikzpicture[yscale=0.1,xscale=25]
draw[<->] (0.5,0) node[below right]t -- (0,0) -- (0,100) node[above left]x(t);
%%Graduation
pgfkeys/pgf/number format/precision=2
foreach t in 0, 8, ..., 48
pgfmathparset/100
pgfmathroundtozerofillpgfmathresult
pgfmathsetmacrotpgfmathresult
draw (t,1) -- (t,-1)
node[below]
t;
endtikzpicture
enddocument
answered 7 mins ago
A.Ellett
35.4k1064164
answered 7 mins ago
A.Ellett
35.4k1064164
answered 7 mins ago
A.Ellett
35.4k1064164
answered 7 mins ago
A.Ellett
35.4k1064164
35.4k1064164
add a comment |Â
add a comment |Â
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%2f454781%2fwrong-calculation-in-tikz-foreach%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