Exact Fraction of a length
I want to place some elements on my page for which I need to calculate their size.
For my example lets say three of those elements should exactly occupy a linewidth when put side by side without space in between.
The easiest possibility might be to just give their width as 0.3linewidth -- but that might be a bit too small generating a gap somewhere. It is however possible to just use 0.3333333333333linewidth -- but that is much to write for a seemingly simple fraction [and it strikes my pedanticism as it's not exactly one third].
If I want to get an exact value of one third, I may use
newlengthonethirdlinewidth
onethirdlinewidth=linewidth
divideonethirdlinewidth by 3
that might be the best way if I use this length multiple times but might be a bit much to type for a one-shot use.
My question is: Is there any simple possibility to get a length of one third (or seven eighths) of a given length?
calculations lengths
|
show 2 more comments
I want to place some elements on my page for which I need to calculate their size.
For my example lets say three of those elements should exactly occupy a linewidth when put side by side without space in between.
The easiest possibility might be to just give their width as 0.3linewidth -- but that might be a bit too small generating a gap somewhere. It is however possible to just use 0.3333333333333linewidth -- but that is much to write for a seemingly simple fraction [and it strikes my pedanticism as it's not exactly one third].
If I want to get an exact value of one third, I may use
newlengthonethirdlinewidth
onethirdlinewidth=linewidth
divideonethirdlinewidth by 3
that might be the best way if I use this length multiple times but might be a bit much to type for a one-shot use.
My question is: Is there any simple possibility to get a length of one third (or seven eighths) of a given length?
calculations lengths
1
dimexprlinewidth/3anddimexpr7linewidth/8work. However TeX uses scaled integers to represent dimensions, so technically0.3333333333333linewidthis more precise than TeX's representation oflinewidth/3. When you input a long decimal chain like that TeX will truncate that to a value it can represent.
– Phelype Oleinik
3 hours ago
Actually, I didn't think about dimexpr. Mind putting that in an answer?
– David Woitkowski
3 hours ago
@PhelypeOleinik "a long decimal chain like that TeX will truncate that to a value it can represent" is misleading, it could be that no truncation can be exactly represented as an integer multiple of pt/65536.
– jfbu
3 hours ago
the most precise way to multiply by a fraction isdimexprnumexpr A*<dimen>/B sprelax(where<dimen>is likelinewidthbut not10ptthen usedimexpr10ptrelaxin place of<dimen>)
– jfbu
3 hours ago
@jfbu Agreed, unfortunate choice of words. On your second comment, why is that? Do you mind writing the answer explaining your comment, please?
– Phelype Oleinik
3 hours ago
|
show 2 more comments
I want to place some elements on my page for which I need to calculate their size.
For my example lets say three of those elements should exactly occupy a linewidth when put side by side without space in between.
The easiest possibility might be to just give their width as 0.3linewidth -- but that might be a bit too small generating a gap somewhere. It is however possible to just use 0.3333333333333linewidth -- but that is much to write for a seemingly simple fraction [and it strikes my pedanticism as it's not exactly one third].
If I want to get an exact value of one third, I may use
newlengthonethirdlinewidth
onethirdlinewidth=linewidth
divideonethirdlinewidth by 3
that might be the best way if I use this length multiple times but might be a bit much to type for a one-shot use.
My question is: Is there any simple possibility to get a length of one third (or seven eighths) of a given length?
calculations lengths
I want to place some elements on my page for which I need to calculate their size.
For my example lets say three of those elements should exactly occupy a linewidth when put side by side without space in between.
The easiest possibility might be to just give their width as 0.3linewidth -- but that might be a bit too small generating a gap somewhere. It is however possible to just use 0.3333333333333linewidth -- but that is much to write for a seemingly simple fraction [and it strikes my pedanticism as it's not exactly one third].
If I want to get an exact value of one third, I may use
newlengthonethirdlinewidth
onethirdlinewidth=linewidth
divideonethirdlinewidth by 3
that might be the best way if I use this length multiple times but might be a bit much to type for a one-shot use.
My question is: Is there any simple possibility to get a length of one third (or seven eighths) of a given length?
calculations lengths
calculations lengths
asked 3 hours ago
David WoitkowskiDavid Woitkowski
864513
864513
1
dimexprlinewidth/3anddimexpr7linewidth/8work. However TeX uses scaled integers to represent dimensions, so technically0.3333333333333linewidthis more precise than TeX's representation oflinewidth/3. When you input a long decimal chain like that TeX will truncate that to a value it can represent.
– Phelype Oleinik
3 hours ago
Actually, I didn't think about dimexpr. Mind putting that in an answer?
– David Woitkowski
3 hours ago
@PhelypeOleinik "a long decimal chain like that TeX will truncate that to a value it can represent" is misleading, it could be that no truncation can be exactly represented as an integer multiple of pt/65536.
– jfbu
3 hours ago
the most precise way to multiply by a fraction isdimexprnumexpr A*<dimen>/B sprelax(where<dimen>is likelinewidthbut not10ptthen usedimexpr10ptrelaxin place of<dimen>)
– jfbu
3 hours ago
@jfbu Agreed, unfortunate choice of words. On your second comment, why is that? Do you mind writing the answer explaining your comment, please?
– Phelype Oleinik
3 hours ago
|
show 2 more comments
1
dimexprlinewidth/3anddimexpr7linewidth/8work. However TeX uses scaled integers to represent dimensions, so technically0.3333333333333linewidthis more precise than TeX's representation oflinewidth/3. When you input a long decimal chain like that TeX will truncate that to a value it can represent.
– Phelype Oleinik
3 hours ago
Actually, I didn't think about dimexpr. Mind putting that in an answer?
– David Woitkowski
3 hours ago
@PhelypeOleinik "a long decimal chain like that TeX will truncate that to a value it can represent" is misleading, it could be that no truncation can be exactly represented as an integer multiple of pt/65536.
– jfbu
3 hours ago
the most precise way to multiply by a fraction isdimexprnumexpr A*<dimen>/B sprelax(where<dimen>is likelinewidthbut not10ptthen usedimexpr10ptrelaxin place of<dimen>)
– jfbu
3 hours ago
@jfbu Agreed, unfortunate choice of words. On your second comment, why is that? Do you mind writing the answer explaining your comment, please?
– Phelype Oleinik
3 hours ago
1
1
dimexprlinewidth/3 and dimexpr7linewidth/8 work. However TeX uses scaled integers to represent dimensions, so technically 0.3333333333333linewidth is more precise than TeX's representation of linewidth/3. When you input a long decimal chain like that TeX will truncate that to a value it can represent.– Phelype Oleinik
3 hours ago
dimexprlinewidth/3 and dimexpr7linewidth/8 work. However TeX uses scaled integers to represent dimensions, so technically 0.3333333333333linewidth is more precise than TeX's representation of linewidth/3. When you input a long decimal chain like that TeX will truncate that to a value it can represent.– Phelype Oleinik
3 hours ago
Actually, I didn't think about dimexpr. Mind putting that in an answer?
– David Woitkowski
3 hours ago
Actually, I didn't think about dimexpr. Mind putting that in an answer?
– David Woitkowski
3 hours ago
@PhelypeOleinik "a long decimal chain like that TeX will truncate that to a value it can represent" is misleading, it could be that no truncation can be exactly represented as an integer multiple of pt/65536.
– jfbu
3 hours ago
@PhelypeOleinik "a long decimal chain like that TeX will truncate that to a value it can represent" is misleading, it could be that no truncation can be exactly represented as an integer multiple of pt/65536.
– jfbu
3 hours ago
the most precise way to multiply by a fraction is
dimexprnumexpr A*<dimen>/B sprelax (where <dimen> is like linewidth but not 10pt then use dimexpr10ptrelax in place of <dimen>)– jfbu
3 hours ago
the most precise way to multiply by a fraction is
dimexprnumexpr A*<dimen>/B sprelax (where <dimen> is like linewidth but not 10pt then use dimexpr10ptrelax in place of <dimen>)– jfbu
3 hours ago
@jfbu Agreed, unfortunate choice of words. On your second comment, why is that? Do you mind writing the answer explaining your comment, please?
– Phelype Oleinik
3 hours ago
@jfbu Agreed, unfortunate choice of words. On your second comment, why is that? Do you mind writing the answer explaining your comment, please?
– Phelype Oleinik
3 hours ago
|
show 2 more comments
2 Answers
2
active
oldest
votes
Let's try this plain TeX test:
newdimentest
newdimenfixed
fixed=345pt
defdotest#1{test=#1fixed thetest -- numbertest par}
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
fixed=101pt
bigskip
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
bye

As you see, adding more decimal digits doesn't improve the result: from five digits on the result is the same. The last column is the value in scaled points.
The method with divide truncates, whereas dimexpr rounds. There may be a difference of 1 scaled point with the two methods (in this case).
Is 0.33333fixed better or worse than dimexprfixed/3relax? If you add flexible glue to fill the gaps the difference cannot be seen with the naked eye, because in the first case it amounts to 115 scaled points, which is less than 0.00062 mm.
You can try with fixed=maxdimen and the difference between the 0.333333 and divide methods is 5462sp, less than 0.03 mm.
Six digits versus five can make a small difference, depending on the number. But using seven or more is irrelevant.
"adding more decimal digits doesn't improve the result". It may change it, you need 17 decimal digits for stabilization in all cases.
– jfbu
2 hours ago
@jfbu Not with TeX. Using more than five decimal digits in a<factor>is a waste of time.
– egreg
2 hours ago
in fact our discussion is not precise. But try0.22222ptversus0.222222pt. Not the same thing.
– jfbu
2 hours ago
@jfbu I was talking about a<factor>not a<dimen>
– egreg
2 hours ago
?????*message{numberdimexpr0.22222dimexpr1ptrelaxrelax}gives14563and*message{numberdimexpr0.222222dimexpr1ptrelaxrelax}gives14564.
– jfbu
1 hour ago
|
show 7 more comments
I described how TeX inputs dimensions and handles units in https://tex.stackexchange.com/a/231281 and Why pdf file cannot be reproduced? and possibly at other locations, including some comments which are not always read.
I am using Plain TeX but of course it works exactly the same in LaTeX.
newdimenfixed
fixed 1pt
newdimentestA
newdimentestB
testA 0.33333587646484374fixed
testB 0.33333587646484375fixed
ifdimtestA = testB
The two dimensions are equal
else
The two dimensions are not equal
fi
bye
Outputs:

One needs 17 fractional digits to be certain that the dimension stabilizes (of course you get only 1sp possible difference after 5 fractional digits, because 1/10^5 < 1/65536, here in this example where one multiplies 1pt). And some things are counterintuitive, for example 0.33333 is enough but 0.22222 is not although it looks closer to 0.222222 than 0.33333 was to 0.333333.
It goes without saying that Knuth has programmed it exactly to fetch 17 fractional digits and not one more, because the theorem is that it will never change after that.
my remark about 17 digits suffice is only where multiplying 1pt or inputting a dimension with pt unit. WIth other units such ascm, it is false. But TeX truncates to 17 digits anyhow the input because it uses the same routine for inputting decimal numbers independently of the unit of dimension.
– jfbu
14 mins ago
notice that this is not the same as starting from a dimension, print it in pt unit withthe. Then Knuth algorithms make sure that the output (never more than 5 fractional digits) will reconstitute exactly the original dimension if used as input. This is not the same as using arbitrary user things like 0.22222 or 0.12345 or whatever which may or may not be precise enough.
– jfbu
7 mins ago
We have 65536 possible dimensions from 0 to 1pt (excluded), and we have 100000 fractional decimal numbers 0.abcde with 5 digits. Thus usingthewill leave 100000-65536=34464 strings of 5 digits which are never obtained asthe<something>. It may be for those strings of 5 digits that we increase the dimension by 1sp by adding more digits. I have not searched the most delicate example which maximises the number of 0s of the minimal addition provoking an increase by 1sp.
– jfbu
1 min ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f472385%2fexact-fraction-of-a-length%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Let's try this plain TeX test:
newdimentest
newdimenfixed
fixed=345pt
defdotest#1{test=#1fixed thetest -- numbertest par}
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
fixed=101pt
bigskip
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
bye

As you see, adding more decimal digits doesn't improve the result: from five digits on the result is the same. The last column is the value in scaled points.
The method with divide truncates, whereas dimexpr rounds. There may be a difference of 1 scaled point with the two methods (in this case).
Is 0.33333fixed better or worse than dimexprfixed/3relax? If you add flexible glue to fill the gaps the difference cannot be seen with the naked eye, because in the first case it amounts to 115 scaled points, which is less than 0.00062 mm.
You can try with fixed=maxdimen and the difference between the 0.333333 and divide methods is 5462sp, less than 0.03 mm.
Six digits versus five can make a small difference, depending on the number. But using seven or more is irrelevant.
"adding more decimal digits doesn't improve the result". It may change it, you need 17 decimal digits for stabilization in all cases.
– jfbu
2 hours ago
@jfbu Not with TeX. Using more than five decimal digits in a<factor>is a waste of time.
– egreg
2 hours ago
in fact our discussion is not precise. But try0.22222ptversus0.222222pt. Not the same thing.
– jfbu
2 hours ago
@jfbu I was talking about a<factor>not a<dimen>
– egreg
2 hours ago
?????*message{numberdimexpr0.22222dimexpr1ptrelaxrelax}gives14563and*message{numberdimexpr0.222222dimexpr1ptrelaxrelax}gives14564.
– jfbu
1 hour ago
|
show 7 more comments
Let's try this plain TeX test:
newdimentest
newdimenfixed
fixed=345pt
defdotest#1{test=#1fixed thetest -- numbertest par}
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
fixed=101pt
bigskip
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
bye

As you see, adding more decimal digits doesn't improve the result: from five digits on the result is the same. The last column is the value in scaled points.
The method with divide truncates, whereas dimexpr rounds. There may be a difference of 1 scaled point with the two methods (in this case).
Is 0.33333fixed better or worse than dimexprfixed/3relax? If you add flexible glue to fill the gaps the difference cannot be seen with the naked eye, because in the first case it amounts to 115 scaled points, which is less than 0.00062 mm.
You can try with fixed=maxdimen and the difference between the 0.333333 and divide methods is 5462sp, less than 0.03 mm.
Six digits versus five can make a small difference, depending on the number. But using seven or more is irrelevant.
"adding more decimal digits doesn't improve the result". It may change it, you need 17 decimal digits for stabilization in all cases.
– jfbu
2 hours ago
@jfbu Not with TeX. Using more than five decimal digits in a<factor>is a waste of time.
– egreg
2 hours ago
in fact our discussion is not precise. But try0.22222ptversus0.222222pt. Not the same thing.
– jfbu
2 hours ago
@jfbu I was talking about a<factor>not a<dimen>
– egreg
2 hours ago
?????*message{numberdimexpr0.22222dimexpr1ptrelaxrelax}gives14563and*message{numberdimexpr0.222222dimexpr1ptrelaxrelax}gives14564.
– jfbu
1 hour ago
|
show 7 more comments
Let's try this plain TeX test:
newdimentest
newdimenfixed
fixed=345pt
defdotest#1{test=#1fixed thetest -- numbertest par}
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
fixed=101pt
bigskip
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
bye

As you see, adding more decimal digits doesn't improve the result: from five digits on the result is the same. The last column is the value in scaled points.
The method with divide truncates, whereas dimexpr rounds. There may be a difference of 1 scaled point with the two methods (in this case).
Is 0.33333fixed better or worse than dimexprfixed/3relax? If you add flexible glue to fill the gaps the difference cannot be seen with the naked eye, because in the first case it amounts to 115 scaled points, which is less than 0.00062 mm.
You can try with fixed=maxdimen and the difference between the 0.333333 and divide methods is 5462sp, less than 0.03 mm.
Six digits versus five can make a small difference, depending on the number. But using seven or more is irrelevant.
Let's try this plain TeX test:
newdimentest
newdimenfixed
fixed=345pt
defdotest#1{test=#1fixed thetest -- numbertest par}
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
fixed=101pt
bigskip
dotest{0.3}
dotest{0.33}
dotest{0.333}
dotest{0.3333}
dotest{0.33333}
dotest{0.333333}
dotest{0.3333333}
dotest{0.33333333}
dotest{0.333333333}
test=fixed dividetest by 3 thetest -- numbertest
test=dimexprfixed/3relax thetest -- numbertest
bye

As you see, adding more decimal digits doesn't improve the result: from five digits on the result is the same. The last column is the value in scaled points.
The method with divide truncates, whereas dimexpr rounds. There may be a difference of 1 scaled point with the two methods (in this case).
Is 0.33333fixed better or worse than dimexprfixed/3relax? If you add flexible glue to fill the gaps the difference cannot be seen with the naked eye, because in the first case it amounts to 115 scaled points, which is less than 0.00062 mm.
You can try with fixed=maxdimen and the difference between the 0.333333 and divide methods is 5462sp, less than 0.03 mm.
Six digits versus five can make a small difference, depending on the number. But using seven or more is irrelevant.
edited 52 mins ago
answered 2 hours ago
egregegreg
716k8619003189
716k8619003189
"adding more decimal digits doesn't improve the result". It may change it, you need 17 decimal digits for stabilization in all cases.
– jfbu
2 hours ago
@jfbu Not with TeX. Using more than five decimal digits in a<factor>is a waste of time.
– egreg
2 hours ago
in fact our discussion is not precise. But try0.22222ptversus0.222222pt. Not the same thing.
– jfbu
2 hours ago
@jfbu I was talking about a<factor>not a<dimen>
– egreg
2 hours ago
?????*message{numberdimexpr0.22222dimexpr1ptrelaxrelax}gives14563and*message{numberdimexpr0.222222dimexpr1ptrelaxrelax}gives14564.
– jfbu
1 hour ago
|
show 7 more comments
"adding more decimal digits doesn't improve the result". It may change it, you need 17 decimal digits for stabilization in all cases.
– jfbu
2 hours ago
@jfbu Not with TeX. Using more than five decimal digits in a<factor>is a waste of time.
– egreg
2 hours ago
in fact our discussion is not precise. But try0.22222ptversus0.222222pt. Not the same thing.
– jfbu
2 hours ago
@jfbu I was talking about a<factor>not a<dimen>
– egreg
2 hours ago
?????*message{numberdimexpr0.22222dimexpr1ptrelaxrelax}gives14563and*message{numberdimexpr0.222222dimexpr1ptrelaxrelax}gives14564.
– jfbu
1 hour ago
"adding more decimal digits doesn't improve the result". It may change it, you need 17 decimal digits for stabilization in all cases.
– jfbu
2 hours ago
"adding more decimal digits doesn't improve the result". It may change it, you need 17 decimal digits for stabilization in all cases.
– jfbu
2 hours ago
@jfbu Not with TeX. Using more than five decimal digits in a
<factor> is a waste of time.– egreg
2 hours ago
@jfbu Not with TeX. Using more than five decimal digits in a
<factor> is a waste of time.– egreg
2 hours ago
in fact our discussion is not precise. But try
0.22222pt versus0.222222pt. Not the same thing.– jfbu
2 hours ago
in fact our discussion is not precise. But try
0.22222pt versus0.222222pt. Not the same thing.– jfbu
2 hours ago
@jfbu I was talking about a
<factor> not a <dimen>– egreg
2 hours ago
@jfbu I was talking about a
<factor> not a <dimen>– egreg
2 hours ago
?????
*message{numberdimexpr0.22222dimexpr1ptrelaxrelax} gives 14563 and *message{numberdimexpr0.222222dimexpr1ptrelaxrelax} gives 14564.– jfbu
1 hour ago
?????
*message{numberdimexpr0.22222dimexpr1ptrelaxrelax} gives 14563 and *message{numberdimexpr0.222222dimexpr1ptrelaxrelax} gives 14564.– jfbu
1 hour ago
|
show 7 more comments
I described how TeX inputs dimensions and handles units in https://tex.stackexchange.com/a/231281 and Why pdf file cannot be reproduced? and possibly at other locations, including some comments which are not always read.
I am using Plain TeX but of course it works exactly the same in LaTeX.
newdimenfixed
fixed 1pt
newdimentestA
newdimentestB
testA 0.33333587646484374fixed
testB 0.33333587646484375fixed
ifdimtestA = testB
The two dimensions are equal
else
The two dimensions are not equal
fi
bye
Outputs:

One needs 17 fractional digits to be certain that the dimension stabilizes (of course you get only 1sp possible difference after 5 fractional digits, because 1/10^5 < 1/65536, here in this example where one multiplies 1pt). And some things are counterintuitive, for example 0.33333 is enough but 0.22222 is not although it looks closer to 0.222222 than 0.33333 was to 0.333333.
It goes without saying that Knuth has programmed it exactly to fetch 17 fractional digits and not one more, because the theorem is that it will never change after that.
my remark about 17 digits suffice is only where multiplying 1pt or inputting a dimension with pt unit. WIth other units such ascm, it is false. But TeX truncates to 17 digits anyhow the input because it uses the same routine for inputting decimal numbers independently of the unit of dimension.
– jfbu
14 mins ago
notice that this is not the same as starting from a dimension, print it in pt unit withthe. Then Knuth algorithms make sure that the output (never more than 5 fractional digits) will reconstitute exactly the original dimension if used as input. This is not the same as using arbitrary user things like 0.22222 or 0.12345 or whatever which may or may not be precise enough.
– jfbu
7 mins ago
We have 65536 possible dimensions from 0 to 1pt (excluded), and we have 100000 fractional decimal numbers 0.abcde with 5 digits. Thus usingthewill leave 100000-65536=34464 strings of 5 digits which are never obtained asthe<something>. It may be for those strings of 5 digits that we increase the dimension by 1sp by adding more digits. I have not searched the most delicate example which maximises the number of 0s of the minimal addition provoking an increase by 1sp.
– jfbu
1 min ago
add a comment |
I described how TeX inputs dimensions and handles units in https://tex.stackexchange.com/a/231281 and Why pdf file cannot be reproduced? and possibly at other locations, including some comments which are not always read.
I am using Plain TeX but of course it works exactly the same in LaTeX.
newdimenfixed
fixed 1pt
newdimentestA
newdimentestB
testA 0.33333587646484374fixed
testB 0.33333587646484375fixed
ifdimtestA = testB
The two dimensions are equal
else
The two dimensions are not equal
fi
bye
Outputs:

One needs 17 fractional digits to be certain that the dimension stabilizes (of course you get only 1sp possible difference after 5 fractional digits, because 1/10^5 < 1/65536, here in this example where one multiplies 1pt). And some things are counterintuitive, for example 0.33333 is enough but 0.22222 is not although it looks closer to 0.222222 than 0.33333 was to 0.333333.
It goes without saying that Knuth has programmed it exactly to fetch 17 fractional digits and not one more, because the theorem is that it will never change after that.
my remark about 17 digits suffice is only where multiplying 1pt or inputting a dimension with pt unit. WIth other units such ascm, it is false. But TeX truncates to 17 digits anyhow the input because it uses the same routine for inputting decimal numbers independently of the unit of dimension.
– jfbu
14 mins ago
notice that this is not the same as starting from a dimension, print it in pt unit withthe. Then Knuth algorithms make sure that the output (never more than 5 fractional digits) will reconstitute exactly the original dimension if used as input. This is not the same as using arbitrary user things like 0.22222 or 0.12345 or whatever which may or may not be precise enough.
– jfbu
7 mins ago
We have 65536 possible dimensions from 0 to 1pt (excluded), and we have 100000 fractional decimal numbers 0.abcde with 5 digits. Thus usingthewill leave 100000-65536=34464 strings of 5 digits which are never obtained asthe<something>. It may be for those strings of 5 digits that we increase the dimension by 1sp by adding more digits. I have not searched the most delicate example which maximises the number of 0s of the minimal addition provoking an increase by 1sp.
– jfbu
1 min ago
add a comment |
I described how TeX inputs dimensions and handles units in https://tex.stackexchange.com/a/231281 and Why pdf file cannot be reproduced? and possibly at other locations, including some comments which are not always read.
I am using Plain TeX but of course it works exactly the same in LaTeX.
newdimenfixed
fixed 1pt
newdimentestA
newdimentestB
testA 0.33333587646484374fixed
testB 0.33333587646484375fixed
ifdimtestA = testB
The two dimensions are equal
else
The two dimensions are not equal
fi
bye
Outputs:

One needs 17 fractional digits to be certain that the dimension stabilizes (of course you get only 1sp possible difference after 5 fractional digits, because 1/10^5 < 1/65536, here in this example where one multiplies 1pt). And some things are counterintuitive, for example 0.33333 is enough but 0.22222 is not although it looks closer to 0.222222 than 0.33333 was to 0.333333.
It goes without saying that Knuth has programmed it exactly to fetch 17 fractional digits and not one more, because the theorem is that it will never change after that.
I described how TeX inputs dimensions and handles units in https://tex.stackexchange.com/a/231281 and Why pdf file cannot be reproduced? and possibly at other locations, including some comments which are not always read.
I am using Plain TeX but of course it works exactly the same in LaTeX.
newdimenfixed
fixed 1pt
newdimentestA
newdimentestB
testA 0.33333587646484374fixed
testB 0.33333587646484375fixed
ifdimtestA = testB
The two dimensions are equal
else
The two dimensions are not equal
fi
bye
Outputs:

One needs 17 fractional digits to be certain that the dimension stabilizes (of course you get only 1sp possible difference after 5 fractional digits, because 1/10^5 < 1/65536, here in this example where one multiplies 1pt). And some things are counterintuitive, for example 0.33333 is enough but 0.22222 is not although it looks closer to 0.222222 than 0.33333 was to 0.333333.
It goes without saying that Knuth has programmed it exactly to fetch 17 fractional digits and not one more, because the theorem is that it will never change after that.
answered 21 mins ago
jfbujfbu
47.2k66149
47.2k66149
my remark about 17 digits suffice is only where multiplying 1pt or inputting a dimension with pt unit. WIth other units such ascm, it is false. But TeX truncates to 17 digits anyhow the input because it uses the same routine for inputting decimal numbers independently of the unit of dimension.
– jfbu
14 mins ago
notice that this is not the same as starting from a dimension, print it in pt unit withthe. Then Knuth algorithms make sure that the output (never more than 5 fractional digits) will reconstitute exactly the original dimension if used as input. This is not the same as using arbitrary user things like 0.22222 or 0.12345 or whatever which may or may not be precise enough.
– jfbu
7 mins ago
We have 65536 possible dimensions from 0 to 1pt (excluded), and we have 100000 fractional decimal numbers 0.abcde with 5 digits. Thus usingthewill leave 100000-65536=34464 strings of 5 digits which are never obtained asthe<something>. It may be for those strings of 5 digits that we increase the dimension by 1sp by adding more digits. I have not searched the most delicate example which maximises the number of 0s of the minimal addition provoking an increase by 1sp.
– jfbu
1 min ago
add a comment |
my remark about 17 digits suffice is only where multiplying 1pt or inputting a dimension with pt unit. WIth other units such ascm, it is false. But TeX truncates to 17 digits anyhow the input because it uses the same routine for inputting decimal numbers independently of the unit of dimension.
– jfbu
14 mins ago
notice that this is not the same as starting from a dimension, print it in pt unit withthe. Then Knuth algorithms make sure that the output (never more than 5 fractional digits) will reconstitute exactly the original dimension if used as input. This is not the same as using arbitrary user things like 0.22222 or 0.12345 or whatever which may or may not be precise enough.
– jfbu
7 mins ago
We have 65536 possible dimensions from 0 to 1pt (excluded), and we have 100000 fractional decimal numbers 0.abcde with 5 digits. Thus usingthewill leave 100000-65536=34464 strings of 5 digits which are never obtained asthe<something>. It may be for those strings of 5 digits that we increase the dimension by 1sp by adding more digits. I have not searched the most delicate example which maximises the number of 0s of the minimal addition provoking an increase by 1sp.
– jfbu
1 min ago
my remark about 17 digits suffice is only where multiplying 1pt or inputting a dimension with pt unit. WIth other units such as
cm, it is false. But TeX truncates to 17 digits anyhow the input because it uses the same routine for inputting decimal numbers independently of the unit of dimension.– jfbu
14 mins ago
my remark about 17 digits suffice is only where multiplying 1pt or inputting a dimension with pt unit. WIth other units such as
cm, it is false. But TeX truncates to 17 digits anyhow the input because it uses the same routine for inputting decimal numbers independently of the unit of dimension.– jfbu
14 mins ago
notice that this is not the same as starting from a dimension, print it in pt unit with
the. Then Knuth algorithms make sure that the output (never more than 5 fractional digits) will reconstitute exactly the original dimension if used as input. This is not the same as using arbitrary user things like 0.22222 or 0.12345 or whatever which may or may not be precise enough.– jfbu
7 mins ago
notice that this is not the same as starting from a dimension, print it in pt unit with
the. Then Knuth algorithms make sure that the output (never more than 5 fractional digits) will reconstitute exactly the original dimension if used as input. This is not the same as using arbitrary user things like 0.22222 or 0.12345 or whatever which may or may not be precise enough.– jfbu
7 mins ago
We have 65536 possible dimensions from 0 to 1pt (excluded), and we have 100000 fractional decimal numbers 0.abcde with 5 digits. Thus using
the will leave 100000-65536=34464 strings of 5 digits which are never obtained as the<something>. It may be for those strings of 5 digits that we increase the dimension by 1sp by adding more digits. I have not searched the most delicate example which maximises the number of 0s of the minimal addition provoking an increase by 1sp.– jfbu
1 min ago
We have 65536 possible dimensions from 0 to 1pt (excluded), and we have 100000 fractional decimal numbers 0.abcde with 5 digits. Thus using
the will leave 100000-65536=34464 strings of 5 digits which are never obtained as the<something>. It may be for those strings of 5 digits that we increase the dimension by 1sp by adding more digits. I have not searched the most delicate example which maximises the number of 0s of the minimal addition provoking an increase by 1sp.– jfbu
1 min ago
add a comment |
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f472385%2fexact-fraction-of-a-length%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
dimexprlinewidth/3anddimexpr7linewidth/8work. However TeX uses scaled integers to represent dimensions, so technically0.3333333333333linewidthis more precise than TeX's representation oflinewidth/3. When you input a long decimal chain like that TeX will truncate that to a value it can represent.– Phelype Oleinik
3 hours ago
Actually, I didn't think about dimexpr. Mind putting that in an answer?
– David Woitkowski
3 hours ago
@PhelypeOleinik "a long decimal chain like that TeX will truncate that to a value it can represent" is misleading, it could be that no truncation can be exactly represented as an integer multiple of pt/65536.
– jfbu
3 hours ago
the most precise way to multiply by a fraction is
dimexprnumexpr A*<dimen>/B sprelax(where<dimen>is likelinewidthbut not10ptthen usedimexpr10ptrelaxin place of<dimen>)– jfbu
3 hours ago
@jfbu Agreed, unfortunate choice of words. On your second comment, why is that? Do you mind writing the answer explaining your comment, please?
– Phelype Oleinik
3 hours ago