\documentclass{minimal}
\usepackage{tikz}
\begin{document}
\pgfmathparse{random(-5,5)}
\pgfmathresult
\end{document}
Works, but I have a .0.0
that not supposed to be here.
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It only takes a minute to sign up.
Sign up to join this communityFrom the PGF manual, section 90.2.6, page 942 (version 3.0.0)
random(x,y)
\pgfmathrandom{x,y}
This function takes zero, one or two arguments. If there are zero arguments, a uniform random number between 0 and 1 is generated. If there is one argument x, a random integer between 1 and x is generated. Finally, if there are two arguments, a random integer between x and y is generated. If there are no arguments, the PGF command should be called as follows:\pgfmathrandom{}
.
What the manual doesn't say is that the arguments should be non negative. Indeed the simple document
\documentclass{article}
\usepackage{tikz}
\begin{document}
\pgfmathparse{random(-1,10)}
\end{document}
that should produce no text, creates the following output
If a random number between –1 and 10 is needed, just use
\pgfmathparse{random(1,12)-2}
This is to be considered a bug in the documentation.
0
and .0
to shave off the decimal part, but in this case a minus sign will break the macros. This could be a feature request: first random
normalizes the input to be positive and then subtracts the correct value from the result.
random
with two arguments calls \pgfmathrandominteger
. So either \pgfmathrandominteger
should check both its arguments are integers or the random
function should check its arguments before calling \pgfmathrandominteger
. No prizes for guessing whose fault that is ;)
Jan 4, 2015 at 15:44
I found something about this:
Firstly, pgf treats any calculation result as floating point number:
\pgfmathsetmacro{\a}{1 + 1};
\pgfmathsetmacro{\b}{-1};
\pgfmathsetmacro{\c}{1};
\draw (\px, \py) circle(2) node[anchor=north west]{\a,\b,\c};
So, this will produce 2.0, -1.0, 1
, respectively (-1
is treated as calculating the negative of 1
).
Then, passing floating point to random
will result in .0
because random
only takes the integer part.
Thus, we just use random(int(-10), int(10))
, then the .0
disappears.
\pgfmathrandominteger
.pgfmathrandominteger
I have no more unwanted characters and the macro gives good results ? I agree with you the documentation speaks of positive values forrandom
, then one can not considere there is a bug inrandom
...random
command in a wrong way, it gives me something bad ? ;-)