Daniel Stutzbach wrote:
On Wed, Mar 12, 2008 at 2:52 PM, Dimitrios Apostolou [EMAIL PROTECTED]
wrote:
Just one quick note. What exactly do you mean by Amortized worst case?
Shouldn't it just be Worst case? I think that the word amortized
better describes the time complexity of specific
Heya
I've been using Python for development for some years now, but up until
now, I didn't participate much in work on Python itself. I've decided to
'take a shot at it', even if a small one at first.
To the subject at hand:
Most experienced programmers know that you shouldn’t compare floating
Dimitrios Apostolou [EMAIL PROTECTED] wrote:
On another note which sorting algorithm is python using? Perhaps we can
add this as a footnote. I always thought it was quicksort, with a worst
case of O(n^2).
See http://svn.python.org/projects/python/trunk/Objects/listsort.txt
Terry Reedy wrote:
Joost Behrends [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| With such a tuple tp i tried 'ix = tp.index(...)' recently and was
| astonished to learn, that this doesn't work. Since we have '... in tp'
| for me it seems, that it should make very little
On Thu, Mar 13, 2008 at 3:16 AM, Dimitrios Apostolou [EMAIL PROTECTED] wrote:
On another note which sorting algorithm is python using? Perhaps we can
add this as a footnote. I always thought it was quicksort, with a worst
case of O(n^2).
It's a highly optimized variant of mergesort, with
On Thu, Mar 13, 2008, Imri Goldberg wrote:
My suggestion is to do either of the following:
1. Change floating point == to behave like a valid floating point
comparison. That means using precision and some error measure.
2. Change floating point == to raise an exception, with an error string
On Thu, Mar 13, 2008 at 4:20 AM, Imri Goldberg [EMAIL PROTECTED] wrote:
My suggestion is to do either of the following:
1. Change floating point == to behave like a valid floating point
comparison. That means using precision and some error measure.
2. Change floating point == to raise an
I am going through my backlog of GHOP work and noticed that test_errno
is essentially a no-op at the moment. I was wondering if anyone knew
if there are any guaranteed values for the errno module? If not, the
test current says that Linux has all the values; is that really true?
-Brett
2008/3/13, Brett Cannon [EMAIL PROTECTED]:
I am going through my backlog of GHOP work and noticed that test_errno
is essentially a no-op at the moment. I was wondering if anyone knew
if there are any guaranteed values for the errno module? If not, the
test current says that Linux has all
Imri Goldberg [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Most experienced programmers know that you shouldn't compare floating
| point numbers with ==.
As a general statement, this is wrong. Mark gave examples.
Please drop the proposal.
The reason for the int division change
I've been trying to give the Windows x64 builds a bit of TLC the past few
evenings. I managed to get a successful build with all external modules last
night (Tcl/Tk required about a half a dozen code/configuration changes each in
order to build in a Windows x64 environment with Visual Studio
I haven't built the bsddb stuff on windows myself in a few years and have
never had access to a windows x64 system so I'm no silver bullet. Making
the BerkeleyDB compile and link options match with those of python is the
first place I'd start. Also you should be able to make a debug build of
Hey Greg,
I'm at PyCon indeed, staying through the sprints 'til next Thursday. I'll drop
you a note offline re catching up.
The other query I had was whether or not I should try a later version of
BerkeleyDB -- are we committed to 4.4.20 (or 4.4.x?) for 2.6/3.0 or is it worth
investigating
I would suggest something like a ~= b, for approximately equal to. How
approximately? Well, there would be a default that could be changed
somewhere.
Don't know if it's all that useful, though.
Tiago A.O.A.
Terry Reedy escreveu:
Imri Goldberg [EMAIL PROTECTED] wrote in message
news:[EMAIL
On 3/13/08, Trent Nelson [EMAIL PROTECTED] wrote:
Hey Greg,
I'm at PyCon indeed, staying through the sprints 'til next Thursday. I'll
drop you a note offline re catching up.
The other query I had was whether or not I should try a later version of
BerkeleyDB -- are we committed to 4.4.20
Ah, and to think I just fixed 4.4.20 ;-)
Removing the dependency on db_static.vcproj and merging the relevant source
code files into _bsddb.vcproj did the trick -- all x64 bsddb-related tests now
pass. The only issue with this approach is that it locks _bsddb.vcproj into
4.4.20. However,
16 matches
Mail list logo
