Tim Peters added the comment:
[Serhiy Storchaka]
> ... I want to say that double rounding causes not
> only bias from ideal distribution, but a difference
> between platforms
That's so, but not too surprising. On those platforms users will see
differences between "primitive
Tim Peters added the comment:
Hmm. Looks like the answer to my question came before, via "Custom collection
can has non-standard behavior with negative indices." Really? We're worried
about a custom collection that assigns some crazy-ass meaning to a negative
index appl
Tim Peters added the comment:
I have a question about this new snippet in choice():
+if i == n and n > 0:
+i = n - 1
What's the purpose of the "and n > 0" clause? Without it, if i == n == 0 then
i will be set to -1, which is just as good as 0 for t
Tim Peters added the comment:
[Raymond]
> I can't say that I feel good about making everyone pay
> a price for a problem that almost no one ever has.
As far as I know, nobody has ever had the problem. But if we know a bug
exists, I think it's at best highly dubious to wait fo
Tim Peters added the comment:
> Anyway, if we modify random.py, the generated
> numbers should be different, no?
Not in a bugfix release. The `min()` trick changes no results whatsoever on a
box that doesn't do double-rounding.
On a box that does do double-rounding, the only di
Tim Peters added the comment:
Victor, don't ask me, look at the code: the random.choice() implementations in
Python 2 and Python 3 have approximately nothing in common, and "the bug" here
should already be impossible in Python 3 (but I can't check that, because I
don&#x
Tim Peters added the comment:
Victor, if people want to use getrandbits(), we should backport the Python3
code, not reinvent it from scratch.
Note too Mark's comment: "There are several places in the source where
something of the form `int(i * random.random())` is used". Th
Tim Peters added the comment:
> It skews the distribution a tiny little bit, ...
But it doesn't - that's the point ;-)
If double-rounding doesn't occur at all (which appears to be the case on most
platforms), absolutely nothing changes (because min(int(random() * N), N-1) ==
Tim Peters added the comment:
Mark, closest I could find to a substantive SSE-vs-fsum report is here, but it
was closed (because the fsum tests were changed to ignore the problem ;-) ):
http://bugs.python.org/issue5593
--
___
Python tracker
<h
Tim Peters added the comment:
I suppose the simplest "fix" would be to replace relevant instances of
int(random() * N)
with
min(int(random() * N), N-1)
That would be robust against many kinds of arithmetic quirks, and ensure that
platforms with and without such quirks would, if
Tim Peters added the comment:
Thanks, Mark! That's convincing. Just as a sanity check, I tried all ints in
1 through 4 billion (inclusive) against 1. - 2.**-52, with no failures.
Although that was with ad hoc Python code simulating various rounding methods
using scaled integers, s
Tim Peters added the comment:
Raymond, there are (at least) two bugs here:
1. The original bug report. Nobody yet has any plausible theory for what went
wrong there. So "won't fix" wouldn't be appropriate. If the OP can't provide
more information, neither a rep
Tim Peters added the comment:
Mark, note that the sequence in the OP's original report only contains 35
elements. That, alas, makes "double rounding" irrelevant to this bug report.
That is, while random.choice() can suffer double-rounding surprises in _some_
cases, it can
Tim Peters added the comment:
Should also note that double rounding cannot account for the _original_ symptom
here. Double rounding surprises on Intel chips require an exact product at
least 65 bits wide, but the OP's sequence is far too short to create such a
product. (Steven's
Tim Peters added the comment:
I'm guessing this is a "double rounding" problem due to gcc not restricting an
Intel FPU to using 53 bits of precison:
> In binary, (2**53-1)/2**53 * 2049 is:
>
> 0.1
> times
> 1
Tim Peters added the comment:
Thanks for the legwork, Steven!
So far it looks like a gcc bug when using -m32 (whether ints, longs and/or
pointers are 4 or 8 bytes _should_ make no difference to anything in Jason
Swails's C example).
But it may be a red herring anyway: there'
Tim Peters added the comment:
Steven, there's something wrong with the arithmetic on your machine, but I
can't guess what from here (perhaps you have a non-standard rounding mode
enabled, perhaps your CPU is broken, ...).
In binary, (2**53-1)/2**53
Tim Peters added the comment:
FYI, where x = 1.0 - 2.**-53, I believe it's easy to show this under IEEE
double precision arithmetic:
For every finite, normal, double y > 0.0,
IEEE_multiply(x, y) < y
under the default (nearest/even) rounding mode. That implies
int(x*
Tim Peters added the comment:
> random() may return 1.0 exactly
That shouldn't be possible. Although the code does assume C doubles have at
least 53 bits of mantissa precision (in which case it does arithmetic that's
exact in at least 53 bits - cannot round up to 1.0; but _could
Tim Peters added the comment:
Good catch, Mark!
--
___
Python tracker
<http://bugs.python.org/issue24059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
I don't care about the ULP. I don't care about exactly reproducing
floating-point results across releases either, but I'd bet someone else does ;-)
--
___
Python tracker
<http://bugs.pyt
Tim Peters added the comment:
FYI, my results match Serhiy's, on Windows, under Pythons 3.4.2 and 2.7.8.
It's not surprising to me. Since IEEE 754 standardized sqrt, most vendors
complied, delivering a square root "as if infinitely precise" with one anally
correct round
Tim Peters added the comment:
Nothing should ever crash the interpreter :-) So this is a thoroughly
legitimate bug report.
However, there's no way to guess whether _this_ crasher is easy to fix, or next
to impossible. Without a test program to provoke the error, there's little
Tim Peters added the comment:
Thanks, Terry! Absolutely agreed: a logical error is an error, and will bite
us eventually, regardless of whether it does so today. I'm very glad the
researchers went to all the trouble to analyze thi
Tim Peters added the comment:
Since it's impossible to trigger the error on any current machine anyway (no
machine has enough memory), increasing the size of the stack would be absurd.
If you read the paper, they note that this is what the Java folks first did
(they changed this pa
Tim Peters added the comment:
@Benjamin, bless you for changing their "n-1 > 0" to "n > 1", and for adding
parentheses to make the intended grouping obvious instead of a puzzle, and for
swapping the addends on the RHS of the new
New submission from Tim Peters:
Some researchers found an error in the logic of merge_collapse, explained here,
and with corrected code shown in section 3.2:
http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/
This affects all current
Tim Peters added the comment:
This is easy: Cowlishaw is wrong on this one, but nothing can be done about it
;-)
Confusion arises because most people think of 0**0 as a value (where it
certainly must be 1) while others seem to view it as some kind of shorthand for
expressing a limit (as the
Tim Peters added the comment:
Floor division on floats is an unattractive nuisance and should be removed,
period - so there ;-)
But short of that, I favor leaving it alone. Whose life would be improved by
changing it to return an int? Not mine - and doing so anyway is bound to break
Tim Peters added the comment:
This should remain closed. It's "a feature" that doctest demands exact textual
equality, and that the only way to override this is with one of the `#doctest:`
flags. "What you see is what you get - exactly" is one of doctest's
fun
Tim Peters added the comment:
Sorry, Mark - I took a true thing and careleslly turned it into a false thing
;-)
It's math.floor(a_float) that returns an int in Py3, not floor division of
floats. So, yup, no real problem with returning -0.0 after all; it's just that
it can't
Tim Peters added the comment:
To be clear, I agree -0.0 is "the correct" answer, and -1.0 is at best
defensible via a mostly-inappropriate limit argument. But in Py3 floor
division of floats returns an integer, and there is no integer -0. Nor, God
willing, will there ever be ;-)
Tim Peters added the comment:
I'm OK with -1, but I don't get that or -0.0 on 32-bit Windows Py 3.4.1:
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more i
Tim Peters added the comment:
+1. I agree it's a bug, that the diagnosis is correct, and that the patch will
fix it :-)
--
___
Python tracker
<http://bugs.python.org/is
Tim Peters added the comment:
Alexander, I don't see a need to make everything a one-liner. Dealing with a
mix of dates and datetimes is easily sorted out with an `if` statement, like
def func(thedate):
if isinstance(thedate, datetime.datetime):
thedate = thedate.date()
Tim Peters added the comment:
Was the title of this meant to be
"datetime.date() should accept a datetime.datetime as init parameter"
instead? That's what the example appears to be getting at.
If so, -1. Datetime objects already have .date(), .time(), and .timetz()
met
Tim Peters added the comment:
@eddygeek, I'd still call something so unintuitive "a bug" - it's hard to
believe this is the _intended_ way to get it to work. So I'd keep this open
until someone with better know
Tim Peters added the comment:
I'm sympathetic, but I don't see a good solution here without using
incompatible code.
ndiff was built to generate "the highest quality diff possible", for text
written and edited by humans, where "quality" is measured by hu
Tim Peters added the comment:
I have no idea what was done to pickle for Python3, but this line works for me
to unpickle a Python2 protocol 2 datetime pickle under Python3, where P2 is the
Python2 pickle string:
pickle.loads(bytes(P2, encoding='latin1'), encoding='bytes
Tim Peters added the comment:
I'm afraid "microoptimizations" aren't worth measuring to begin with, since,
well, they're "micro" ;-) Seriously, switch compilers, compilation flags, or
move to a new release of a single compiler, and a micro-optimization ofte
Tim Peters added the comment:
Of course pickles come with overheads too - don't be tedious ;-) The point is
that the guts of the datetime pickling is this:
basestate = PyBytes_FromStringAndSize((char *)self->data,
_PyDateTime_DATETIME_DATASIZE
Tim Peters added the comment:
Yup, it's definitely more than 8 bytes. In addition to the comments you
quoted, an in-memory datetime object also has a full Python object header, a
member to cache the hash code, and a byte devoted to saying whether or not a
tzinfo member is present.
Gue
Tim Peters added the comment:
A note from Guido, from about 2 years ago:
https://mail.python.org/pipermail/python-dev/2012-July/121127.html
"""
TBH, I think that adding nanosecond precision to the datetime type is
not unthinkable. You'll have to come up with some clever ba
Tim Peters added the comment:
One more useless ;-) data point, from Macsyma:
? acosh;
-- Function: acosh ()
- Hyperbolic Arc Cosine.
I don't like "area" - while accurate, nobody else uses it. Gratuitous novelty
is no virtue ;-) I like "inverse" better than &
Tim Peters added the comment:
BTW, note that the idea "successful lookaround assertions match an empty
string" isn't just a figure of speech: it's the literal truth, and - indeed -
is key to understanding what happens here. You can see this by adding some
capturi
Tim Peters added the comment:
>> (?<=a)(?<=a)(?<=a)(?<=a)
> There are four different points.
> If a1 before a2 and a2 before a3 and a3 before a4 and a4
> before something.
Sorry, that view doesn't make any sense. A successful lookbehind assertion
matches the e
Tim Peters added the comment:
I would not call this a bug - it's just usually a silly thing to do ;-)
Note, e.g., that p{N} is shorthand for writing p N times. For example, p{4} is
much the same as (but not exactly so in all cases; e.g., if `p` happens to
contain a capturing group
Tim Peters added the comment:
I'm more puzzled by why `__hash__()` here bothers to call `hex()` at all. It's
faster to hash the underlying int as-is, and collisions in this specific
context would still be rare.
@Josh, note that there's nothing bad about getting sequentia
Tim Peters added the comment:
@pacosta, if Mark's answer is too abstract, here's a complete session showing
that the result you got for gcd(2.7, 107.3) is in fact exactly correct:
>>> import fractions
>>> f1 = fractions.Fraction(2.7)
>>> f2 = frac
Tim Peters added the comment:
The gcd function is documented as taking two integer arguments:
"Return the greatest common divisor of the integers a and b."
I'm -0 on generalizing it, and also -0 on burning cycles to enforce the
restriction to integer arguments.
Tim Peters added the comment:
I suggest this needs a measurable goal, like "minimize expected-case time" or
"minimize worst-case time". "Use a state of the art implementation" isn't a
measurable goal - it's an abstract wish with no measurable mer
Tim Peters added the comment:
Crytpo generators are a whole different world, and I wouldn't listen to anyone
save a bona fide expert in that field. Plausible: the "hardest thing" OpenSSL
has to do is generate secure RSA keys. But the bit length of an RSA key can't
be
Tim Peters added the comment:
> Thanks for the explanation. It's much clearer now.
Maybe, but it's also overblown - LOL ;-) That is, no matter what the starting
seed, the user will see a microscopically tiny span of the Twister's entire
period. So all those "prova
Tim Peters added the comment:
[pitrou]
> I still find it difficult to understand where is the said danger.
The theoretical properties that make the Twister so attractive were all proved
based on mathematical analysis of its entire period. The only way to get at
the whole period is to al
Tim Peters added the comment:
[haypo]
> No user complained past years.
Raymond said "We've previously had this problem with MT (since resolved, where
it is was landed in a very non-random zone)." Do you believe he was wrong?
> I don't think that we should worry so m
Tim Peters added the comment:
[haypo]
> What is an uninteresting sequence? What are the problem of these
> sequences?
A sequence that would greatly surprise a user. For example, if you generate
32-bit ints from the Twister in one obvious way, there are starting places
where you'
Tim Peters added the comment:
[neologix]
> some code spawns many processes per second (see recent
> discussion on python-dev).
But that doesn't imply they're seeding the random module many times per second,
right? Seeding isn't part of Python initialization, it's part
Tim Peters added the comment:
+1, although it could really use a comment explaining that 2500 bytes was
chosen to be >= the Twister's 19937 internal bits of state. Otherwise it looks
as arbitrary as 32 did ;-)
--
nosy: +tim.peters
__
Tim Peters added the comment:
@asvetlov, glad this fixes crashes in aiohttp library tests too, but I hadn't
heard about that before. Is there an open bug report about it on this tracker
(so we can close it)?
--
___
Python tracker
Changes by Tim Peters :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue21435>
___
Tim Peters added the comment:
finalize42.patch includes a test case. If nobody objects within a few hours,
I'll commit it.
--
Added file: http://bugs.python.org/file35187/finalize42.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Tim Peters :
--
title: Segfault with cyclic reference and asyncio.Future -> Segfault in gc with
cyclic trash
___
Python tracker
<http://bugs.python.org/issu
Changes by Tim Peters :
--
assignee: -> tim.peters
___
Python tracker
<http://bugs.python.org/issue21435>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
xxx.py provokes a closely related death on my box, in a debug build (where
0xdbdbdbdb happened to be an invalid memory address). There are no imports so
asyncio is definitely off the hook ;-)
The code is senseless, and changing just about anything makes the
Tim Peters added the comment:
finalize4.patch repairs the comment typos, adds a new comment, and removes the
unused `old` argument. I think the code is ready to ship with this.
I still don't have a reasonably simple fails-before-works-after test case.
But that doesn't both
Tim Peters added the comment:
OK! This has nothing to do with the trashcan mechanism.
The list object whose gc_next gets stomped on is not itself in a cycle. It's
an empty list, and just happens to be a value in a dict, which in turn is a
value in another dict. Its refcount falls to
Tim Peters added the comment:
Antoine, the carets are a symptom of my flu. My fingers jump on the keyboard
from sneezing and coughing, and my eyes are watery so I don't see the typos.
But I believe that can be fixed ;-)
I doubt the trashcan cruft is responsible, for several reason
Tim Peters added the comment:
Guido, it's best if Antoine reviewed it - he wrote the relevant PEP, and the
code I'm changing. I'm sure he'll agree it's a necessary change.
About the rarity of the bug, not only do the refcounts and cyclic structure
have to be just ri
Tim Peters added the comment:
Oh, fudge. There are other failure modes in the test suite after I took out
the seemingly redundant incref/decref pair. Adding it back in finalize3.patch.
--
Added file: http://bugs.python.org/file35167/finalize3.patch
Tim Peters added the comment:
Attaching a marginally cleaner version of the patch, with comments.
I think it's clear this addresses _some_ real fatal problems, but they're rare:
for a problem to show up, it has to be the case that finalize() reduces the
refcount of the current o
Tim Peters added the comment:
A bit more info: recall that, when deleting a type object (for class B), the
previous (list) object's gc_next got overwritten with NULL. The new info: its
(the list object's) gc_refs also changed from GC_TENTATIVELY_UNREACHABLE to
GC_UNTRACKED,
Tim Peters added the comment:
Sorry for the earlier noise. I'm fighting a flu and my head is mush :-(
Anyway, this doesn't look obvious. We get to this point:
if (Py_REFCNT(op) == 1) {
/* op will be destroyed */
gc = gc-&
Tim Peters added the comment:
Ah, fudge - I think I forgot that these circular lists also have dummy heads,
in which case it's A Good Thing "the first element" is skipped, and it should
be impossible for one to become physically empty (the dummy header should
always survive
Tim Peters added the comment:
Also noting that the loop "looks funny" because it appears never to process the
first element in the input list (unless the input list contains only one
element). That is, the loop starts by processing the second element in the
list, and exits as
Tim Peters added the comment:
Noting that in a Windows debug build, at death gc is 0xdbdbdbdb, so we are in
reading up free'd memory (0xdb is pymalloc's "dead byte" marker).
--
___
Python tracker
<http://bug
Tim Peters added the comment:
Thought question: suppose finalize_garbage() is called with a collectable list
all of whose members are in fact going to be destroyed?
I don't see how the loop iteration logic could reliably work then. For
concreteness, suppose there's only object -
Tim Peters added the comment:
Guido, that's no good. The outer loop is traversing a doubly-linked circular
list, and it should be flatly impossible for gc to ever be NULL - the list
structure is insanely damaged if any gc_next or gc_prev field reachable from it
is NULL (gc always comes
Tim Peters added the comment:
There's no way to influence finalization order for objects in cycles, and there
never was. So nothing actually changed in that respect ;-) What did change is
that Python used to forcibly break many module-level cycles in a way that just
happened to resu
Tim Peters added the comment:
I don't see a way to test it either, but it's easy enough to prove it's correct
;-) That is, looks good to me!
--
nosy: +tim.peters
___
Python tracker
<http://bugs.pyt
Tim Peters added the comment:
After more thought, I don't think the user can do anything to influence
finalization order in cases like this, short of adding "del" statements (or
moral equivalents) to break cycles before the interpreter shuts down.
Fine by me ;-) Something C
Tim Peters added the comment:
I think Antoine is right on all counts. The most surprising bit may be that p,
c, and c2 are in reference cycles, but - surprising or not - that's always been
true. The reason "it worked" before 3.4 is that CPython happened to break the
cycle
Changes by Tim Peters :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue21351>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
Just noting that, for me, the problem goes away if
del c, c2
is added as the last line of the test. This suggests the problem is due to
changes in end-of-life module cleanup.
Without that line, I see 3 kinds of output:
1.
del child
del child
del parent
parent
Tim Peters added the comment:
Russell, I'm still looking for a sufficiently compelling "use case" here:
something tangible and useful that can be done with the new function that can't
be easily done now.
"I plan to write a web API that accepts a word, 'doge&#x
Tim Peters added the comment:
I wonder whether this new function would attract any users, given that the user
already has control over the smallest ratio that will be accepted, and over the
maximum number of close matches returned. That's always been sufficient for me.
What useful th
Tim Peters added the comment:
Comparison can certainly trigger a recursion error if the sequences contain no
(or few) matching non-junk elements, but contain many "almost matching"
elements. If the sequences have lengths M and N, recursion can go as deep as
2*min(M, N) then.
Now i
Tim Peters added the comment:
Yup, agreed with all: ValueError makes a lot more sense, but the change
shouldn't be backported.
--
___
Python tracker
<http://bugs.python.org/is
Tim Peters added the comment:
Steven, no objection here.
--
___
Python tracker
<http://bugs.python.org/issue21183>
___
___
Python-bugs-list mailing list
Unsub
Tim Peters added the comment:
The first footnote in the docs explain this:
Examples containing both expected output and an
exception are not supported. Trying to guess where
one ends and the other begins is too error-prone,
and that also makes for a confusing test.
So, sorry
Tim Peters added the comment:
In the absence of Guido here, I'll channel him ;-) "The problem" with oddball
platforms has been that some require major changes in many parts of the
interpreter, and then all the added cruft complicates life for every
maintainer, while few peo
Tim Peters added the comment:
[Nick]
> - deprecate aware time() entirely (raises the thorny question of what to
> return from .time() on an aware datetime() object)
aware_datetime_object.time() already returns a naive time object. The thorny
question is what .timetz() should return -
Tim Peters added the comment:
Excellent idea! But then we should change bool(0.1) to be False too ;-)
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue20
Tim Peters added the comment:
This is expected. "global" has only to do with the visibility of a name within
a module; it has nothing to do with visibility of mutations across processes.
On a Linux-y system, executing Pool(3) creates 3 child processes, each of which
sees a read-
Tim Peters added the comment:
I've haven't yet seen anyone complain about the inability to compare None
except in the specific context of sorting. If it is in fact specific to
sorting, then this specific symptom and "the problem" are in fact the same
thing ;-)
Tim Peters added the comment:
They certainly should _not_ be swapped, as explained clearly in the message
following the one you referenced. For the first half:
if self._lock.acquire(0):
succeeds if and only if the lock is not held by _any_ thread at the time. In
that case, the lock
Tim Peters added the comment:
1. I'm sync'ing with north-america.pool.ntp.org. But the docs on my box say
"Your clock is typically updated once a week", and I believe it.
2. I just ran Zach's program again, with the same Python, and _this_ time
'time'
Tim Peters added the comment:
I'm not sanguine about fixing any of this :-( The Microsoft docs are awful,
and the more web searches I do the more I realize that absolutely everyone is
confused, just taking their best guesses.
FYI, here are results from your new program on my 32-bit Vist
Tim Peters added the comment:
@Liam, try using the "decimal" module instead. That follows rules much like
the ones people learn as kids.
>>> from decimal import Decimal as D
>>> D("0.1") * 3 # decimal results are computed exactly
Decimal('
Tim Peters added the comment:
FYI, this person seems to have made a career ;-) of making sense of the Windows
time functions:
http://stackoverflow.com/questions/7685762/windows-7-timing-functions-how-to-use-getsystemtimeadjustment-correctly
and their site:
http://www.windowstimestamp.com
Tim Peters added the comment:
@haypo, I've read the PEP and it has great ideas. What I'm wondering is
whether they've been implemented "correctly" in the relevant cases on Windows
here. That Zach see a resolution of 0.0156001 on Windows isn't plausibly a
ques
901 - 1000 of 1332 matches
Mail list logo
