Warnings killing my performance
mwilson at the-wire.com
Sat Feb 7 16:16:44 CET 2004
In article <153fa67.0402070445.77121b2e at posting.google.com>,
kylotan at hotmail.com (Kylotan) wrote:
>"Terry Reedy" <tjreedy at udel.edu> wrote in message news:<mailman.1322.1076118385.12720.python-list at python.org>...
>> "Kylotan" <kylotan at hotmail.com> wrote in message
>> news:153fa67.0402060933.13840e8c at posting.google.com...
>> > And my second is, is there a quick way of taking an integer, shifting
>> > it left 13 bits (or multiplying by 2 ** 13, whatever), discarding any
>> > excess bits, and which won't cause a warning?
>> Have you tried masking off the upper 13 bits *before* the shift? So that
>> there is no overflow to warn about? Does this make any sense?
>Yes, it makes perfect sense... but unfortunately getting rid of that
>specific warning isn't enough. As noted in my first post, something is
>going through the warnings mechanism silently. I changed the code to
> """Given a 32-bit integer, return a float in [-1.0, 1.0]"""
> x = int(x) & 0x3FFFF # Preserve lowest 18 bits, to remove
> x = int(x << 13) ^ x # Shift left 13 bits.
> return (1.0-((x*(x*x*15731+789221)+1376312589)&0x7fffffff)/1073741824.0)
>And the profiler is still showing a call to warn() and warn_explicit()
>for each call to IntToRandFloat. I'm also having to preserve 18 bits
>instead of the desired 19 because the warning displays when I use 18,
>presumably because it includes the sign bit. However now I think I am
>damaging the distribution of the function (which is supposed to
>generate deterministic noise).
I notice that you're effectively cubing x, so you could
only keep 10 bits of it and be sure of avoiding 32-bit
overflow. Maybe a linear pseudo-random formula would save
some trouble. But it appears that random.randint also
generates invisible warnings.
The warnings go away with
x = long(x << 13) ^ x
More information about the Python-list