range() is not the best way to check range?
it seems that range() can be really slow: the following program will run, and the last line shows how long it ran for: import time startTime = time.time() a = 1.0 for i in range(0, 3): if i in range (0, 1): a += 1 if not i % 1000: print i print a, " ", round(time.time() - startTime, 1), "seconds" - the last line of output is - 10001.0 22.8 seconds so if i change the line if i in range (0, 1): to if i >= 0 and i < 1: the the last line is 10001.0 0.2 seconds so approximately, the program ran 100 times faster! or is there an alternative use of range() or something similar that can be as fast? -- http://mail.python.org/mailman/listinfo/python-list
Re: range() is not the best way to check range?
[EMAIL PROTECTED] wrote:
> it seems that range() can be really slow:
>
> if i in range (0, 1):
My original use was like this:
if i in range (iStart, iEnd):
listData.append(a)
in which iStart is 1000 and iEnd is 1008
so in that case, the program ran fine...
but later on, i wanted to include all data, so I relaxed the range by
setting iStart to 0 and iEnd to and later on i found that the
program was slow due to this.
So looks like the usage of
if sDay in ("Tue", "Wed", "Thu"):
is more like good use of "in a list" but in range(0,1) will be a
big search in a list.
--
http://mail.python.org/mailman/listinfo/python-list
a print bug?
it seems that the behavior of "print" is that it will round off properly for any floating point imperfection, such as shown in the first two samples. The third sample seems to be a bug? It doesn't know how to handle the floating imperfection in this case. >>> 1.2345 1.2344 >>> print 1.2345 1.2345 >>> print "%10.3f" % 1.2345# seems like a bug >>> -- 1.234 >>> print "%10.3f" % 1.23450001 1.235 >>> print "%10.3f" % 1.2344 1.234 >>> print "%10.3f" % 1.2346 1.235 -- http://mail.python.org/mailman/listinfo/python-list
Re: a print bug?
Sybren Stuvel wrote: > It has nothing to do with the print command, and everything with > floating point precision. See http://docs.python.org/tut/node16.html how about the discrepancy between >>> print 1.2345 1.2345 >>> print "%10.3f" % 1.2345# seems like a bug 1.234 the first one, print knows enough to recognize and print it as 1.2345. however, in the second line, when it is round off, it doesn't know it is 1.2345 any more. -- http://mail.python.org/mailman/listinfo/python-list
Re: a print bug?
[EMAIL PROTECTED] wrote: > how about the discrepancy between > > >>> print 1.2345 > > 1.2345 > > >>> print "%10.3f" % 1.2345# seems like a bug > > 1.234 > > the first one, print knows enough to recognize and print it as 1.2345. > however, in the second line, when it is round off, it doesn't know it > is 1.2345 any more. I think maybe this is the reason: the first one, print will print it out with a rounding to the 11th decimal point, therefore hiding any floating point imperfection. however, in the second one, print will not first round it off to the 11th decimal point with a subsequent rounding off to the 3rd decimal point. In that case, the floating point imperfection is manifested. (by thinking it is 1.2344) a question is: since print can nicely hide and smooth out the floating point imperfection, and probably most people prefer it that way, how come the implementation of print "%10.3f" doesn't also do that -- eliminating the imperfection first, and then print it out accordingly. I think one argument is the loss of precision, but we only print it, rather than modify the number or the variable itself... hm... say, if a bank uses python to print out the "change that should be returned to the customer" using print "%20.2f", then there will be a cent missing here and there... why not smooth out that imperfection and return that penny to the customer? (not that they really care). -- http://mail.python.org/mailman/listinfo/python-list
Re: a print bug?
Duncan Booth wrote: > But you wouldn't complain about this would you? > > >>> print "%10.4f" % 1.23445 > 1.2345 > >>> print "%10.3f" % 1.23445 > 1.234 > > A value which is slightly than 1.2345 prints to 4 decimal places as 1.2345 > and to 3 decimal places as 1.234. > > That's all that happens with your value as well: 1.2345 is not exactly > representable as a floating point number, and the nearest representable > number is less than 1.2345. This is the expected behavior though... even school when they first teach "rounding off", they will tell you 1.23445 rounding off to 3 decimal places is not 1.235 and i don't see anything weird about the two lines above. -- http://mail.python.org/mailman/listinfo/python-list
Re: a print bug?
Steve Holden wrote: > You obviously haven't yet passed your floating-point number proficiency > test yet. Please restrict yourself to integers until you understand the > difficulties that inaccuracies in floating-point can create ;-) hm, actually, i understand the limitation of floating point. but my real concern is, how come "print" favors one version over the other... the first version will favor the correct rounding, while the second doesn't favor it. to me, this is biased computing i will feel happier if the behavior is consistent. (such as the first line printing out as 1.23449) . if most people favor the behavior of line 1, that is, silently rounding off to about the 11th decimal places, then why doesn't printing with formatting also use that same behavior, which is rounding off to the 11th places first, and then round off to whatever the user wants. print 1.2345 > 1.2345 print "%10.3f" % 1.2345 > 1.234 but then again, i just realize even if i do a >>> round(1.2344999, 6) 1.2344 so even if you round it off, it is still represented the same way still, how "print" handles 1.2345 and treating it and printing it as 1.2345, i wonder why we don't make the "print with formatting" the same behavior, treating it as 1.2345 first and round it off to 1.235 -- http://mail.python.org/mailman/listinfo/python-list
looks like in PIL, resize() will give high quality thumbnails than thumbnail()
In PIL, since thumbnail() first makes a draft copy of the image, and then resize it, so thumbnail() can run a lot faster than resize() because draft() seems a lot faster when resizing from very big images to small images... (such as the original image is 3000 x 2000, and it can make a draft really quickly to 375 x 250, and then resize to, say 200 x 133 as a thumbnail) However, the double resizing probably will make a thumbnail with a lower quality than if it is directly resizing from the original... as each resizing involves some approximation. however, i tried directly using resize() and it is a lot slower. But looks like if quality is of concern and time is not an issue, then we can use the resize() to create thumbnails instead. -- http://mail.python.org/mailman/listinfo/python-list
Re: looks like in PIL, resize() will give high quality thumbnails than thumbnail()
[EMAIL PROTECTED] wrote: > In PIL, since thumbnail() first makes a draft copy of the image, and > then resize it, so thumbnail() can run a lot faster than resize() > because draft() seems a lot faster when resizing from very big images > to small images... (such as the original image is 3000 x 2000, and it > can make a draft really quickly to 375 x 250, and then resize to, say > 200 x 133 as a thumbnail) as a matter of fact, i tried using thumbnail() to resize photos of 3456 x 2304 to 800 x 533 and it is a lot faster than using resize() -- http://mail.python.org/mailman/listinfo/python-list
array of array of float
i used C too much and haven't used Python for a while... like in C, if we want an array of array of float, we use float a[200][500]; now in Python, seems like we have to do something like a = [ [ ] ] * 200 and then just use a[1].append(12.34) etc but it turns out that all 200 elements points to the same list... and i have to use a = [ ] for i in range (0, 200): a.append([ ]) is there a simpler way... i wonder... -- http://mail.python.org/mailman/listinfo/python-list
