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 1 of 11 [1] 2 3 … 11 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-26 08:51 +1100 |
| Subject | Performance of int/long in Python 3 |
| Message-ID | <mailman.3703.1364248275.2939.python-list@python.org> |
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?
The cost is clear. Compare these methods for calculating the sum of
all numbers up to 65535, which stays under 2^31:
def range_sum(n):
return sum(range(n+1))
def forloop(n):
tot=0
for i in range(n+1):
tot+=i
return tot
def forloop_offset(n):
tot=1000000000000000
for i in range(n+1):
tot+=i
return tot-1000000000000000
import timeit
import sys
print(sys.version)
print("inline: %d"%sum(range(65536)))
print(timeit.timeit("sum(range(65536))",number=1000))
for func in ['range_sum','forloop','forloop_offset']:
print("%s: %r"%(func,(globals()[func](65535))))
print(timeit.timeit(func+"(65535)","from __main__ import "+func,number=1000))
Windows XP:
C:\>python26\python inttime.py
2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
inline: 2147450880
2.36770455463
range_sum: 2147450880
2.61778550067
forloop: 2147450880
7.91409131608
forloop_offset: 2147450880L
23.3116954809
C:\>python33\python inttime.py
3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)]
inline: 2147450880
5.25038713020789
range_sum: 2147450880
5.412975112758745
forloop: 2147450880
17.875799577879313
forloop_offset: 2147450880
19.31672544974291
Debian Wheezy:
rosuav@sikorsky:~$ python inttime.py
2.7.3 (default, Jan 2 2013, 13:56:14)
[GCC 4.7.2]
inline: 2147450880
1.92763710022
range_sum: 2147450880
1.93409109116
forloop: 2147450880
5.14633893967
forloop_offset: 2147450880
5.13459300995
rosuav@sikorsky:~$ python3 inttime.py
3.2.3 (default, Feb 20 2013, 14:44:27)
[GCC 4.7.2]
inline: 2147450880
2.884124994277954
range_sum: 2147450880
2.6586129665374756
forloop: 2147450880
7.660192012786865
forloop_offset: 2147450880
8.11817193031311
On 2.6/2.7, there's a massive penalty for switching to longs; on
3.2/3.3, the two for-loop versions are nearly identical in time.
(Side point: I'm often seeing that 3.2 on Linux is marginally faster
calling my range_sum function than doing the same thing inline. I do
not understand this. If anyone can explain what's going on there, I'm
all ears!)
Python 3's int is faster than Python 2's long, but slower than Python
2's int. So the question really is, would a two-form representation be
beneficial, and if so, is it worth the coding trouble?
ChrisA
[toc] | [next] | [standalone]
| From | Cousin Stanley <cousinstanley@gmail.com> |
|---|---|
| Date | 2013-03-25 23:35 +0000 |
| Message-ID | <kiqn0c$1l7$1@dont-email.me> |
| In reply to | #41834 |
Chris Angelico wrote: > The Python 3 merge of int and long has effectively penalized > small-number arithmetic by removing an optimization. > .... > The cost is clear. > .... The cost isn't quite as clear under Debian Wheezy here .... Stanley C. Kitching Debian Wheezy python inline range_sum forloop forloop_offset 2.7.3 3.1359 3.0725 9.0778 15.6475 3.2.3 2.8226 2.8074 13.47624 13.6430 # --------------------------------------------------------- Chris Angelico Debian Wheezy python inline range_sum forloop forloop_offset 2.7.3 1.9276 1.9341 5.1463 5.1346 3.2.3 2.8841 2.6586 7.6602 8.1182 -- Stanley C. Kitching Human Being Phoenix, Arizona
[toc] | [prev] | [next] | [standalone]
| From | Dan Stromberg <drsalists@gmail.com> |
|---|---|
| Date | 2013-03-25 17:12 -0700 |
| Message-ID | <mailman.3707.1364256738.2939.python-list@python.org> |
| In reply to | #41837 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Mar 25, 2013 at 4:35 PM, Cousin Stanley <cousinstanley@gmail.com>wrote: > > Chris Angelico wrote: > > > The Python 3 merge of int and long has effectively penalized > > small-number arithmetic by removing an optimization. > > .... > > The cost is clear. > > .... > I thought I heard that Python 3.x will use machine words for small integers, and automatically coerce internally to a 2.x long as needed. Either way, it's better to have a small performance cost to avoid problems when computers move from 32 to 64 bit words, or 64 bit to 128 bit words. With 3.x int's, you don't have to worry about a new crop of CPU's breaking your code.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-26 17:26 +1100 |
| Message-ID | <mailman.3719.1364279193.2939.python-list@python.org> |
| In reply to | #41837 |
On Tue, Mar 26, 2013 at 10:35 AM, Cousin Stanley <cousinstanley@gmail.com> wrote: > > Chris Angelico wrote: > >> The Python 3 merge of int and long has effectively penalized >> small-number arithmetic by removing an optimization. >> .... >> The cost is clear. >> .... > > The cost isn't quite as clear > under Debian Wheezy here .... > > Stanley C. Kitching > Debian Wheezy > > python inline range_sum forloop forloop_offset > > 2.7.3 3.1359 3.0725 9.0778 15.6475 > > 3.2.3 2.8226 2.8074 13.47624 13.6430 Interesting, so your 3.x sum() is optimizing something somewhere. Strange. Are we both running the same Python? I got those from apt-get, aiming for consistency (rather than building a 3.3 from source). The cost is still visible in the for-loop versions, though, and you're still seeing the <2^31 and >2^31 for-loops behave the same way in 3.x but perform quite differently in 2.x. So it's looking like things are mostly the same. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Cousin Stanley <cousinstanley@gmail.com> |
|---|---|
| Date | 2013-03-26 13:38 +0000 |
| Message-ID | <kis8cu$gmd$1@dont-email.me> |
| In reply to | #41857 |
Chris Angelico wrote:
> Interesting, so your 3.x sum() is optimizing something somewhere.
> Strange. Are we both running the same Python ?
>
> I got those from apt-get
> ....
I also installed python here under Debian Wheezy
via apt-get and our versions look to be the same ....
-sk-
2.7.3 (default, Jan 2 2013, 16:53:07) [GCC 4.7.2]
3.2.3 (default, Feb 20 2013, 17:02:41) [GCC 4.7.2]
CPU : Intel(R) Celeron(R) D CPU 3.33GHz
-ca-
2.7.3 (default, Jan 2 2013, 13:56:14) [GCC 4.7.2]
3.2.3 (default, Feb 20 2013, 14:44:27) [GCC 4.7.2]
CPU : ???
Could differences in underlying CPU architecture
lead to our differing python integer results ?
--
Stanley C. Kitching
Human Being
Phoenix, Arizona
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-27 01:08 +1100 |
| Message-ID | <mailman.3747.1364306899.2939.python-list@python.org> |
| In reply to | #41900 |
On Wed, Mar 27, 2013 at 12:38 AM, Cousin Stanley <cousinstanley@gmail.com> wrote: > Chris Angelico wrote: > >> Interesting, so your 3.x sum() is optimizing something somewhere. >> Strange. Are we both running the same Python ? >> >> I got those from apt-get >> .... > > I also installed python here under Debian Wheezy > via apt-get and our versions look to be the same .... > > -sk- > > 2.7.3 (default, Jan 2 2013, 16:53:07) [GCC 4.7.2] > > 3.2.3 (default, Feb 20 2013, 17:02:41) [GCC 4.7.2] > > CPU : Intel(R) Celeron(R) D CPU 3.33GHz > > > -ca- > > 2.7.3 (default, Jan 2 2013, 13:56:14) [GCC 4.7.2] > > 3.2.3 (default, Feb 20 2013, 14:44:27) [GCC 4.7.2] > > CPU : ??? > > > Could differences in underlying CPU architecture > lead to our differing python integer results ? Doubtful. I have Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz quad-core with hyperthreading, but I'm only using one core for this job. I've run the tests several times and each time, Py2 is a shade under two seconds for inline/range_sum, and Py3 is about 2.5 seconds for each. Fascinating. Just for curiosity's sake, I spun up the tests on my reiplophobic server, still running Ubuntu Karmic. Pentium(R) Dual-Core CPU E6500 @ 2.93GHz. gideon@gideon:~$ python inttime.py 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] inline: 2147450880 2.7050409317 range_sum: 2147450880 2.64918494225 forloop: 2147450880 6.58765792847 forloop_offset: 2147450880L 16.5167789459 gideon@gideon:~$ python3 inttime.py 3.1.1+ (r311:74480, Nov 2 2009, 14:49:22) [GCC 4.4.1] inline: 2147450880 4.44533085823 range_sum: 2147450880 4.37314105034 forloop: 2147450880 12.4834370613 forloop_offset: 2147450880 13.5000522137 Once again, Py3 is slower on small integers than Py2. So where's the difference with your system? This is really weird! I assume you can repeat the tests and get the same result every time? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Cousin Stanley <cousinstanley@gmail.com> |
|---|---|
| Date | 2013-03-26 16:41 +0000 |
| Message-ID | <kisj39$jvp$1@dont-email.me> |
| In reply to | #41902 |
Chris Angelico wrote: > Once again, Py3 is slower on small integers than Py2. Chris Angelico Ubuntu Karmic. Pentium(R) Dual-Core CPU E6500 @ 2.93GHz. python inline range_sum forloop forloop_offset 2.6.4 2.7050 2.6492 6.5877 16.5168 3.1.1 4.4453 4.3731 12.4834 13.5001 You do seem to have a slight py3 improvement under ubuntu for the forloop_offset case .... > So where's the difference with your system ? CPU ???? > This is really weird ! Yep ... > I assume you can repeat the tests > and get the same result every time ? Yes .... First lines of numbers below are from yesterday while second lines are from today .... Stanley C. Kitching Debian Wheezy Intel(R) Celeron(R) D CPU 3.33GH Single Core python inline range_sum forloop forloop_offset 2.7.3 3.1359 3.0725 9.0778 15.6475 2.7.3 3.0382 3.1452 9.8799 16.8579 3.2.3 2.8226 2.8074 13.47624 13.6430 3.2.3 2.8331 2.8228 13.54151 13.8716 -- Stanley C. Kitching Human Being Phoenix, Arizona
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-27 03:54 +1100 |
| Message-ID | <mailman.3756.1364316890.2939.python-list@python.org> |
| In reply to | #41922 |
On Wed, Mar 27, 2013 at 3:41 AM, Cousin Stanley <cousinstanley@gmail.com> wrote: > > Chris Angelico wrote: > >> Once again, Py3 is slower on small integers than Py2. > > Chris Angelico > Ubuntu Karmic. > Pentium(R) Dual-Core CPU E6500 @ 2.93GHz. > > python inline range_sum forloop forloop_offset > > 2.6.4 2.7050 2.6492 6.5877 16.5168 > > 3.1.1 4.4453 4.3731 12.4834 13.5001 > > You do seem to have a slight py3 improvement > under ubuntu for the forloop_offset case .... Yes, that's correct. The forloop_offset one is using long integers in all cases. (Well, on Py2 it's adding a series of ints to a long, but the arithmetic always has to be done with longs.) Python 3 has had some improvements done, but the main thing is that there's a massive spike in the Py2 time, while Py3 has _already paid_ that cost - as evidenced by the closeness of the forloop and forloop_offset times on Py3. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2013-03-26 14:24 -0400 |
| Message-ID | <mailman.3765.1364322291.2939.python-list@python.org> |
| In reply to | #41922 |
On 3/26/2013 12:41 PM, Cousin Stanley wrote: >> So where's the difference with your system ? > > CPU ???? Compilers and compiler settings can also make a difference. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-26 11:50 -0700 |
| Message-ID | <a52fbe9d-db14-4ed2-bb49-adfb4b56f973@k4g2000yqn.googlegroups.com> |
| In reply to | #41834 |
On 25 mar, 22:51, Chris Angelico <ros...@gmail.com> wrote: > 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 ... ------ A character is not an integer (short form). jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-27 06:03 +1100 |
| Message-ID | <mailman.3771.1364324590.2939.python-list@python.org> |
| In reply to | #41941 |
On Wed, Mar 27, 2013 at 5:50 AM, jmfauth <wxjmfauth@gmail.com> wrote: > On 25 mar, 22:51, Chris Angelico <ros...@gmail.com> wrote: >> 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 ... > > ------ > > A character is not an integer (short form). So? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-26 13:44 -0700 |
| Message-ID | <0b779c80-4f50-4716-8c30-47755c15f304@m12g2000yqp.googlegroups.com> |
| In reply to | #41943 |
On 26 mar, 20:03, Chris Angelico <ros...@gmail.com> wrote: > On Wed, Mar 27, 2013 at 5:50 AM, jmfauth <wxjmfa...@gmail.com> wrote: > > On 25 mar, 22:51, Chris Angelico <ros...@gmail.com> wrote: > >> 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 ... > > > ------ > > > A character is not an integer (short form). > > So? > > ChrisA A character is not an integer. jmf
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-03-26 20:50 +0000 |
| Message-ID | <mailman.3774.1364330979.2939.python-list@python.org> |
| In reply to | #41947 |
On 26/03/2013 20:44, jmfauth wrote: > On 26 mar, 20:03, Chris Angelico <ros...@gmail.com> wrote: >> On Wed, Mar 27, 2013 at 5:50 AM, jmfauth <wxjmfa...@gmail.com> wrote: >>> On 25 mar, 22:51, Chris Angelico <ros...@gmail.com> wrote: >>>> 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 ... >> >>> ------ >> >>> A character is not an integer (short form). >> >> So? >> >> ChrisA > > A character is not an integer. > > jmf > But you are an idiot. -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2013-03-26 21:08 +0000 |
| Message-ID | <kit2p7$rut$1@reader2.panix.com> |
| In reply to | #41949 |
On 2013-03-26, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 26/03/2013 20:44, jmfauth wrote:
>>>
>>>> A character is not an integer (short form).
>>>
>>> So?
>>
>> A character is not an integer.
>>
>> jmf
>
> But you are an idiot.
I think we all agree that jmf is a character.
So we've established that no characters are integers, but some
characters are idiots.
Does that allow us to determine wheter integers are idiots or not?
--
Grant Edwards grant.b.edwards Yow! All of life is a blur
at of Republicans and meat!
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-27 08:14 +1100 |
| Message-ID | <mailman.3776.1364332489.2939.python-list@python.org> |
| In reply to | #41951 |
On Wed, Mar 27, 2013 at 8:08 AM, Grant Edwards <invalid@invalid.invalid> wrote: > On 2013-03-26, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: >> On 26/03/2013 20:44, jmfauth wrote: >>>> >>>>> A character is not an integer (short form). >>>> >>>> So? >>> >>> A character is not an integer. >>> >>> jmf >> >> But you are an idiot. > > I think we all agree that jmf is a character. > > So we've established that no characters are integers, but some > characters are idiots. > > Does that allow us to determine wheter integers are idiots or not? No, it doesn't. I'm fairly confident that most of them are not... however, I have my eye on 42. He gets around, a bit, but never seems to do anything very useful. I'd think twice before hiring him. But 1, now, he's a good fellow. Even when things get divisive, he's the voice of unity. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2013-03-27 12:10 +1300 |
| Message-ID | <areo6iFb3lfU1@mid.individual.net> |
| In reply to | #41952 |
> On Wed, Mar 27, 2013 at 8:08 AM, Grant Edwards <invalid@invalid.invalid> wrote: > >>Does that allow us to determine wheter integers are idiots or not? > > No, it doesn't. I'm fairly confident that most of them are not... > however, I have my eye on 42. He thought he was equal to 6 x 9 at one point, which seems pretty idiotic to me. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-03-26 19:19 -0400 |
| Message-ID | <mailman.3811.1364402853.2939.python-list@python.org> |
| In reply to | #41961 |
On 03/26/2013 07:10 PM, Gregory Ewing wrote: >> On Wed, Mar 27, 2013 at 8:08 AM, Grant Edwards >> <invalid@invalid.invalid> wrote: >> >>> Does that allow us to determine wheter integers are idiots or not? >> >> No, it doesn't. I'm fairly confident that most of them are not... >> however, I have my eye on 42. > > He thought he was equal to 6 x 9 at one point, which > seems pretty idiotic to me. > Not in base 13. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-03-26 21:26 +0000 |
| Message-ID | <mailman.3778.1364333002.2939.python-list@python.org> |
| In reply to | #41951 |
On 26/03/2013 21:14, Chris Angelico wrote: > On Wed, Mar 27, 2013 at 8:08 AM, Grant Edwards <invalid@invalid.invalid> wrote: >> On 2013-03-26, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: >>> On 26/03/2013 20:44, jmfauth wrote: >>>>> >>>>>> A character is not an integer (short form). >>>>> >>>>> So? >>>> >>>> A character is not an integer. >>>> >>>> jmf >>> >>> But you are an idiot. >> >> I think we all agree that jmf is a character. >> >> So we've established that no characters are integers, but some >> characters are idiots. >> >> Does that allow us to determine wheter integers are idiots or not? > > No, it doesn't. I'm fairly confident that most of them are not... > however, I have my eye on 42. He gets around, a bit, but never seems > to do anything very useful. I'd think twice before hiring him. > > But 1, now, he's a good fellow. Even when things get divisive, he's > the voice of unity. > > ChrisA > Which reminds me, why do people on newsgroups often refer to 101, my favourite number? I mean, do we really care about the number of a room that Eric Blair worked in when he was at the BBC? -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-03-26 17:28 -0400 |
| Message-ID | <mailman.3779.1364333340.2939.python-list@python.org> |
| In reply to | #41951 |
On 03/26/2013 05:14 PM, Chris Angelico wrote: > <snip> >> Does that allow us to determine wheter integers are idiots or not? > > No, it doesn't. I'm fairly confident that most of them are not... > however, I have my eye on 42. He gets around, a bit, but never seems > to do anything very useful. I'd think twice before hiring him. Ah, 42, the "Answer to Life, the Universe, and Everything" -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2013-03-26 23:14 -0400 |
| Message-ID | <mailman.3792.1364354075.2939.python-list@python.org> |
| In reply to | #41951 |
On Wed, 27 Mar 2013 08:14:46 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:
> No, it doesn't. I'm fairly confident that most of them are not...
> however, I have my eye on 42. He gets around, a bit, but never seems
> to do anything very useful. I'd think twice before hiring him.
>
> But 1, now, he's a good fellow. Even when things get divisive, he's
> the voice of unity.
>
Unless he's also #6 (in which case #2 is in for trouble)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web