Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #41834 > unrolled thread
| Started by | Chris Angelico <rosuav@gmail.com> |
|---|---|
| First post | 2013-03-26 08:51 +1100 |
| Last post | 2013-03-28 12:39 +0000 |
| Articles | 20 on this page of 206 — 30 participants |
Back to article view | Back to comp.lang.python
Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-26 08:51 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-25 23:35 +0000
Re: Performance of int/long in Python 3 Dan Stromberg <drsalists@gmail.com> - 2013-03-25 17:12 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-26 17:26 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-26 13:38 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 01:08 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-26 16:41 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 03:54 +1100
Re: Performance of int/long in Python 3 Terry Reedy <tjreedy@udel.edu> - 2013-03-26 14:24 -0400
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-26 11:50 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 06:03 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-26 13:44 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-26 20:50 +0000
Re: Performance of int/long in Python 3 Grant Edwards <invalid@invalid.invalid> - 2013-03-26 21:08 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 08:14 +1100
Re: Performance of int/long in Python 3 Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-03-27 12:10 +1300
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-03-26 19:19 -0400
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-26 21:26 +0000
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-03-26 17:28 -0400
Re: Performance of int/long in Python 3 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-03-26 23:14 -0400
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-27 13:30 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 07:52 +1100
Re: Performance of int/long in Python 3 Ned Deily <nad@acm.org> - 2013-03-26 17:00 -0700
Re: Performance of int/long in Python 3 rurpy@yahoo.com - 2013-03-26 21:31 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-27 00:20 +0000
Re: Performance of int/long in Python 3 Ned Deily <nad@acm.org> - 2013-03-26 18:31 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-27 11:51 +0000
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 01:47 +0000
flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-27 20:18 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rusi <rustompmody@gmail.com> - 2013-03-27 20:49 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 05:20 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rusi <rustompmody@gmail.com> - 2013-03-27 22:42 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 07:48 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rurpy@yahoo.com - 2013-03-28 12:54 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-28 13:31 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Grant Edwards <invalid@invalid.invalid> - 2013-03-29 14:52 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-29 08:51 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Grant Edwards <invalid@invalid.invalid> - 2013-03-29 16:50 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rurpy@yahoo.com - 2013-03-29 14:26 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-29 16:07 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-31 00:35 -0700
ASCII versus non-ASCII [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-31 08:22 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-31 13:55 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-03-31 22:33 -0700
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-31 23:52 -0600
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-01 16:57 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 08:14 +0000
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-01 08:15 -0400
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-01 06:11 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 17:02 +0000
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 17:07 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 04:20 +1100
Re: Performance of int/long in Python 3 MRAB <python@mrabarnett.plus.com> - 2013-04-01 18:53 +0100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-01 12:15 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 06:28 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-01 13:28 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 07:35 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 22:38 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 22:43 +0100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-02 10:43 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 00:24 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 19:03 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-02 08:35 +0000
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 02:24 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 10:43 +0100
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 11:58 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 06:42 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-02 14:03 +0000
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 15:39 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 16:02 +0100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 08:12 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 16:43 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 10:08 -0700
Re: Performance of int/long in Python 3 Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-02 17:33 -0400
Re: Performance of int/long in Python 3 Joshua Landau <joshua.landau.ws@gmail.com> - 2013-04-02 23:40 +0100
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-02 08:09 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 15:12 +0100
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 16:03 +0100
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-02 08:17 -0700
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 09:57 -0700
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 11:22 -0700
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 11:50 -0700
Re: Performance of int/long in Python 3 Lele Gaifax <lele@metapensiero.it> - 2013-04-03 00:52 +0200
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 02:20 -0700
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-02 13:44 -0600
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 14:31 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 20:53 -0700
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 15:03 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 22:11 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:22 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:28 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 00:38 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 00:10 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 19:15 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:25 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 00:34 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 05:32 +0000
Re: Performance of int/long in Python 3 Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-03 02:19 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 17:27 +1100
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:25 +1100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 17:29 +1100
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:52 +1100
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 01:06 -0600
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 18:24 +1100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 18:37 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-03 01:07 -0700
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 19:22 +1100
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 06:20 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 22:05 +1100
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 07:52 -0400
Sorting [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 14:43 +0000
Re: Sorting [was Re: Performance of int/long in Python 3] Roy Smith <roy@panix.com> - 2013-04-03 11:00 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:30 -0600
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 13:51 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-04 09:58 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 07:53 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 19:02 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-03 01:08 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 12:27 +0100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:43 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 01:17 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 15:07 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 08:57 +1100
Re: Performance of int/long in Python 3 Serhiy Storchaka <storchaka@gmail.com> - 2013-04-06 12:09 +0300
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-07 07:24 +1000
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-06 14:58 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 01:29 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 19:58 -0600
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-06 22:18 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 23:22 -0600
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 08:29 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 20:00 -0600
Re: Performance of int/long in Python 3 Serhiy Storchaka <storchaka@gmail.com> - 2013-04-07 11:02 +0300
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-07 16:14 +0100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 15:02 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:38 -0600
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 17:43 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 08:55 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 23:39 +0100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 20:49 -0400
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-03 09:10 -0700
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-03 10:09 -0700
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 20:46 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:53 -0600
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-02 20:28 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 14:56 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 20:54 +0100
Re: Performance of int/long in Python 3 roy@panix.com (Roy Smith) - 2013-04-01 16:31 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 00:35 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 21:22 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ned Deily <nad@acm.org> - 2013-03-28 13:23 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-27 23:12 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 02:03 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Foote <ian@feete.org> - 2013-03-28 09:36 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-28 23:11 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 13:01 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 07:12 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 01:38 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 08:14 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 02:21 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 08:45 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Terry Reedy <tjreedy@udel.edu> - 2013-03-28 12:01 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:11 -0600
Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 00:39 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 11:54 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 02:37 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 13:44 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-29 00:11 -0600
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-29 00:22 -0600
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Terry Reedy <tjreedy@udel.edu> - 2013-03-29 14:06 -0400
Re: Surrogate pairs in new flexible string representation Christian Heimes <christian@python.org> - 2013-03-29 23:05 +0100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-29 01:03 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 12:10 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] MRAB <python@mrabarnett.plus.com> - 2013-03-29 02:00 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 03:16 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:01 -0600
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 14:34 +1100
unicode and the FSR [was: Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ethan Furman <ethan@stoneleaf.us> - 2013-03-28 21:56 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 16:33 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 16:46 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] MRAB <python@mrabarnett.plus.com> - 2013-03-28 14:51 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 14:57 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 02:07 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-03-28 09:47 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 21:30 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 06:34 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:33 -0600
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 09:55 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 04:13 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 10:48 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 04:55 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 13:26 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 08:45 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Terry Reedy <tjreedy@udel.edu> - 2013-03-28 19:12 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-03-28 13:29 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 14:11 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 14:33 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] MRAB <python@mrabarnett.plus.com> - 2013-03-28 21:50 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-03-28 14:52 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-03-28 19:53 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 11:03 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-29 00:15 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 14:40 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] 88888 Dihedral <dihedral88888@googlemail.com> - 2013-03-28 16:04 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] 88888 Dihedral <dihedral88888@googlemail.com> - 2013-03-28 16:04 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-28 12:39 +0000
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-04-02 11:22 -0700 |
| Message-ID | <fc66de13-8467-4056-9c88-9a042c78a553@m9g2000vbc.googlegroups.com> |
| In reply to | #42590 |
On 2 avr, 18:57, rusi <rustompm...@gmail.com> wrote:
> On Apr 2, 8:17 pm, Ethan Furman <et...@stoneleaf.us> wrote:
>
> > Simmons (too many Steves!), I know you're new so don't have all the history with jmf that many
> > of us do, but consider that the original post was about numbers, had nothing to do with
> > characters or unicode *in any way*, and yet jmf still felt the need to bring unicode up.
>
> Just for reference, here is the starting para of Chris' original mail
> that started this thread.
>
> > The Python 3 merge of int and long has effectively penalized
> > small-number arithmetic by removing an optimization. As we've seen
> > from PEP 393 strings (jmf aside), there can be huge benefits from
> > having a single type with multiple representations internally. Is
> > there value in making the int type have a machine-word optimization in
> > the same way?
>
> ie it mentions numbers, strings, PEP 393 *AND jmf.* So while it is
> true that jmf has been butting in with trollish behavior into
> completely unrelated threads with his unicode rants, that cannot be
> said for this thread.
-----
That's because you did not understand the analogy, int/long <-> FSR.
One another illustration,
>>> def AddOne(i):
... if 0 < i <= 100:
... return i + 10 + 10 + 10 - 10 - 10 - 10 + 1
... elif 100 < i <= 1000:
... return i + 100 + 100 + 100 + 100 - 100 - 100 - 100 - 100
+ 1
... else:
... return i + 1
...
Do it work? yes.
Is is "correct"? this can be discussed.
Now replace i by a char, a representent of each "subset"
of the FSR, select a method where this FST behave badly
and take a look of what happen.
>>> timeit.repeat("'a' * 1000 + 'z'")
[0.6532032148133153, 0.6407248807756699, 0.6407264561239894]
>>> timeit.repeat("'a' * 1000 + '9'")
[0.6429508479509245, 0.6242782443215589, 0.6240490311410927]
>>>
>>> timeit.repeat("'a' * 1000 + '€'")
[1.095694927496563, 1.0696347279235603, 1.0687741939041082]
>>> timeit.repeat("'a' * 1000 + 'ẞ'")
[1.0796421281222877, 1.0348612767961853, 1.035325216876231]
>>> timeit.repeat("'a' * 1000 + '\u2345'")
[1.0855414137412112, 1.0694677410017164, 1.0688096392412945]
>>>
>>> timeit.repeat("'œ' * 1000 + '\U00010001'")
[1.237314015362017, 1.2226262553064657, 1.21994619397816]
>>> timeit.repeat("'œ' * 1000 + '\U00010002'")
[1.245773635836997, 1.2303978424029651, 1.2258257877430765]
Where does it come from? Simple, the FSR breaks the
simple rules used in all coding schemes (unicode or not).
1) a unique set of chars
2) the "same" algorithm for all chars.
And again that's why utf-8 is working very smoothly.
The "corporates" which understood this very well and
wanted to incorporate, let say, the used characters
of the French language had only the choice to
create new coding schemes (eg mac-roman, cp1252).
In unicode, the "latin-1" range is real plague.
After years of experience, I'm still fascinated to see
the corporates has solved this issue easily and the "free
software" is still relying on latin-1.
I never succeed to find an explanation.
Even, the TeX folks, when they shifted to the Cork
encoding in 199?, were aware of this and consequently
provides special package(s).
No offense, this is in my mind why "corporate software"
will always be "corporate software" and "hobbyist software"
will always stay at the level of "hobbyist software".
A French windows user, understanding nothing in the
coding of characters, assuming he is aware of its
existence (!), has certainly no problem.
Fascinating how it is possible to use Python to teach,
to illustrate, to explain the coding of the characters. No?
jmf
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-04-02 11:50 -0700 |
| Message-ID | <0db48970-c682-4881-8276-c8cae5d26640@kk11g2000pbb.googlegroups.com> |
| In reply to | #42594 |
On Apr 2, 11:22 pm, jmfauth <wxjmfa...@gmail.com> wrote:
> On 2 avr, 18:57, rusi <rustompm...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 2, 8:17 pm, Ethan Furman <et...@stoneleaf.us> wrote:
>
> > > Simmons (too many Steves!), I know you're new so don't have all the history with jmf that many
> > > of us do, but consider that the original post was about numbers, had nothing to do with
> > > characters or unicode *in any way*, and yet jmf still felt the need to bring unicode up.
>
> > Just for reference, here is the starting para of Chris' original mail
> > that started this thread.
>
> > > The Python 3 merge of int and long has effectively penalized
> > > small-number arithmetic by removing an optimization. As we've seen
> > > from PEP 393 strings (jmf aside), there can be huge benefits from
> > > having a single type with multiple representations internally. Is
> > > there value in making the int type have a machine-word optimization in
> > > the same way?
>
> > ie it mentions numbers, strings, PEP 393 *AND jmf.* So while it is
> > true that jmf has been butting in with trollish behavior into
> > completely unrelated threads with his unicode rants, that cannot be
> > said for this thread.
>
> -----
>
> That's because you did not understand the analogy, int/long <-> FSR.
>
> One another illustration,
>
> >>> def AddOne(i):
>
> ... if 0 < i <= 100:
> ... return i + 10 + 10 + 10 - 10 - 10 - 10 + 1
> ... elif 100 < i <= 1000:
> ... return i + 100 + 100 + 100 + 100 - 100 - 100 - 100 - 100
> + 1
> ... else:
> ... return i + 1
> ...
>
> Do it work? yes.
> Is is "correct"? this can be discussed.
>
> Now replace i by a char, a representent of each "subset"
> of the FSR, select a method where this FST behave badly
> and take a look of what happen.
>
> >>> timeit.repeat("'a' * 1000 + 'z'")
>
> [0.6532032148133153, 0.6407248807756699, 0.6407264561239894]>>> timeit.repeat("'a' * 1000 + '9'")
>
> [0.6429508479509245, 0.6242782443215589, 0.6240490311410927]
>
>
>
> >>> timeit.repeat("'a' * 1000 + '€'")
>
> [1.095694927496563, 1.0696347279235603, 1.0687741939041082]>>> timeit.repeat("'a' * 1000 + 'ẞ'")
>
> [1.0796421281222877, 1.0348612767961853, 1.035325216876231]>>> timeit.repeat("'a' * 1000 + '\u2345'")
>
> [1.0855414137412112, 1.0694677410017164, 1.0688096392412945]
>
>
>
> >>> timeit.repeat("'œ' * 1000 + '\U00010001'")
>
> [1.237314015362017, 1.2226262553064657, 1.21994619397816]>>> timeit.repeat("'œ' * 1000 + '\U00010002'")
>
> [1.245773635836997, 1.2303978424029651, 1.2258257877430765]
>
> Where does it come from? Simple, the FSR breaks the
> simple rules used in all coding schemes (unicode or not).
> 1) a unique set of chars
> 2) the "same" algorithm for all chars.
Can you give me a source for this requirement?
Numbers are after all numbers. SO we should use the same code/
algorithms/machine-instructions for floating-point and integers?
>
> And again that's why utf-8 is working very smoothly.
How wonderful. Heres a suggestion.
Code up the UTF-8 and any of the python string reps in C and profile
them.
Please come back and tell us if UTF-8 outperforms any of the python
representations for strings on any operation (except straight copy).
>
> The "corporates" which understood this very well and
> wanted to incorporate, let say, the used characters
> of the French language had only the choice to
> create new coding schemes (eg mac-roman, cp1252).
>
> In unicode, the "latin-1" range is real plague.
>
> After years of experience, I'm still fascinated to see
> the corporates has solved this issue easily and the "free
> software" is still relying on latin-1.
> I never succeed to find an explanation.
>
> Even, the TeX folks, when they shifted to the Cork
> encoding in 199?, were aware of this and consequently
> provides special package(s).
>
> No offense, this is in my mind why "corporate software"
> will always be "corporate software" and "hobbyist software"
> will always stay at the level of "hobbyist software".
>
> A French windows user, understanding nothing in the
> coding of characters, assuming he is aware of its
> existence (!), has certainly no problem.
>
> Fascinating how it is possible to use Python to teach,
> to illustrate, to explain the coding of the characters. No?
>
> jmf
You troll with eclat and elan!
[toc] | [prev] | [next] | [standalone]
| From | Lele Gaifax <lele@metapensiero.it> |
|---|---|
| Date | 2013-04-03 00:52 +0200 |
| Message-ID | <mailman.27.1364943151.3114.python-list@python.org> |
| In reply to | #42594 |
jmfauth <wxjmfauth@gmail.com> writes:
> Now replace i by a char, a representent of each "subset"
> of the FSR, select a method where this FST behave badly
> and take a look of what happen.
You insist in cherry-picking a single "method where this FST behave
badly", even when it is so obviously a corner case (IMHO it is not
reasonably a common case when you have relatively big chunks of ASCII
characters where you are adding one single non-ASCII char...)
Anyway, these are my results on the opposite case, where you have a big
chunk of non-ASCII characters and a single ASCII char added:
Python 2.7.3 (default, Jan 2 2013, 13:56:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> timeit.repeat("'€' * 1000 + 'z'")
[0.2817099094390869, 0.2811391353607178, 0.2811310291290283]
>>> timeit.repeat("u'œ' * 1000 + u'\U00010001'")
[0.549591064453125, 0.5502040386199951, 0.5490291118621826]
>>> timeit.repeat("u'\U00010001' * 1000 + u'œ'")
[0.3823568820953369, 0.3823089599609375, 0.3820679187774658]
>>> timeit.repeat("u'\U00010002' * 1000 + 'a'")
[0.45046305656433105, 0.45000195503234863, 0.44980502128601074]
Python 3.3.0 (default, Mar 18 2013, 12:00:52)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> timeit.repeat("'€' * 1000 + 'z'")
[0.23264244200254325, 0.23299441300332546, 0.2325888039995334]
>>> timeit.repeat("'œ' * 1000 + '\U00010001'")
[0.3760241370036965, 0.37552819900156464, 0.3755163860041648]
>>> timeit.repeat("'\U00010001' * 1000 + 'œ'")
[0.28259182300098473, 0.2825558360054856, 0.2824251129932236]
>>> timeit.repeat("'\U00010002' * 1000 + 'a'")
[0.28227063300437294, 0.2815949220021139, 0.2829978369991295]
IIUC, while it may be true that Py3 is slightly slower than Py2 when the
string operation involves an internal representation change (all your
examples, and the second operation above), in the much more common case
it is considerably faster. This, and the fact that Py3 actually handles
the whole Unicode space without glitches, make it a better environment
in my eyes. Kudos to the core team!
Just my 0.45-0.28 cents,
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it | -- Fortunato Depero, 1929.
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-04-02 02:20 -0700 |
| Message-ID | <87dff083-14d8-4163-89f3-d78a9be6c802@c15g2000vbl.googlegroups.com> |
| In reply to | #42547 |
On 2 avr, 10:03, Chris Angelico <ros...@gmail.com> wrote: > On Tue, Apr 2, 2013 at 6:24 PM, jmfauth <wxjmfa...@gmail.com> wrote: > > An editor may reflect very well the example a gave. You enter > > thousand ascii chars, then - boum - as you enter a non ascii > > char, your editor (assuming is uses a mechanism like the FSR), > > has to internally reencode everything! > > That assumes that the editor stores the entire buffer as a single > Python string. Frankly, I think this unlikely; the nature of > insertions and deletions makes this impractical. (I've known editors > that do function this way. They're utterly unusable on large files.) > > ChrisA -------- No, no, no, no, ... as we say in French (this is a kindly form). The length of a string may have its importance. This bad behaviour may happen on every char. The most complicated chars are the chars with diacritics and ligatured [1, 2] chars, eg chars used in Arabic script [2]. It is somehow funny to see, the FSR "fails" precisely on problems Unicode will solve/handle, eg normalization or sorting [3]. No really a problem for those you are endorsing the good work Unicode does [5]. [1] A point which was not, in my mind, very well understood when I read the PEP393 discussion. [2] Take a unicode "TeX" compliant engine and toy with the decomposed form of these chars. A very good way, to understand what can be really a char, when you wish to process text "seriously". [3] I only test and tested these "chars" blindly with the help of the doc I have. Btw, when I test complicated "Arabic chars", I noticed, Py33 "crashes", it does not really crash, it get stucked in some king of infinite loop (or is it due to "timeit"?). [4] Am I the only one who test this kind of stuff? [5] Unicode is a fascinating construction. jmf
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-04-02 13:44 -0600 |
| Message-ID | <mailman.21.1364931932.3114.python-list@python.org> |
| In reply to | #42550 |
On Tue, Apr 2, 2013 at 3:20 AM, jmfauth <wxjmfauth@gmail.com> wrote: > It is somehow funny to see, the FSR "fails" precisely > on problems Unicode will solve/handle, eg normalization or > sorting [3]. Neither of these problems have anything to do with the FSR. Can you give us an example of normalization or sorting where Python 3.3 fails and Python 3.2 does not? > [3] I only test and tested these "chars" blindly with the help > of the doc I have. Btw, when I test complicated "Arabic chars", > I noticed, Py33 "crashes", it does not really crash, it get stucked > in some king of infinite loop (or is it due to "timeit"?). Without knowing what the actual test that you ran was, we have no way of answering that. Unless you give us more detail, my assumption would be that the number of repetitions that you passed to timeit was excessively large for the particular test case. > [4] Am I the only one who test this kind of stuff? No, you're just the only one who considers it important. Micro-benchmarks like the ones you have been reporting are *useful* when it comes to determining what operations can be better optimized, but they are not *important* in and of themselves. What is important is that actual, real-world programs are not significantly slowed by these kinds of optimizations. Until you can demonstrate that real programs are adversely affected by PEP 393, there is not in my opinion any regression that is worth worrying over.
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-03 14:31 +1100 |
| Message-ID | <3qadncD4-6fcPsbMnZ2dnUVZ_rqdnZ2d@westnet.com.au> |
| In reply to | #42600 |
Ian Kelly:
> Micro-benchmarks like the ones you have been reporting are *useful*
> when it comes to determining what operations can be better optimized,
> but they are not *important* in and of themselves. What is important
> is that actual, real-world programs are not significantly slowed by
> these kinds of optimizations. Until you can demonstrate that real
> programs are adversely affected by PEP 393, there is not in my opinion
> any regression that is worth worrying over.
The problem with only responding to issues with real-world programs
is that real-world programs are complex and their performance issues
often difficult to diagnose. See, for example, scons which is written in
Python and which has not been able to overcome performance problems over
several years.
(http://www.electric-cloud.com/blog/2010/07/21/a-second-look-at-scons-performance/)
Bottom-up performance work has advantages in that a narrow focus
area can be more easily analyzed and tested and can produce widely
applicable benefits.
The choice of comparison for the script wasn't arbitrary. Comparison
is one of the main building blocks of higher-level code. Sorting, for
example, depends strongly on comparison performance with a decrease in
comparison speed multiplied when applied to sorting.
Its unfortunate that stringbench.py does not contain any comparison
or sorting tests.
Sorting a million string list (all the file paths on a particular
computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so
we're out of the 'not noticeable by humans' range. Perhaps this is still
a 'micro-benchmark' - I'd just like to avoid adding email access to get
this over the threshold.
Here's some code. Replace the "if 1" with "if 0" on subsequent runs
to avoid the costly file system walk.
import os, time
from os.path import join, getsize
paths = []
if 1:
for root, dirs, files in os.walk('c:\\'):
for name in files:
paths.append(join(root, name))
with open("filelist.txt", "w") as f:
f.write("\n".join(paths))
else:
with open("filelist.txt", "r") as f:
paths = f.read().split("\n")
print(len(paths))
timeStart = time.time()
paths.sort()
timeEnd = time.time()
print("Time taken=", timeEnd - timeStart)
Neil
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-04-02 20:53 -0700 |
| Message-ID | <5f8ed721-7c89-4ffd-8f2b-21979cc3386a@kk11g2000pbb.googlegroups.com> |
| In reply to | #42621 |
On Apr 3, 8:31 am, Neil Hodgson <nhodg...@iinet.net.au> wrote: > Sorting a million string list (all the file paths on a particular > computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so > we're out of the 'not noticeable by humans' range. Perhaps this is still > a 'micro-benchmark' - I'd just like to avoid adding email access to get > this over the threshold. What does that last statement mean?
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-03 15:03 +1100 |
| Message-ID | <isSdnR9SovVON8bMnZ2dnUVZ_u-dnZ2d@westnet.com.au> |
| In reply to | #42622 |
rusi wrote:
> ...
>> a 'micro-benchmark' - I'd just like to avoid adding email access to get
>> this over the threshold.
>
> What does that last statement mean?
Its a reference to a comment by Jamie Zawinski (relatively famous
developer of Netscape Navigator and other things):
"Every program attempts to expand until it can read mail. Those
programs which cannot so expand are replaced by ones which can."
One of the games played in bug reporting and avoidance is to deny
that the report is a real problem. A short script is dismissed as
unrepresentative of actual programs. Once it can read email though, it
has to be a real program.
Neil
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-04-02 22:11 -0700 |
| Message-ID | <91e33518-4265-4c71-bc8d-49ef3b5cfe92@la7g2000pbc.googlegroups.com> |
| In reply to | #42624 |
On Apr 3, 9:03 am, Neil Hodgson <nhodg...@iinet.net.au> wrote: > rusi wrote: > > ... > >> a 'micro-benchmark' - I'd just like to avoid adding email access to get > >> this over the threshold. > > > What does that last statement mean? > > Its a reference to a comment by Jamie Zawinski (relatively famous > developer of Netscape Navigator and other things): And Xemacs (which is famous in the free sw world for other things!) > > "Every program attempts to expand until it can read mail. Those > programs which cannot so expand are replaced by ones which can." :-) Ok got it
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-03 17:22 +1100 |
| Message-ID | <mailman.37.1364970149.3114.python-list@python.org> |
| In reply to | #42624 |
On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson <nhodgson@iinet.net.au> wrote: > rusi wrote: > "Every program attempts to expand until it can read mail. Those programs > which cannot so expand are replaced by ones which can." In my personal experience, it's calculators. I put command-line calculators into *everything*... often in the form of more general executors, and thus restricted to admins, but it's still a calculator. For some reason, the ability to type "calc 1+2" and get back 3 is very satisfying to me. You know, in case I ever forget what one plus two makes. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-03 09:28 -0400 |
| Message-ID | <roy-E0DA9D.09280003042013@news.panix.com> |
| In reply to | #42632 |
In article <mailman.37.1364970149.3114.python-list@python.org>, Chris Angelico <rosuav@gmail.com> wrote: > On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson <nhodgson@iinet.net.au> wrote: > > rusi wrote: > > "Every program attempts to expand until it can read mail. Those programs > > which cannot so expand are replaced by ones which can." > > In my personal experience, it's calculators. I put command-line > calculators into *everything*... often in the form of more general > executors, and thus restricted to admins, but it's still a calculator. > > For some reason, the ability to type "calc 1+2" and get back 3 is very > satisfying to me. You know, in case I ever forget what one plus two > makes. I discovered recently that Spotlight (the OSX built-in search engine) can do this.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-04 00:38 +1100 |
| Message-ID | <mailman.58.1364996290.3114.python-list@python.org> |
| In reply to | #42664 |
On Thu, Apr 4, 2013 at 12:28 AM, Roy Smith <roy@panix.com> wrote: > In article <mailman.37.1364970149.3114.python-list@python.org>, > Chris Angelico <rosuav@gmail.com> wrote: > >> On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson <nhodgson@iinet.net.au> wrote: >> > rusi wrote: >> > "Every program attempts to expand until it can read mail. Those programs >> > which cannot so expand are replaced by ones which can." >> >> In my personal experience, it's calculators. I put command-line >> calculators into *everything*... often in the form of more general >> executors, and thus restricted to admins, but it's still a calculator. >> >> For some reason, the ability to type "calc 1+2" and get back 3 is very >> satisfying to me. You know, in case I ever forget what one plus two >> makes. > > I discovered recently that Spotlight (the OSX built-in search engine) > can do this. Good feature, not surprising. Google Search has had that feature for a while, and it just "feels right" to be able to look up information the same way regardless of its source. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-03 00:10 -0400 |
| Message-ID | <roy-E86676.00103603042013@news.panix.com> |
| In reply to | #42622 |
In article <5f8ed721-7c89-4ffd-8f2b-21979cc3386a@kk11g2000pbb.googlegroups.com>, rusi <rustompmody@gmail.com> wrote: > On Apr 3, 8:31 am, Neil Hodgson <nhodg...@iinet.net.au> wrote: > > > Sorting a million string list (all the file paths on a particular > > computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so > > we're out of the 'not noticeable by humans' range. On the other hand, how long did it take you to do the directory tree walk required to find those million paths? I'll bet a long longer than 0.78 seconds, so this gets lost in the noise. Still, it is unfortunate if sort performance got hurt significantly. My mind was blown a while ago when I discovered that python could sort a file of strings faster than the unix command-line sort utility. That's pretty impressive.
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-03 19:15 +1100 |
| Message-ID | <1f2dnfPBhY54eMbMnZ2dnUVZ_oSdnZ2d@westnet.com.au> |
| In reply to | #42625 |
Roy Smith:
> On the other hand, how long did it take you to do the directory tree
> walk required to find those million paths? I'll bet a long longer than
> 0.78 seconds, so this gets lost in the noise.
About 2 minutes. But that's just getting an example data set. Other
data sets may be loaded more quickly from databases or files or be
created by processing. Reading the example data from a file takes around
the same time as sorting.
Neil
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-03 09:25 -0400 |
| Message-ID | <roy-828AA4.09250603042013@news.panix.com> |
| In reply to | #42646 |
In article <1f2dnfPBhY54eMbMnZ2dnUVZ_oSdnZ2d@westnet.com.au>, Neil Hodgson <nhodgson@iinet.net.au> wrote: > Roy Smith: > > > On the other hand, how long did it take you to do the directory tree > > walk required to find those million paths? I'll bet a long longer than > > 0.78 seconds, so this gets lost in the noise. > > About 2 minutes. But that's just getting an example data set. Other > data sets may be loaded more quickly from databases or files or be > created by processing. Reading the example data from a file takes around > the same time as sorting. Fair enough. In fact, given that reading the file from disk is O(n) and sorting it is O(n log n), at some point, the sort will totally swamp the input time. Your original example just happened to be one of the unusual cases where the sort time is not the rate limiting factor in the overall process. I remember reading somewhere that more CPU cycles in the entire history of computing have been spend doing sorting than anything else.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-04 00:34 +1100 |
| Message-ID | <mailman.54.1364996056.3114.python-list@python.org> |
| In reply to | #42663 |
On Thu, Apr 4, 2013 at 12:25 AM, Roy Smith <roy@panix.com> wrote: > > Fair enough. In fact, given that reading the file from disk is O(n) and > sorting it is O(n log n), at some point, the sort will totally swamp the > input time. But given the much larger fixed cost of disk access, that might take an awful lot of strings... ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-03 05:32 +0000 |
| Message-ID | <515bbedb$0$29891$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42621 |
On Wed, 03 Apr 2013 14:31:03 +1100, Neil Hodgson wrote: > Sorting a million string list (all the file paths on a particular > computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so > we're out of the 'not noticeable by humans' range. Perhaps this is still > a 'micro-benchmark' - I'd just like to avoid adding email access to get > this over the threshold. I cannot confirm this performance regression. On my laptop (Debian Linux, not Windows), I can sort a million file names in approximately 1.2 seconds in both Python 3.2 and 3.3. There is no meaningful difference in speed between the two versions. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Terry Jan Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2013-04-03 02:19 -0400 |
| Message-ID | <mailman.36.1364970003.3114.python-list@python.org> |
| In reply to | #42629 |
On 4/3/2013 1:32 AM, Steven D'Aprano wrote: > On Wed, 03 Apr 2013 14:31:03 +1100, Neil Hodgson wrote: > >> Sorting a million string list (all the file paths on a particular >> computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so >> we're out of the 'not noticeable by humans' range. Perhaps this is still >> a 'micro-benchmark' - I'd just like to avoid adding email access to get >> this over the threshold. What system *and* what compiler and compiler options. Unless 3.2 and 3.3 are both compiler with the same compiler and settings, we do not know the source of the difference. > I cannot confirm this performance regression. On my laptop (Debian Linux, > not Windows), I can sort a million file names in approximately 1.2 > seconds in both Python 3.2 and 3.3. There is no meaningful difference in > speed between the two versions. I am guessing that Neil's undisclosed system (that I can see) is Windows, since other benchmarks have been more different on Windows than on *nix. Given that we *know* that the 3.2 and 3.3 distribution are compiled with different compilers and run with different C runtimes, it is possible that some of the difference is from that and not from python at all. tjr
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-03 17:27 +1100 |
| Message-ID | <iaadnbkQ-skQUcbMnZ2dnUVZ_qydnZ2d@westnet.com.au> |
| In reply to | #42631 |
Terry Jan Reedy:
> What system *and* what compiler and compiler options. Unless 3.2 and 3.3
> are both compiler with the same compiler and settings, we do not know
> the source of the difference.
The version signatures are:
3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)]
3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit
(Intel)]
The machine is running Windows 8 64-bit (the Python installations
are 32-bit though) and the processor is an i3 2350M running at 2.3 GHz.
Neil
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-03 17:25 +1100 |
| Message-ID | <mailman.38.1364970346.3114.python-list@python.org> |
| In reply to | #42629 |
On Wed, Apr 3, 2013 at 4:32 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Wed, 03 Apr 2013 14:31:03 +1100, Neil Hodgson wrote: > >> Sorting a million string list (all the file paths on a particular >> computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so >> we're out of the 'not noticeable by humans' range. Perhaps this is still >> a 'micro-benchmark' - I'd just like to avoid adding email access to get >> this over the threshold. > > I cannot confirm this performance regression. On my laptop (Debian Linux, > not Windows), I can sort a million file names in approximately 1.2 > seconds in both Python 3.2 and 3.3. There is no meaningful difference in > speed between the two versions. I'd be curious to know the sorts of characters used. Given that it's probably a narrow-vs-wide Python difference we're talking here, the actual distribution of codepoints may well make a difference. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web