Tim Peters added the comment:
My two cents:
- Spell it comb(n, k).
- TypeError if args aren't ints.
- ValueError if not 0 <= k <= n.
Not concerned about speed. It's possible to do this with no divisions
involving integers bigger than `n` and `k`(*), using O(k) space, but
Tim Peters added the comment:
Just for fun, here's a gonzo implementation (without arg-checking) using ideas
from the sketch. All factors of 2 are shifted out first, and all divisions are
done before any multiplies.
For large arguments, this can run much faster than a dumb loop.
Tim Peters added the comment:
`input()` returns a string, not a list. For input '1010' you're effectively
computing this:
>>> int('1' * 8) + int('1' * 2) # = + 11
1122
which is the correct answer. If you want your input to be a lis
Tim Peters added the comment:
Please read my answer again. Your code does not do what you _think_ it does.
It does what I said it does instead.
>>> a = input()
1010
>>> print(a)
1010
>>> print(type(a))
The input you're working with is NOT A LIST OF INTEGER
Tim Peters added the comment:
Antoine, alas, it's subtler than that. The worker process (process_func())
puts _another_ `StopIteration` on the input queue in its `finally` clause. So
the first worker process to finish adds back a sentinel for the next worker to
see, and so on. At th
Tim Peters added the comment:
I don't know that the language needs to define this, but sticking to __lt__ was
a wholly deliberate design decision for CPython.
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
Steven, thanks for noticing the docs! I was surprised to hear it wasn't
documented, but not surprised enough to check myself ;-)
This decision was suggested by me, and endorsed by Guido, when designing
timsort looking ahead to Python 3, where __cmp__ was
Tim Peters added the comment:
Please resist pointless feature creep. The original report was about comb(n,
k) for integer n and k with 0 <= k <= n and that's all. Everyone who commented
appeared to agree they'd find that useful.
But nobody has said they'd find gene
Tim Peters added the comment:
For history, note that `bisect` doesn't always work in this context either: a
heap is NOT always in sorted order. For example, this is "a (min) heap" too:
[1, 3, 2].
More, that's "the real" problem. If we could find the element
Tim Peters added the comment:
I'd like to divorce `prod()` from floating-point complications. The `sum()`
builtin has proved extremely handy, even for floats, in large part because it's
type-agnostic and straightforward. While I'd usually use `prod()` on ints and
Fractions
Tim Peters added the comment:
Precisely _how_ are you building it? As noted above, if you're using Visual
Studio, try using build.bat instead for the first time.
--
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
> As far as I can tell from the discussions here, Steven
> and you stated a preference for the shortened names, and
> that's it.
Plus Mark, plus me - all backed "comb()" specifically.
> I find it hard to imagine anyone needing combinat
Tim Peters added the comment:
As Mark said, the behavior of Python's floating-point math functions (not just
trig, but also log, pow, exp, ...) is inherited almost entirely from the
platform C's math libraries. Python itself guarantees nothing about what
`math.sin(x)` returns
Tim Peters added the comment:
Yes, it's quadratic time. If the string being searched has N characters, first
it fails to find "x" in all N of 'em, then `.*` advances by one and it fails to
find "x" in the trailing N-1 characters, then again in the trailing N
Tim Peters added the comment:
Without re.IGNORECASE, the leading
^[_a-z0-9-]+
can't even match the first character (`val` starts with uppercase Z), so it
fails instantly.
With re.IGNORECASE, it's not "stuck", but is taking a verry long time to
try an enormous n
Tim Peters added the comment:
difflib generally synchs on the longest contiguous matching subsequence that
doesn't contain a "junk" element. By default, `ndiff()`'s optional `charjunk`
argument considers blanks and tabs to be junk characters.
In the strings:
"
Tim Peters added the comment:
It's probably OK, but there's no "pure win" to be had here. There's generally
more than one way to convert one string to another, and what "looks right" to
humans depends a whole lot on context.
For example, consi
Tim Peters added the comment:
> It's impressive *and* scary that such 13 years old
> bug only show up today...
Then again, there's probably no other code in the world that compares slice
objects ;-)
--
nosy: +tim.peters -josh.r
__
Tim Peters added the comment:
Josh, I'd say the speed of this code doesn't matter one whit to anything. Like
you, I'd _prefer_ that the issue be fixed by building "real tuples" that own
their own references, which would also (as you showed) allow for briefer,
si
Tim Peters added the comment:
> Oh, Tim Peters succeded somehow to
> remove Josh Rosenberg from the nosy list: I add him again ;-)
Certainly wasn't my intent! That happens too often on the tracker. Thanks for
noticing! :-(
--
___
Pyt
Tim Peters added the comment:
"Multiple roundings" in the float code is a red herring - that's just
implementation details trying to cheaply get the same effect as computing with
infinite precision. Here with actual unbounded precision:
>>> from fractions import F
Tim Peters added the comment:
Thanks, Steven! I'll go on to suggest that the best intro to these issues for
Python programmers is in Python's own tutorial:
https://docs.python.org/3/tutorial/floatingpoint.html
Raymond, `divmod(a, b)[0]` IS the mathematical `floor(a/b)`, where
Tim Peters added the comment:
- Some form of this would be most welcome!
- If it's spelled this way, put the modulus argument last? "Everyone expects"
the modulus to come last, whether in code:
x = (a+b) % m
x = a*b % m
x = pow(a, b, m)
or in math:
a^(k
Tim Peters added the comment:
Raymond, I doubt we can do better (faster) than straightforward egcd without
heroic effort anyway. We can't even know whether a modular inverse exists
without checking whether the gcd is 1, and egcd builds on what we have to do
for the latter anyway. Ev
Tim Peters added the comment:
Your last line can't possibly return True, because `somelist.reverse()` returns
None.
So the last line is irrelevant. Your complaint appears to be about the line
before, which shows that the list retains its original order.
That's expected. All th
Tim Peters added the comment:
I haven't tried the example, but at this point I'd be surprised if it failed.
The caching here isn't at level of `__lt__` but at the higher level of
(invisible from Python code) a type's tp_richcompare slot. A heap type -
regardless of wheth
Tim Peters added the comment:
@ppperry, I have no idea what the bulk of the code in typeobect.c is trying to
do.
--
___
Python tracker
<http://bugs.python.org/issue28
Tim Peters added the comment:
Elliot, I don't care if the example behaves differently. Although someone else
may ;-)
The only things `.sort()` has ever tried to guarantee in the presence of
mutations (of either the list or the elements) during sorting are that (a) the
implementation
Tim Peters added the comment:
Elliot, did you run the example in a release build or a debug build? I'm
wondering why this:
assert(v->ob_type == w->ob_type &&
v->ob_type->tp_richcompare != NULL &&
v->ob_type->tp_richcompare == compa
Tim Peters added the comment:
The impact would be small: it would add one (or so) pointer-equality compare
that, in practice, will always say "yup, they're equal". Dirt cheap, and the
branch is 100% predictable.
--
___
Python
Tim Peters added the comment:
Elliot, PyObject_RichCompareBool calls PyObject_RichCompare. That in turn does
some checks, hides a small mountain of tests in the expansions of the
recursion-checking macros, and calls do_richcompare. That in turn does some
useless (in the cases you're a
Tim Peters added the comment:
I think this is expected. Add this as the first line of `simulate()` and the
problem should go away:
q.cancel_join_thread()
As the docs say, a Queue works with a background thread, which feeds incoming
data from an internal buffer to a (interprocess) pipe
Changes by Tim Peters :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29797>
___
___
Tim Peters added the comment:
@ppperry, I believe you're right - good catch! I expect the current patch
would treat the NotImplemented return as meaning "the first argument is less
than the second argument".
I added a comment to the code (on github) suggesting an obvio
Tim Peters added the comment:
See also:
https://en.wikipedia.org/wiki/Hamming_weight
As that says, there are a number of languages and processors with first class
support for a popcount function. I've frequently implemented it in Python when
using integers as integer bitsets (`i`
Tim Peters added the comment:
I think we should certainly support asserts regardless of whether Py_DEBUG is
in force (although Py_DEBUG should imply asserts run too).
And I wish you had stuck to just that much ;-) The argument against, e.g.,
'assert(!PyErr_Occurred())', seems e
Tim Peters added the comment:
So there's more than one issue here.
First, should asserts be supported in the absence of Py_DEBUG? It seems, so
far, everyone agrees they should be.
Second, ...? I'm really not following your argument. It _appears_ to be
something along the lines
Tim Peters added the comment:
I'll take a crack at these ancient comments ;-)
"""
daemon
The process’s daemon flag, a Boolean value. This must be set before start()
is called.
The initial value is inherited from the creating process. [1]
When a process e
Tim Peters added the comment:
@Eryk, not me ;-) I find the "daemonic or not?" distinction useless for
processes - it just gets in the way at times (e.g., a Pool worker dies with an
assert(!) error if it tries to create its own Pool for something).
I don't care about orphans ei
Tim Peters added the comment:
Again, I don't care about orphans. In the usual cases people are running code
with no concern about what happens in case of forced termination. The only
thing stopping it now is that the code goes out of its way to prevent it (or,
alternatively, goes out o
Tim Peters added the comment:
Yes, that example takes time exponential in the number of blanks to (fail to)
match - each time you add a blank to `input`, it essentially doubles the time
required.
It's _possible_ for an implementation to deduce that `(\s+)+` is an insanely
inefficient w
Tim Peters added the comment:
I already commented on github - +1 for this change.
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue30
Tim Peters added the comment:
Generally speaking, trying to shuffle a dict D already blows up, unless D's
keys are the integers range(len(D)). In that case, D is indistinguishable from
a list in the sense that both map range(N) to values via __getitem__.
`shuffle()` does no type c
Tim Peters added the comment:
Users certainly have been fooled by this, although "unpacking" is a red
herring. I've been burned by it, and I've seen StackOverflow puzzles related
to the same thing. I think this is the heart of it: given a finite iterable
I, it usual
Tim Peters added the comment:
If we could roll back the clock, I'd impose a total ordering on floats in
Python and supply some other way to spell 754's comparison operators (which
users would have to ask for explicitly if they wanted to hassle with the
near-useless and too-often-
Tim Peters added the comment:
> *Clearly*, negative NaNs should be sorted to the start
> of the list, while positive NaNs are sorted to the end
> of the list. (Yes, I'm joking, but only a little bit: that's
> the result you'd get if you used IEEE 754's totalOr
Tim Peters added the comment:
Stuff like that happens in any language supporting a tell() function for a file
opened in text mode on Windows, inherited from the platform C's ftell()
implementation:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=vs
Tim Peters added the comment:
I have no use for this either, and agree with rejecting it - in nearly 30
years, nobody has asked for this before, and it's still the case that we don't
have an actual programming use case (some theoretical use in an abstract
mathematical mod
Tim Peters added the comment:
Jurjen, the errors you see in Python's sin() are _entirely_ due to your
platform C's libm. Python just calls the platform C's sin. So nothing can be
said about it in general.
The better libm trig functions today do indeed perform trig argument
Tim Peters added the comment:
I'm at best -0 on this, and on the edge of -1. We already supply
mutate-in-place operations for when this is wanted, and, e.g., for lists, it's
as dead easy to spell as
L1 += L2
Half the point of the hack for string catenation was that the simil
Tim Peters added the comment:
Brandt, it's quite possible I have no real idea what this patch is aimed at. I
didn't reverse-engineer the code, the title is extremely broad, and there are
no Python examples I can find for what it _is_ aimed at. If, e.g., it's
impossible that
Tim Peters added the comment:
Serhiy, if I understand this, it _could_ pay big with even just a few
operations. For example,
[0] * 100 + [1] + [2] + [3]
As-is, we'll copy the million zeroes three times. WIth the patch, more likely
the original vector of a million zeroes
Tim Peters added the comment:
Josh, I agree - but do read Armin's response. The string hack was done inside
ceval.c, where we have extraordinary knowledge of context. Adding similar
hacks inside Python C API functions seems to be a non-starter - they can't
magically star
Tim Peters added the comment:
I'm inclined to agree with Mark - the wholly naive algorithm is already
"perfect" away from extreme (whether large or small) magnitudes, and can't be
beat for speed either. This kind of thing gets much more attractive in IEEE
single prec
Tim Peters added the comment:
+1 from me! I'm tired of re-inventing this too :-)
Agree with every point Mark made.
Just in passing, noting a triviality: for the ceiling, `1 + isqrt(n - 1)`
fails when `n` is zero.
But I've never had a use for the ceiling here, or for "near
Tim Peters added the comment:
Note that this pure Python gives the same result:
>>> "%.0f" % float(1639873214337061279)
'1639873214337061376'
That's not surprising: int -> float conversion is limited to the precision of
a Python float, which is a C doub
Tim Peters added the comment:
It sounds like you need to read an introduction (any!) to computer
floating-point formats. The relevant part in the output you showed is this:
mant_dig=53
As on almost other current machines, your platform's floating point format is
restricted to 53 bi
Change by Tim Peters :
--
nosy: +noam, tim.peters
___
Python tracker
<https://bugs.python.org/issue26092>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
Noam Yorav-Raphael, I tried to add you because this is pushing back against
your patch in issue 8408. It's been some years now, and nobody has cared
enough to pursue it, so I'll just close this if you still don't care ;-)
As doctest'
Tim Peters added the comment:
Oops! Should be issue 8048.
--
___
Python tracker
<https://bugs.python.org/issue26092>
___
___
Python-bugs-list mailing list
Unsub
Tim Peters added the comment:
This report appears to be the same:
https://bugs.python.org/issue27463
One other thing to note: the Python docs are sometimes unclear about whether
expressions are intended to be interpreted as Python code or as mathematical
expressions. In:
"&qu
Tim Peters added the comment:
I agree it would be nice (very!) to get this in. Indeed, I'm surprised to see
that this is still open :-(
But who can drive it? I cannot.
--
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
Thank you for giving this worthy orphan a home, Raymond!
Victor, don't fret too much. The code is really quite simple, and at worst
affects only `sorted()` and `list.sort()`. The vast bulk of review effort (of
which it got enough) went into dreami
New submission from Tim Peters :
This has come up repeatedly, and the docs should be updated to resolve it:
https://stackoverflow.com/questions/48603998/python-iterating-over-a-list-but-i-want-to-add-to-that-list-while-in-the-loop/48604036#48604036
Seemingly the only relevant documentation is
Tim Peters added the comment:
Some other points to consider: I don't think this belongs in the `for`
statement docs at all. Instead they should merely _note_ that what happens if
a sequence being iterated over is mutated is up to the sequence iterator.
Then, e.g., the `list` docs s
Tim Peters added the comment:
As I mentioned on StackOverflow, the literal in question appears to have been
crafted to convert to the best possible 53-bit binary approximation to log(2)
regardless of whether a compiler converts it to double precision (53 bits of
precision) or to "d
Tim Peters added the comment:
Stefan, yup! Thank you. `array.array` and `bytearray` iterators appear to
work the same way as `list` iterators here.
Terry, the note in the `for` statement docs was written before there _was_ an
iterator protocol. For example, here are the 1.5.1 docs:
https
Tim Peters added the comment:
> Surprisingly, deleting a very large set takes much longer than creating it.
Luis, that's not surprising ;-) When you create it, it's mostly the case that
there's a vast chunk of raw memory from which many pieces are passed out in
address
Tim Peters added the comment:
The docs could be clearer about this: the argument to .put() is _not_ pickled
at the time .put() is called. The object is remembered (by reference, not by
value), and a feeder thread pickles the value and puts the pickle on the queue
when the feeder thread
Tim Peters added the comment:
What did you expect? The precision of Python ints is limited only by the
amount of memory you have, but Python floats are IEEE-754 double precision
numbers, and have only 53 bits of precision.
2**53 + 1 simply can't be represented exactly as a float
Tim Peters added the comment:
> Is this also desired for fractions.Fraction and numbers.Rational?
I think so. The idea, e.g., that "it's obvious" for Fraction is no more
compelling than that it's even more obvious for ints ;-) Given that it's
spreadin
Tim Peters added the comment:
Serhiy, we already went down the path of implementing this as a method. Of
course `numbers.Rational` could define the method as `return (self.numerator,
self.denominator)` for itself and its subclasses. Unless I'm confused, that
would "magically&q
Tim Peters added the comment:
Thanks, Guido! I figured I was missing something :-)
It looks like `numbers.Rational` _is_ a "for real" base class of
`fractions.Fraction`, though, so I'm in favor of supplying a default
implementation of `.as_integer_ratio()` in `numbers.R
Tim Peters added the comment:
Serhiy, I don't understand. If `numbers.Rational` is in fact a superclass of
`numpy.int64`, then the latter will inherit an implementation added to the
former. The idea here isn't to add an abstract method to the Rational
interface, but a concre
Tim Peters added the comment:
[Raymond]
> The OPs notion of "absurd" behavior implies a rule that
> all float methods should be available for ints. That
> would suggest the is_integer, hex, fromhex, and
> as_integer_ratio would all need to propagate to the
> other type
Tim Peters added the comment:
Thanks, Mark! So if int.as_integer_ratio is added to the core, numpy.int64
won't magically have it too, regardless of whether we do or don't add an
implementation to numbers.Rational.
As an end user, I'd be surprised if numpy.int64 didn't su
Tim Peters added the comment:
Serhiy, nobody is proposing to add float.as_integer(). It already exists:
>>> (3.1).is_integer()
False
I already allowed I don't have a feel for how _generally_ useful it is, but you
have at least my and Stefan's word for that the functionali
Tim Peters added the comment:
If you want to deprecate the method, bring that up on python-dev or
python-ideas. It's inappropriate on the issue tracker (unless, e.g., you open
a new issue with a patch to rip it out of the language). It's also
inappropriate to keep on demanding
Tim Peters added the comment:
This won't be changed. The dict type doesn't support efficient random choice
(neither do sets, by the way), and it's been repeatedly decided that it would
do a disservice to users to hide that. As you know, you can materialize the
keys in a
Tim Peters added the comment:
I'd be +1 on generalizing math.hypot to accept an arbitrary number of
arguments. It's the natural building block for computing distance, but the
reverse is strained. Both are useful.
Here's scaling code translated from the Fortran implementat
Tim Peters added the comment:
Some notes on the hypot() code I pasted in: first, it has to special case
infinities too - it works fine if there's only one of 'em, but returns a NaN if
there's more than one (it ends up computing inf/inf, and the resulting NaN
propagates).
S
Tim Peters added the comment:
Mark, thanks! I'm happy with that resolution: if any argument is infinite,
return +inf; else if any argument is a NaN, return a NaN; else do something
useful ;-)
Serhiy, yes, the scaling that prevents catastrophic overflow/underflow due to
naively squ
Tim Peters added the comment:
Mark, how about writing a clever single-rounding dot product that merely
_detects_ when it encounters troublesome cases? If so, it can fall back to a
(presumably) much slower method. For example, like this for the latter:
def srdp(xs, ys):
"S
Tim Peters added the comment:
Please see the response to issue31889. Short course: you need to pass
`autojunk=False` to the SequenceMatcher constructor.
--
nosy: +tim.peters
resolution: -> duplicate
stage: -> resolved
status: open -&g
Tim Peters added the comment:
factorial(float) was obviously intended to work the way it does, so I'd leave
it alone in whatever changes are made to resolve _this_ issue. I view it as a
harmless-enough quirk, but, regardless, if people want to deprecate it that
should be a different
Tim Peters added the comment:
There's nothing in the docs I can see that implies `sample(x, n)` is a prefix
of what `sample(x, n+1)` would have returned had the latter been called
instead. If so, then - as always - it's "at your own risk" when you rely on
behavio
Tim Peters added the comment:
I don't see anything objectionable about the class optimizing the
implementation of a private method.
I'll note that there's a speed benefit beyond just removing the two type checks
in the common case: the optimized `_randbelow()` also avoids
Tim Peters added the comment:
I'm the wrong guy to ask about that. Since I worked at Zope Corp, my natural
inclination is to monkey-patch everything - but knowing full well that will
offend everyone else ;-)
That said, this optimization seems straightforward to me: two distinct m
Tim Peters added the comment:
Sounds good (removing \b) to me, Terry!
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue33204>
___
___
Pytho
Tim Peters added the comment:
I agree this isn't a bug (and it was right to close it). I expect the OP is
confused about what the `.timestamp()` method does, though. This note in the
docs directly address what happens in their problematic
`datetime.utcnow().timestamp()` case:
&qu
Tim Peters added the comment:
Ned, I think this one is more the case that the OP didn't read the docs ;-)
That said, there's a level of complexity here that seemingly can't be reduced:
the distinctions between the `datetime` and `time` modules' views of the world,
and
Tim Peters added the comment:
docstrings give brief statements intended to jog your memory; they're not
intended to be comprehensive docs. Read the actual documentation and see
whether you're still confused. When you "assumed it is irrelevant to time
zone", that w
Tim Peters added the comment:
Please find a minimal example that illustrates the problem you think you've
found, and paste the plain text _into_ the bug report.
In the meantime, I'm closing this as "not a bug". The division operator
applied to integers in Python 2 defau
Tim Peters added the comment:
-1. We should stop pretending this _ might_ happen ;-)
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue33
Tim Peters added the comment:
Closing because this appears to be senseless.
--
nosy: +tim.peters
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Peters added the comment:
I'm not familiar with `icdiff` - it's not part of the Python distribution,
right? If so, you should really talk to its author(s).
If two files have different line endings, then no pair of lines between them
can be equal, and the difference engine wil
Tim Peters added the comment:
The text/binary distinction you have in mind doesn't particularly apply to
difflib: it compares sequences of hashable objects. "Text files" are
typically converted by front ends to lists of strings, but, e.g., the engine is
just as happy comp
Tim Peters added the comment:
Note that 2am doesn't exist on the local clock: it leaps from 1:59:59 to
3:00:00. You're claiming that one answer is "correct", but why? The relevant
_standards_ don't appear to specify what happens when the input is senseless.
Not
Tim Peters added the comment:
Of course the relationship is extremely delicate near pi/2. On my Windows
Python 3:
>>> import math
>>> (1.5707963267948961).hex()
'0x1.921fb54442d16p+0'
>>> math.tan(float.fromhex('0x1.921fb54442d16p+0')) # what t
Tim Peters added the comment:
Ah! So it looks like OpenBSD took its math functions from Sun's fdlibm. I
believe wxMaxima does too. That would certainly explain why they give the same
answer ;-)
So who's right? Using "bigfloats" in wxMaxima and feeding its bigfl
601 - 700 of 1332 matches
Mail list logo
