Works, but I have a .0.0 that not supposed to be here.

  • 3
    I think the problem comes because the lower limit is negative. You may want to have a check on the function \pgfmathrandominteger. Aug 21, 2014 at 12:12
  • Sorry, but the hint does not actually solve the problem. And I can only guess where the problem is, so I can't write an answer based on this. Aug 21, 2014 at 12:27
  • I don't understand, using pgfmathrandominteger I have no more unwanted characters and the macro gives good results ? I agree with you the documentation speaks of positive values for random, then one can not considere there is a bug in random ...
    – Tarass
    Aug 21, 2014 at 17:42
  • You're right. Though, to me an answer should explain why with negative values it appears the unnecessary 0.0! The other method works, but it's a workaround. Aug 21, 2014 at 18:17
  • The question you want to answer is : why when I use the random command in a wrong way, it gives me something bad ? ;-)
    – Tarass
    Aug 21, 2014 at 18:35

2 Answers 2


From the PGF manual, section 90.2.6, page 942 (version 3.0.0)

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




that should produce no text, creates the following output

enter image description here

If a random number between –1 and 10 is needed, just use


This is to be considered a bug in the documentation.

  • It also could produce a random number between -1 and 10. It is sometimes usefull.
    – Tarass
    Jan 3, 2015 at 19:05
  • @Tarass Just shift the result: \pgfmathparse{random(1,12)-2}
    – egreg
    Jan 3, 2015 at 19:07
  • Ok but why not directly in the function itself?
    – Tarass
    Jan 3, 2015 at 19:09
  • 1
    @Tarass I guess it depends on the implementation; probably the input is put between 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.
    – egreg
    Jan 3, 2015 at 19:11
  • 2
    I don't think this "a bug in the documentation". It is just a bug. The function 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};
\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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .