Hello,

Today I came up against a strange problem where collisions were being encountered after less than 1mil iterations when attempting to use random.random().

After much digging, the problem was because I was casting my float to a string, and this was automatically rounding it.

Some explanation is given [1], but it still leaves me with questions.

>>> import random
>>> random.random()
0.33885573194811902
>>> x = random.random()
>>> x
0.88022393777095409
>>> print x
0.880223937771
>>> str(x)
'0.880223937771'
>>> print str(x)
0.880223937771
>>> repr(x)
'0.88022393777095409'
>>> str(repr(x))
'0.88022393777095409'

After painstakingly searching through documentation (including the lengthy one about floating points arithmetic), I was unable to find any explanation behind why the float is automatically rounded if str() is called on it.

Although I doubt this behavior would ever be changed, it would be nice to update the documentation to reflect this. I'm thinking a note underneath random.random() explaining that you have to use repr() and not str() in order to maintain floating point precision.

Thoughts?

Cal

[1] http://stackoverflow.com/questions/3481289/converting-a-python-float-to-a-string-without-losing-precision

http://docs.python.org/2/tutorial/floatingpoint.html

As stated before, I have already read this document.

This ticket is specifically about making users aware of this behaviour in the form of a documentation update on the random.random() docs.

The link you provided does not exactly make this very clear.

The `random` module docs are not the right place to add notes about general floating-point arithmetic behaviour.

Normally I would concur, but casting random.random() to a string is commonly used, and people aren't going to read the entire floating point arithmetic page to figure this out. And even if they do, that page still doesn't make it entirely obvious at first read.

Hopefully if anyone else is caught out by this, then they will see this thread at least :X

In fact it has been changed.  In Python3 you get:

>>> x = 0.88022393777095409
>>> x
0.8802239377709541
>>> str(x)
'0.8802239377709541'

Even in 2.7 you would get the above repr, not the one you showed.  This is because 2.7 and 3.3 use the "shortest repr" described in the floating point document, but 2.7 still uses the old rounding as the default str representation (for backward compatibility reasons).

While you could still make an argument for updating the 2.7 docs, I'm not sure it is worth it.  If you (or anyone) want to propose a patch, I would suggest that instead of adding a note to the random docs, that a glossary entry be added for 'floating point' which mentions it as a 2.7 limitation, and a link to that glossary entry from the random docs.

Many thanks for your lengthy response David.

Sorry, my initial bug report stated it was Python 2.7. The tests I performed were actually on Python 2.6.6.

I will take a look at how to contribute documentation updates, and once I've familiarized myself with it I'll submit a patch for review.

Thanks again

It is notable that this behaviour isn't described anywhere that I can find in the library manual or the reference manual.  As David says, it applies only to 2.7;  in 3.2 and later, `str` and `repr` are identical.

> a glossary entry be added for 'floating point' which mentions it as a
> 2.7 limitation

That could work.  I *really* don't think it should be linked to from the random docs, though;  this has absolutely nothing to do with the random module, except that the random module happens to contain functions that can produce floats.  Many other modules do that, too.

Another option would be to add the information somewhere in

http://docs.python.org/2/library/stdtypes.html#numeric-types-int-float-long-complex

That's why I suggested a glossary entry.  The relevant function description *does* contain the phrase "floating point", so a glossary link there would be reasonably natural.

I agree with Mark here. This isn't specific to random.random() and it's already covered elsewhere in the documentation.

Furthermore, I don't know why you're using str() on random.random(). There are better ways to get random strings, such as random.getrandbits() or os.urandom().

Recommend closing.

Actually, you do have a good point, this should have been using random.getrandbits really.