Tim Peters added the comment:
[Marc-Andre]
> BTW: I wonder how long it's going to take before
> someone figures out that our merge sort based
> list.sort() is vulnerable as well... its worst-
> case performance is O(n log n), making attacks
> somewhat harder.
I would
Tim Peters added the comment:
- Tuple objects don't currently reserve space to store their hash code, so it's
likely this would increase the size of every tuple.
- It's unclear to me which natural use patterns would actually enjoy a major
speed boost. Note that dicts remember
Tim Peters added the comment:
About thread state, the C standard is no help. That's an OS decision. All
OSes I'm aware of do save/restore FPU state across thread switches. Doesn't
mean all OSes do, just that I don't know of an exception.
-
Tim Peters added the comment:
Terry, I had no intention here at all - had nothing to do with unified_diff.
Would have to look at the history to see who added it, and ask them. That
said, the very name "unified_diff" suggests someone did intend to mimic _some_
system'
Tim Peters added the comment:
Raymond, Mark pointed to the footnote explaining the first result. As to the
second, Kahan tried his best, but I'm afraid nobody can make me care about the
sign bit on a zero ;-) Whatever Mark thought best is fine
Tim Peters <[EMAIL PROTECTED]> added the comment:
Strongly doubt this has anything to do with random number generation.
Python maintains a freelist for float objects, which is both unbounded
and immortal. Instead of doing "data[i] = random()", do, e.g., "data[i]
= float(
Tim Peters <[EMAIL PROTECTED]> added the comment:
They stayed alive simultaneously because you stored 100 million of them
simultaneously in a list (data[]). If instead you did, e.g.,
for i in xrange(1):
x = random()
the problem would go away -- then only two float objec
Tim Peters <[EMAIL PROTECTED]> added the comment:
Float objects also require, as do all Python objects, space to hold a
type pointer and a reference count. So each float object requires at
least 16 bytes (on most 32-bit boxes, 4 bytes for the type pointer, 4
bytes for the refcount, + 8
Tim Peters <[EMAIL PROTECTED]> added the comment:
This isn't "a bug", since it's functioning as documented and designed.
Read note 1 in the "date Objects" section of the reference manual,
explaining the meaning of "date2 = date1 + timedelta":
"
Tim Peters <[EMAIL PROTECTED]> added the comment:
If you think using 16 (when possible) will stop complaints, think again
;-) For example,
>>> for x in 0.07, 0.56:
... putatively_improved_repr = "%.16g" % x
... assert float(putatively_improved
Tim Peters <[EMAIL PROTECTED]> added the comment:
The error message is correct. In the Gregorian calendar, years
divisible by 100 are not leap years, unless they're also divisible by
400. So 2000, 2400, 2800, ..., are leap years, but 2100, 2200, 2300,
2500, 2600, 2700, 2900, ... a
Tim Peters <[EMAIL PROTECTED]> added the comment:
About (2**52-1)*2.**(-1074): same outcome under Cygwin 2.5.1, which is
presumably based on David Gay's "perfect rounding" code. Cool ;-)
Under the native Windows 2.5.1:
>>> x = (2**52-1)*2.**(-1074)
>>>
Tim Peters <[EMAIL PROTECTED]> added the comment:
I'm afraid you missed the joke ;-) While you believe spaces are
required on both sides of an em dash, there is no consensus on this
point. For example, most (but not all) American authorities say /no/
spaces should be used. That
Tim Peters <[EMAIL PROTECTED]> added the comment:
Mark, I don't currently have a machine with SVN and a compiler
installed, so can't play with patches. I just want to note here that,
if you're concerned about speed, it would probably pay to eliminate all
library call
Tim Peters <[EMAIL PROTECTED]> added the comment:
Mark, changing API is something to avoid after beta cycles begin (so,
e.g., it's late in the game to /add/ a new API, like a new method for
complex summation). But there's no particular reason to fear changing
implementation f
Tim Peters <[EMAIL PROTECTED]> added the comment:
I doubt this is a bug in Python. It's more likely an error (one or more
;-)) in the logic of the script, triggered by the inherently
unpredictable order of set iteration.
Some evidence: I added a `.counter` member to the Sequence
Tim Peters <[EMAIL PROTECTED]> added the comment:
Vadim, to see how memory addresses change, simply add something like
print "id", id(self)
to Sequence.__init__. On Windows (Vista, Python 2.5.1), I see different
addresses printed each time the program is run. Then, as
Tim Peters <[EMAIL PROTECTED]> added the comment:
As the doctest docs say,
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.
Sinc
Tim Peters <[EMAIL PROTECTED]> added the comment:
> Anything in obmalloc that is not arena space should continue to come
> from malloc, I believe.
Sorry, but I don't understand why arena space should be different. If a
platform's libc implementers think mmap should b
Tim Peters <[EMAIL PROTECTED]> added the comment:
I have to admit that if Python /didn't/ know better than platform libc
implementers in some cases, there would be no point to having obmalloc
at all :-(
What you (Martin) suggest is reason
Tim Peters <[EMAIL PROTECTED]> added the comment:
No thought went into picking random.random in the test -- it was just a
random ;-) choice. Amaury's analysis of the source of non-determinism
is on target, and the easiest fix is to pick a coded-in-Python function
to pickle instead.
Tim Peters <[EMAIL PROTECTED]> added the comment:
Amaury, yes, it would be nice if pickle were more reliable here. But
that should be the topic of a different tracker issue. Despite the
Title, this issue is really about sporadic pickletools.py failures, and
the pickletools tests are try
Tim Peters <[EMAIL PROTECTED]> added the comment:
BTW, note that the Title of this issue is misleading:
pickle.whichmodule() uses object identity ("is":
if ... getattr(module, funcname, None) is func:
) to determine whether the given function object is supplied by a
modu
Tim Peters <[EMAIL PROTECTED]> added the comment:
Not a bug. Try (future - now).seconds instead so that the timedelta is
positive. As explained in the docs, a negative timedelta is normalized
so that only the .days attribute is negative, and, as the docs also say,
"normalization
Tim Peters added the comment:
Note that nothing in obmalloc is _intended_ to be thread-safe. Almost all
Python API functions make the caller responsible for serializing calls (which
is usually accomplished "by magic" via the GIL). This includes calls to all
facilities supplied b
Tim Peters added the comment:
Amaury, I have no real idea what your "No, the description above says it: ..."
is a response to, but if it's to my point that obmalloc is not intended to be
thread-safe, it's not addressing that point. Any case in which another thread
Tim Peters added the comment:
Just noting there are ways to trick the macro into reading a thing once. For
example, embed something like a
((x = arenas[(POOL)->arenaindex].address) || 1)
clause early on & refer to x later (where x is some file-scope new variable).
obmalloc is not i
Tim Peters added the comment:
Right, I already agreed it would be fine to fix this if it's cheap ;-)
I didn't give any real thought to the macro solution, but that's fine by me
too. It would be best to embed the assignment in a _natural_ place, though;
like
Tim Peters added the comment:
> `x` should be a local variable. ... assembler code will be smaller.
??? It should make no difference to an optimizing compiler. Lifetime analysis
(even if it's feeble) should be able to determine that all uses are purely
local, with no need to store t
Tim Peters added the comment:
Whatever works best. Unsure what you mean by "global", though, because it's
not a C concept. File-scope variables in C can have internal or external
linkage; to get internal linkage, so that lifetime analysis is effective
without needing (r
Tim Peters added the comment:
Cool! Python has a long history of catering to feeble compilers too ;-), so
using function locals is fine. Speed matters more than obscurity here.
--
___
Python tracker
<http://bugs.python.org/issue8
Tim Peters added the comment:
At heart, this is really the same kind of thing that eventually prodded Python
into adopting David Gay's burdensome ;-) code for correctly rounded
double<->string I/O conversions. We could similarly take on porting and
maintaining KC Ng's fdlibm
Tim Peters added the comment:
I find this whole discussion to be hilarious ;-)
"Approximate upper bound" is gibberish - "upper bound" is a crisp concept that
means what it says. It's not necessarily true that an upper bound is
inaccurate - it may be exactly r
Tim Peters added the comment:
There is nothing you can do to repr() that's sufficient by itself to
ensure eval(repr(x)) == x.
The other necessary part is correctly rounded float /input/ routines.
The 754 standard does not require correctly rounding input or output
routines. It does re
Tim Peters added the comment:
Again, without replacing float input routines too, this is /not/ good
enough to ensure eval(repr(x)) == x even across just 100%-conforming 754
platforms.
It is good enough to ensure (well, assuming the code is 100% correct)
eval(repr(x)) == x across conforming 754
Tim Peters added the comment:
[Raymond]
> ...
> NaNs in particular are a really
> difficult case because our equality testing routines
> have a fast path where identity implies equality.
Works as intended in 2.5; this is Windows output:
1.#INF
>>> nan = inf - inf
>>
Tim Peters added the comment:
[Guido]
> ... We can just say that Python
> won't work correctly unless your float input routine is rounding
> correctly; a unittest should detect whether this is the case.
Sorry, but that's intractable. Correct rounding is a property that
need
Tim Peters added the comment:
[Guido]
> I take it your position is that this can never be done 100% correctly
No. David Gay's code is believed to be 100% correctly-rounded and is
also reasonably fast in most cases. I don't know of any other "open"
string<->
Tim Peters added the comment:
It's not a question of bugs. Call the machine writing the string W and
the machine reading the string R. Then there are 4 ways R can get back
the double W started with when using the suggested algorithm:
1. W and R are the same machine. This is the way t
Tim Peters added the comment:
[Guido]
> ...
> (2) Will the Windows input routine still accept the *old*
> representations for INF and NAN? IMO that's important (a) so as to be
> able to read old pickles or marshalled data, (b) so as to be able to
> read data files writte
Tim Peters added the comment:
Historical note: Guido is probably thinking of "the old" pickle and
marshal here, which did have problems with inf and NaN on Windows (as in
they didn't work at all). Michael Hudson changed them to use special
bit patterns instead, IIRC
Tim Peters added the comment:
Guido, right, for that to work reliably, double->str and str->double
must both round correctly on the platform doing the repr(), and
str->double must round correctly on the platform reading the string.
It's quite easy to understand why at a high le
Tim Peters added the comment:
If someone has a more recent version of MS's compiler, I'd be interested
to know what this does:
inc = 2.0**-43
base = 1024.0
xs = ([base + i*inc for i in range(-4, 0)] +
[base] +
[base + 2*i*inc for i in (1, 2)])
print xs
print ["%.16g&q
Tim Peters added the comment:
Thanks, Amaury! That settles an issue raised earlier: MS's
string<->double routines still don't do correct rounding, and "aren't
even close" (the specific incorrect rounding showed here isn't
Tim Peters added the comment:
Right, Unix-derived C libraries generally do IEEE-754 "round to
nearest/even" rounding, while Microsoft's do "add a half and chop"
rounding. The Python reference manual says nothing about this, and
neither does the C standard (well, C89
Tim Peters added the comment:
Nice example! Yes, the round() implementation is numerically naive, in
this particular case ignoring that x+0.5 isn't necessarily representable
(it multiplies the input by 10.0, adds 0.5, takes the floor, then
divides by 10.0, and in this specific case addin
Tim Peters added the comment:
The functionality of what was called (and I agree confusingly so)
"sign()" here is supplied by "signbit()" in C99. That standard isn't
free, but the relevant part is incorporated in the free Open Group
standards:
http://www.opengroup
Tim Peters added the comment:
Unassigned myself -- I don't care about this 4 years later either ;-)
--
assignee: tim_one -> nobody
nosy: +nobody
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Tim Peters added the comment:
Mark, these are the "spirit of 754" rules:
1. If the mathematical result is a real number, but of magnitude too
large to approximate by a machine float, overflow is signaled and the
result is an infinity (with the appropriate sign).
2. If the mathemati
Tim Peters added the comment:
"is" is for testing object identity, not numeric equality. That "1 is
1" is always true is simply an implementation detail common to all
recent versions of CPython, due to CPython caching "very small" integer
objects. The language d
Tim Peters added the comment:
Please take requests for discussion to comp.lang.python. Many people
there understand this behavior and will be happy to explain it in as
much detail as you want. The bug tracker is not the place for this.
___
Python tracker
Tim Peters added the comment:
There's no need to keep asking -- this report was already rejected ;-)
Seriously, the efficiency argument carries no weight with me -- in 15
years of using Queue in a variety of applications, the time it takes to
.put and .get "here's a piec
New submission from Tim Peters :
When looking into a StackOverflow question about surprisingly high memory use,
I stumbled into this (under 3.10.1, Win64):
>>> import sys
>>> s = "1 2 3 4 5".split()
>>> s
['1', '2', '3', &#x
Change by Tim Peters :
--
type: behavior -> resource usage
___
Python tracker
<https://bugs.python.org/issue46990>
___
___
Python-bugs-list mailing list
Un
Tim Peters added the comment:
Well, that's annoying ;-) In context, the OP was saving a list of 10 million
splits. So each overallocation by a single element burned 80 million bytes of
RAM. Overallocating by 7 burned 560 million bytes.
Which is unusual. Usually a split result is short-
Tim Peters added the comment:
Actually, I see this ('Debug Assertion Failed!' in the same spot) every time I
try to run the test suite with a debug build, starting yesterday.
Didn't have time to track it down. It _appeared_ to an obscure consequence of
this commit:
Tim Peters added the comment:
BTW, the frequency of this new failure mode appears to be vastly increased if
running the debug tests with "-j0". For example, the box popping up is reliably
the very first sign of life if I run this from the PCBuild directory:
rt
Tim Peters added the comment:
Christian, yes, but only in a debug build. See Eryk Sun's message a bit above:
the machinery to prevent this is already present, but isn't getting called
early enough.
--
___
Python tracker
<https://bu
New submission from Tim Peters :
I added some excruciatingly obscure technical tricks to ensure that
fnmatch.py's regexps can't fall into exponential-time match failures.
It's hard to stop re from useless backtracking. But the new "atomic groups"
make that easy i
Change by Tim Peters :
--
keywords: +patch
pull_requests: +30118
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/32029
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
New changeset 5c3201e146b251017cd77202015f47912ddcb980 by Tim Peters in branch
'main':
bpo-47080: Use atomic groups to simplify fnmatch (GH-32029)
https://github.com/python/cpython/commit/5c3201e146b251017cd77202015f47
Change by Tim Peters :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Peters added the comment:
Definitely a duplicate, and I doubt Mark or Raymond will change their mind.
One observation: while floats are not uniformly dense in [0, 1), random()
results are uniformly spaced. Each is of the form I / 2**53 for an integer I in
range(2**53).
--
nosy
Tim Peters added the comment:
Various kinds of tasks:
- "Power switch must be on." Needs to done the first time. _May_ need to be
done again later (if some later task turns the power off again). Can be done
any number of times without harm (beyond the expense of checking), so lo
Tim Peters added the comment:
I believe I'm elaborating on your "footgun".
It doesn't matter to me whether we pick some scheme and document it, _if_ that
scheme is incoherent, impossible to remember, error-prone, etc.
That's how, e.g., regular expression syn
Tim Peters added the comment:
I'll testify that I won't volunteer one second of my time pursuing these
abstract "purity" crusades ;-) `isfinite()` et alia were added to supply
functions defined by current standards to work on IEEE floating-point values.
People work
New submission from Tim Peters :
Recording before I forget. These are easy:
1. As the comments note, cache the hash code.
2. Use the new (in 3.8) pow(denominator, -1, modulus) to get the inverse
instead of raising to the modulus-2 power. Should be significantly faster. If
not, the new
Tim Peters added the comment:
Why I expected a major speedup from this: the binary exponentiation routine
(for "reasonably small" exponents) does 30 * ceiling(exponent.bit_length() /
30) multiply-and-reduces, plus another for each bit set in the exponent.
That's a major dif
Tim Peters added the comment:
Well, details matter ;-) Division in Python is expensive. In the
exponentiation algorithm each reduction (in general) requires a 122-by-61 bit
division. In egcd, after it gets going nothing exceeds 61 bits, and across
iterations the inputs to the division
Tim Peters added the comment:
Mark, I did just a little browsing on this. It seems it's well known that egcd
beats straightforward exponentiation for this purpose in arbitrary precision
contexts, for reasons already sketched (egcd needs narrower arithmetic from the
start, benefits fro
Tim Peters added the comment:
I'm with Mark: leave numeric hashes alone. There's no reason to change them,
and in addition to what Mark wrote it's a positively Good Thing that `hash(i)
== i` for all sufficiently small ints. Not only is that efficient to compute,
it guara
Tim Peters added the comment:
Some random notes:
- 1425089352415399815 appears to be derived from using the golden ratio to
contrive a worst case for the Euclid egcd method. Which it's good at :-) Even
so, the current code runs well over twice as fast as when replacing the
pow(tha
Tim Peters added the comment:
For posterity:
"Modular Inverse Algorithms Without Multiplications for Cryptographic
Applications"
Laszlo Hars
https://link.springer.com/article/10.1155/ES/2006/32192
"""
On the considered computational platforms fo
New submission from Tim Peters :
For example, these should all raise ValueError instead:
>>> pow(2, -1, 1)
0
>>> pow(1, -1, 1)
0
>>> pow(0, -1, 1)
0
>>> pow(2, -1, -1)
0
>>> pow(1, -1, -1)
0
>>> pow(0, -1, -1)
0
--
component
Tim Peters added the comment:
@Batuhan, fine by me if you want to take this on! It should be relatively
easy. But Mark wrote the code, so it's really up to him. While I doubt this,
he may even argue that it's working correct
Tim Peters added the comment:
Yup, you have a point there! :-) I guess I'm just not used to 0 being a
multiplicative identity.
Don't know what other systems do. Playing with Maxima, modulo 1 it seems to
think 0 is the inverse of everything _except_ for 0. `inv_mod(0, 1)` retur
Tim Peters added the comment:
Mark, to save you the hassle, I'm closing this myself now. Thanks for the
feedback!
--
assignee: -> tim.peters
resolution: -> not a bug
stage: patch review -> resolved
status: open -> closed
_
Tim Peters added the comment:
I don't have a problem with the trivial ring - I wasn't being that high-minded
;-) I was testing a different inverse algorithm, and in the absence of errors
checked that
minv(a, m) * a % m == 1
for various a and m >= 0. Of course that faile
Change by Tim Peters :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Peters added the comment:
> Sometimes you guys make me feel dumb as a rock.
I expect we all do that favor for each other at times ;-)
--
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
This just isn't going to happen. There's no agreement to be had. For example,
the proleptic Gregorian calendar _does_ have a "year 0", and so also does ISO
8601.
Version 1.0 of the XML schema spec did not have a year 0, but _claimed_ to
Tim Peters added the comment:
This has nothing in particular do with `min()`. As strings, 'I' < 'i', and 'F'
< 'I'. For example,
>>> 'I' < 'i'
True
>>> sorted("InFinity")
['F', '
Tim Peters added the comment:
> Also, THE min("Infinity") is priniting "I". Practically,
> the minimum value is "e" right ?
Sorry, I have no idea what "practically" means to you. It's just a fact that
all uppercase ASCII letters compare l
Tim Peters added the comment:
You're probably chasing ghosts ;-) Please read about what needs to be done to
use valgrind successfully with Python:
https://github.com/python/cpython/blob/master/Misc/README.valgrind
--
nosy: +tim.peters
title: Use After Free: PyObject_Free -
Tim Peters added the comment:
I favor making this a structseq, primarily based on Paul's attempt to find
actual use cases, which showed that named member access would be most useful
most often. I have no intuition for that myself, because while I wrote the
original functions here,
Change by Tim Peters :
--
assignee: -> rhettinger
___
Python tracker
<https://bugs.python.org/issue24416>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
It's working fine. What do you expect? For example,
9 or 7 > "str"
groups as
9 or (7 > "str")
9 is evaluated for "truthiness" first, and since it's not 0 it's considered to
be true. That
Tim Peters added the comment:
I'm sorry you're not satisfied with the answer, but I'm a bona fide expert on
this and you're not going to get anyone to agree with your confusion here ;-)
But the bug tracker is not the right place for tutorials. Please take this up
Tim Peters added the comment:
@sangeetamchauhan, the reply you got in the image you attached was in error -
kind of. Section "6.16. Operator precedence" defines Python's operator
precedence:
https://docs.python.org/3/reference/expressions.html#index-92
"""
Tim Peters added the comment:
BTW, the docs also spell out that "and" and "or" ALWAYS evaluate their left
operand before their right operand, and don't evaluate the right operand at all
if the result of evaluating the left operand is true (for "or&quo
Tim Peters added the comment:
Ah, so you were expecting an error! That helps.
But that's not how the language works, or how it's documented to work, as has
been explained in quite some detail already.
In general, precedence _constrains_ evaluation order, but does not _define
New submission from Tim Peters :
The Glossary has this entry:
"""
struct sequence
A tuple with named elements. Struct sequences expose an interface similar to
named tuple in that elements can be accessed either by index or as an
attribute. However, they do not have any of
Tim Peters added the comment:
I don't believe that would improve the docs, but suit yourself. This is hardly
a FAQ, but instead a peculiar case where, for whatever reason, someone is
saying "I'm puzzled by what `or` does, but didn't read the docs for `or`".
Mo
Tim Peters added the comment:
Paul, please heed what Raymond said: it's not good to merge another core dev's
PR unless they ask you to. Besides what Raymond said, a core dev may well
check in incomplete work for any number of reasons (e.g., to see how the
automated test run
Tim Peters added the comment:
Note that you can contrive similar cases with positive hash codes too. For
example, force both hash codes to 2**60 - 2.
The salient points are that 0 * 5 is congruent to 0 mod any power of 2, while
-2 * 5 = -10 is congruent to -2 mod 8, so they're
Tim Peters added the comment:
Something that may be slightly worth pursuing: in
j = (5*j + 1) % 2**power
to get a full-period sequence hitting every integer in range(2**power) exactly
once, the multiplier (5) is a bit delicate (it has to be congruent to 1 mod 4),
but the addend (1
Tim Peters added the comment:
A more principled change would be to replace instances of this:
i = (i*5 + perturb + 1) & mask;
with this:
i = (i*5 + (perturb << 1) + 1) & mask;
The latter spelling has no fixed points. That's easy to see: `(perturb << 1)
Tim Peters added the comment:
Following up, at least under Visual Studio for x86 "it's free" to change the
code to add in `perturb` shifted left. The C source:
perturb >>= PERTURB_SHIFT;
i = (i*5 + (perturb << 1) + 1) & mask;
compiles to this, wher
Tim Peters added the comment:
I agree with Raymond here: using collections.namedtuple is fine in the pure
Python version. Since Raymond checked in doc changes to purge the phrase
"struct sequences" (thanks again for that!), it's consistent with everything
else now for t
Tim Peters added the comment:
Some results of the "add perturb shifted left 1 instead" approach. These come
from using an old pile of Python code I have that allows for easy investigation
of different collision probe strategies.
- As expected, because it has no fixed points, th
101 - 200 of 1332 matches
Mail list logo
