Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #71001 > unrolled thread
| Started by | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| First post | 2014-05-06 21:19 -0400 |
| Last post | 2014-05-08 10:47 -0400 |
| Articles | 20 on this page of 155 — 34 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: The “does Python have variables?” debate Ned Batchelder <ned@nedbatchelder.com> - 2014-05-06 21:19 -0400
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-07 09:18 +0300
Re: The “does Python have variables?” debate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-07 09:51 +0100
Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-07 06:00 -0700
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-07 17:17 +0300
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 00:30 +1000
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 00:14 +1000
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-07 17:20 +0300
Re: The “does Python have variables?” debate Jerry Hill <malaclypse2@gmail.com> - 2014-05-07 11:48 -0400
Re: The “does Python have variables?” debate Mark H Harris <harrismh777@gmail.com> - 2014-05-07 14:31 -0500
Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 05:57 +1000
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 00:15 +0300
Re: The “does Python have variables?” debate Mark H Harris <harrismh777@gmail.com> - 2014-05-07 16:35 -0500
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 01:27 +0000
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 12:09 +1000
Re: The “does Python have variables?” debate Steven D'Aprano <steve@pearwood.info> - 2014-05-08 03:41 +0000
Re: The “does Python have variables?” debate Dan Sommers <dan@tombstonezero.net> - 2014-05-08 03:43 +0000
Re: The “does Python have variables?” debate Mark H Harris <harrismh777@gmail.com> - 2014-05-09 17:34 -0500
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 01:11 +0000
Re: The “does Python have variables?” debate Larry Hudson <orgnut@yahoo.com> - 2014-05-10 00:46 -0700
Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 10:35 +1000
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 01:32 +0000
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 09:19 +0300
Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 16:40 +1000
Re: The "does Python have variables?" debate Rustom Mody <rustompmody@gmail.com> - 2014-05-07 23:50 -0700
Re: The "does Python have variables?" debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 10:03 +0300
Re: The “does Python have variables?” debate Ned Batchelder <ned@nedbatchelder.com> - 2014-05-07 21:33 -0400
Re: The “does Python have variables?” debate Johannes Schneider <johannes.schneider@galileo-press.de> - 2014-05-08 09:26 +0200
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-09 00:54 +0000
Re: The “does Python have variables?” debate Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org> - 2014-05-08 10:07 +0200
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 18:14 +1000
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 13:22 +0000
Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 18:34 +1000
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 12:43 +0300
Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 21:14 +1000
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 15:01 +0300
Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-09 05:14 +1000
Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 14:50 -0700
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-09 00:02 +0000
Re: The � debate Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-05-09 13:10 +1200
Re: The � debate Ben Finney <ben@benfinney.id.au> - 2014-05-09 13:13 +1000
Re: The � debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 01:34 +0000
Re: The � debate Mark H Harris <harrismh777@gmail.com> - 2014-05-09 21:34 -0500
Re: The � debate Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-05-10 17:58 +1200
Re: The � debate Chris Angelico <rosuav@gmail.com> - 2014-05-10 17:10 +1000
Re: The � debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 07:48 +0000
Re: The � debate Chris Angelico <rosuav@gmail.com> - 2014-05-10 18:01 +1000
Re: The � debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-10 11:21 +0300
Re: The � debate Rustom Mody <rustompmody@gmail.com> - 2014-05-10 02:05 -0700
Re: The � debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-10 12:30 -0700
Re: The � debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-10 11:18 +0300
Re: The � debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 09:31 +0000
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 13:18 +0000
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 23:46 +1000
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 14:22 +0000
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 00:51 +1000
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 16:04 +0000
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 02:10 +1000
Re: The “does Python have variables?” debate Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-08 21:02 -0400
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-09 01:32 +0000
Re: The “does Python have variables?” debate Roy Smith <roy@panix.com> - 2014-05-08 22:21 -0400
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 12:31 +1000
Re: The "does Python have variables?" debate Rustom Mody <rustompmody@gmail.com> - 2014-05-08 22:40 -0700
Re: The "does Python have variables?" debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 15:51 +1000
Re: The "does Python have variables?" debate Rustom Mody <rustompmody@gmail.com> - 2014-05-09 07:09 -0700
Re: The "does Python have variables?" debate Chris Angelico <rosuav@gmail.com> - 2014-05-10 00:29 +1000
Re: The "does Python have variables?" debate Rustom Mody <rustompmody@gmail.com> - 2014-05-09 09:07 -0700
Re: The “does Python have variables?â€瑩 debate Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-09 19:51 -0400
Re: The “does Python have variables?â€瑩 debate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-10 01:03 +0100
Fortran (Was: The "does Python have variables?" debate) Roy Smith <roy@panix.com> - 2014-05-10 09:42 -0400
Re: Fortran (Was: The "does Python have variables?" debate) Terry Reedy <tjreedy@udel.edu> - 2014-05-10 14:31 -0400
Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 01:17 -0500
Re: Fortran (Was: The "does Python have variables?" debate) Rustom Mody <rustompmody@gmail.com> - 2014-05-11 00:01 -0700
Re: Fortran (Was: The "does Python have variables?" debate) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 07:09 +0000
Re: Fortran (Was: The "does Python have variables?" debate) Tomasz Rola <rtomek@ceti.pl> - 2014-05-11 18:09 +0200
Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-11 19:27 +0300
Re: Fortran Roy Smith <roy@panix.com> - 2014-05-11 13:51 -0400
Re: Fortran Chris Angelico <rosuav@gmail.com> - 2014-05-12 04:08 +1000
Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 23:51 +0000
Re: Fortran Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-12 01:27 +0100
Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-12 02:28 +0000
Re: Fortran Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-12 10:05 +0100
Re: Fortran Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-12 20:52 -0400
Re: Fortran Ethan Furman <ethan@stoneleaf.us> - 2014-05-11 11:05 -0700
Re: Fortran Chris Angelico <rosuav@gmail.com> - 2014-05-12 04:33 +1000
Re: Fortran Roy Smith <roy@panix.com> - 2014-05-11 14:43 -0400
Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 23:15 +0000
Re: Fortran MRAB <python@mrabarnett.plus.com> - 2014-05-12 00:51 +0100
Re: Fortran Roy Smith <roy@panix.com> - 2014-05-11 20:14 -0400
Re: Fortran alister <alister.nospam.ware@ntlworld.com> - 2014-05-12 14:14 +0000
Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-12 01:11 +0000
Re: Fortran Dave Angel <d@davea.name> - 2014-05-11 23:27 -0400
Re: Fortran Grant Edwards <invalid@invalid.invalid> - 2014-05-12 14:07 +0000
Re: Fortran Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-11 21:12 -0400
Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-12 02:42 +1000
Re: Fortran Tomasz Rola <rtomek@ceti.pl> - 2014-05-11 20:04 +0200
Re: Fortran Chris Angelico <rosuav@gmail.com> - 2014-05-12 04:12 +1000
Re: Fortran (Was: The "does Python have variables?" debate) Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-05-11 19:05 +0200
Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 13:54 -0500
Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-12 04:59 +1000
Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 14:14 -0500
Re: Fortran (Was: The "does Python have variables?" debate) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-29 14:06 +0000
Re: Fortran (Was: The "does Python have variables?" debate) Peter Pearson <ppearson@nowhere.invalid> - 2014-05-29 17:53 +0000
Re: Fortran (Was: The "does Python have variables?" debate) Dave Angel <davea@davea.name> - 2014-05-11 23:10 -0400
Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 23:10 -0500
Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 23:26 -0500
Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-12 14:53 +1000
Re: Fortran (Was: The "does Python have variables?" debate) Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-05-12 10:44 +0200
Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-13 00:33 -0500
Re: Fortran (Was: The "does Python have variables?" debate) Steven D'Aprano <steve@pearwood.info> - 2014-05-13 05:48 +0000
Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-13 00:55 -0500
Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-13 15:56 +1000
Re: Fortran (Was: The "does Python have variables?" debate) Steven D'Aprano <steve@pearwood.info> - 2014-05-13 09:34 +0000
Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-13 20:00 +1000
Re: Fortran (Was: The "does Python have variables?" debate) Rustom Mody <rustompmody@gmail.com> - 2014-05-13 03:44 -0700
Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-13 20:50 +1000
Re: Fortran (Was: The "does Python have variables?" debate) Gene Heskett <gheskett@wdtv.com> - 2014-05-13 02:31 -0400
Re: Fortran (Was: The "does Python have variables?" debate) Steven D'Aprano <steve@pearwood.info> - 2014-05-13 07:22 +0000
Re: Fortran (Was: The "does Python have variables?" debate) Roy Smith <roy@panix.com> - 2014-05-13 07:16 -0400
Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-13 21:21 +1000
Re: Fortran (Was: The "does Python have variables?" debate) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-13 14:42 +0100
Re: Fortran (Was: The "does Python have variables?" debate) Gene Heskett <gheskett@wdtv.com> - 2014-05-13 07:42 -0400
Re: Fortran Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-05-13 19:33 +0200
Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-13 22:57 +0300
Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-14 00:10 +0000
Re: Fortran Ian Kelly <ian.g.kelly@gmail.com> - 2014-05-13 21:43 -0600
Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-14 07:35 +0300
Re: Fortran Steven D'Aprano <steve@pearwood.info> - 2014-05-14 06:58 +0000
Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-14 11:46 +0300
Re: Fortran Sturla Molden <sturla.molden@gmail.com> - 2014-05-14 23:05 +0000
struct.unpack: why 's' fmt char convert to bytestring GuoChao <cx63@outlook.com> - 2014-05-15 20:34 +0800
Re: struct.unpack: why 's' fmt char convert to bytestring Dave Angel <davea@davea.name> - 2014-05-15 09:49 -0400
Re: struct.unpack: why 's' fmt char convert to bytestring MRAB <python@mrabarnett.plus.com> - 2014-05-15 15:47 +0100
Re: Fortran Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-05-14 15:13 +0200
Re: Fortran albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-29 14:26 +0000
Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-29 17:50 +0300
Re: Fortran Chris Angelico <rosuav@gmail.com> - 2014-05-30 00:58 +1000
Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-29 18:09 +0300
Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-29 17:57 +0000
Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-29 21:55 +0300
Re: The “does Python have variables?” debate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-09 09:13 +0100
Re: The “does Python have variables?” debate Michael Torrie <torriem@gmail.com> - 2014-05-08 08:06 -0600
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 00:13 +1000
Re: The “does Python have variables?” debate Terry Reedy <tjreedy@udel.edu> - 2014-05-08 15:21 -0400
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 23:06 +0300
Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 15:36 -0700
Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 17:05 -0700
Re: The “does Python have variables?” debate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-09 01:47 +0100
Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 00:57 +0000
Re: The “does Python have variables?” debate Roy Smith <roy@panix.com> - 2014-05-08 08:41 -0400
Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 22:54 +1000
Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 06:18 -0700
Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 17:03 +0300
Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 16:09 -0700
Re: The “does Python have variables?” debate "Neil D. Cerutti" <neilc@norwich.edu> - 2014-05-08 10:47 -0400
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-05-13 14:42 +0100 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9966.1399988465.18130.python-list@python.org> |
| In reply to | #71469 |
On 13/05/2014 12:21, Chris Angelico wrote: > On Tue, May 13, 2014 at 9:16 PM, Roy Smith <roy@panix.com> wrote: >> Sometimes code is still running for 15 years because it's so wonderful >> nobody has been able to come up with anything better. Sometimes it's >> because nobody knows how it works anymore and everybody is afraid to >> touch it :-) > > And sometimes, both... > Or neither as you don't have the source :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@wdtv.com> |
|---|---|
| Date | 2014-05-13 07:42 -0400 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9959.1399981350.18130.python-list@python.org> |
| In reply to | #71446 |
On Tuesday 13 May 2014 03:22:28 Steven D'Aprano did opine And Gene did reply: > On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote: > > People who write buggy self-modifying code aren't paying attention. > > [...] > > > IMO, people who bad-mouth self-modifying code are folks who don't > > have the patience to do it right, because stable self-modifying code > > CAN most certainly be done. > > Many things *can* be done. The question is, is it worth the effort to > do it? The simplest code that meets the functional requirements is > usually the best. > > > Stable, dead reliable self modifying code CAN be written, I have done > > it. And that code was still in use at the tv station that I wrote it > > for 15 years later. > > Yep, and people have written stable, dead reliable unstructured code > using GOTO and possibly even COMEFROM too. Nevertheless, nobody serious > uses unstructured code these days. It takes much more effort to get it > stable and reliable in the first place. Maintenance is ten or a hundred > times harder and therefore more expensive. Chances are good that the > software you wrote 15 years ago is now a black box: it damn well better > work, because no-one knows how it works well enough to debug problems > or add new functionality. > > And after 15 years, I daresay that includes you. Actually, 34 years, but I have the advantage of having retained a copy on dead tree as well as a broadcast cart with a couple copies of it, on a shelf above where I am sitting. And, should tape machine ballistics change, I left an extensive tome on how to adjust it for that. The 1802 is a somewhat limited beast, but for all the processing it had to do on the falling edge of each vertical drive pulse (it drove the raw, homemade character generator to lay a new academy leader among other things), it had all the data constructed to generate those characters with 6 dma cycles per video field, and was all done in the middle of line 21 of an ntsc field, twiddling its thumbs until the next falling edge of house vertical drive. I also invented a drop frame version of the time code with half the error of the official version. Just because I could. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-05-13 19:33 +0200 |
| Subject | Re: Fortran |
| Message-ID | <871tvxtwgj.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #71427 |
Mark H Harris <harrismh777@gmail.com> writes: > On 5/12/14 3:44 AM, Alain Ketterlin wrote: >> When you are doing scientific computation, this overhead is >> unacceptable, because you'll have zillions of computations to perform. > > I'm still trying to sort that out. I have not tested this yet, but > it looks like Julia is fully dynamic (yes it has types too), and it > does parallel processing at its core, so the zillions of computations > are being handled all at once, depending on how many processors|cores > you have. The amount of parallelism is a property of the program, not a property of the language... I hope you don't expect all your julia statements to execute in parallel. (And Fortan/C/C++ have leveraged OpenMP and MPI for years. Julia's distributed arrays and fork-join model may make things a bit easier for the programmer, but I doubt it will lead to better performance.) >> Julia provides a way to make things fast: typing. If you provide >> explicit types, the dynamic typing part obviously disappears, and >> the overhead is removed. > > Julia is dynamic (depending on how far you want to go with that) > but what makes it fast is the JIT. It is almost accomplishing C/C++ > and FORTRAN speeds (even though dynamic) because it is compiling > on-the-fly. JITing by itself has little impact on performance (as unladden-swallow has shown for python). For the JIT to produce code as fast as a Fortan/C/C++ compiler would, two conditions must be met: 1) the JIT has to have as much information about types as the statically-typed language compilers have, and 2) the time spent by the JIT compiler has to be negligible compared to the time spent executing the code. If your program is not statically typed, the code produced by the JIT is very unlikely to be more efficient than the code that would be executed by the virtual machine (or interpreter), because the jitted code needs to do everything the virtual machine does. And the JIT takes time. [...] > Yes, and more+ Gnu GMP & MPFR are not new to me, but the wrapper > and repl are ! I am just realizing the power behind the libraries in > this context, but I am very impressed with the functionality wrapped > around the Gnu stuff... the interface is quite nice. Good. I don't know mathlab enough to see how it compares. >> Sorry, I was comparing to Fortran, and it's use in scientific computing. >> Self modifying code is totally irrelevant there. > > no, no, no... there has to be a value add for scientists to move > away from R or Matlab, or from FORTRAN. Why go to the trouble? [...] > Why?, glad you asked. Enter self modifying code for one. The > influence of Lisp|Scheme is potentially huge here. I wouldn't bet a penny on this. (Probably because I have yet to see a real, convincing application of self-modifying code. I mean something which is not covered by JITs---GPU shaders, and things like that.) The real nice thing that makes Julia a different language is the optional static typing, which the JIT can use to produce efficient code. It's the only meaningful difference with the current state of python. -- Alain.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-05-13 22:57 +0300 |
| Subject | Re: Fortran |
| Message-ID | <8761l9pi3n.fsf@elektro.pacujo.net> |
| In reply to | #71506 |
Alain Ketterlin <alain@dpt-info.u-strasbg.fr>:
> The real nice thing that makes Julia a different language is the
> optional static typing, which the JIT can use to produce efficient code.
> It's the only meaningful difference with the current state of python.
I'm guessing the two main performance roadblocks for Python are:
1. The dot notation is a hash table lookup instead of a fixed offset to
a vector.
2. The creation of a class instance generates a set of trampolines for
all methods. The trampolines are ordinary fields that can be
overridden.
Both features are critical to Python's "sex appeal;" I wouldn't give
them up for performance gains.
Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle. After all, the developer *could*
provide that static typing information in, like, 99.9% of the code. That
would be feat worthy of a Millennium Technology Prize. It would be like
having the cake and eating it, too.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-05-14 00:10 +0000 |
| Subject | Re: Fortran |
| Message-ID | <5372b488$0$29977$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #71509 |
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote: > Producing an effective JIT for Python seems like a formidable challenge > but not impossible in principle. Or in practice. http://pypy.org/ And it's predecessor: http://psyco.sourceforge.net/ -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-05-13 21:43 -0600 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9989.1400039536.18130.python-list@python.org> |
| In reply to | #71518 |
On Tue, May 13, 2014 at 6:10 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote: > >> Producing an effective JIT for Python seems like a formidable challenge >> but not impossible in principle. > > Or in practice. > > http://pypy.org/ > > And it's predecessor: http://psyco.sourceforge.net/ Also numba, which is reminiscent of psyco, but with more features and Python 3 support.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-05-14 07:35 +0300 |
| Subject | Re: Fortran |
| Message-ID | <87tx8tnfjc.fsf@elektro.pacujo.net> |
| In reply to | #71518 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote: > >> Producing an effective JIT for Python seems like a formidable challenge >> but not impossible in principle. > > Or in practice. > > http://pypy.org/ I'm having a hard time finding information on how well it performs wrt Java, for example. Did PyPy truly find the Philosophers' Stone? Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2014-05-14 06:58 +0000 |
| Subject | Re: Fortran |
| Message-ID | <537313fe$0$11109$c3e8da3@news.astraweb.com> |
| In reply to | #71532 |
On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote: > Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > >> On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote: >> >>> Producing an effective JIT for Python seems like a formidable >>> challenge but not impossible in principle. >> >> Or in practice. >> >> http://pypy.org/ > > I'm having a hard time finding information on how well it performs wrt > Java, for example. Did PyPy truly find the Philosophers' Stone? I don't understand your question. PyPy doesn't do anything with Java. In principle you could use PyPy's underlying toolchain to build a Java compiler, similar to the Python, Prolog and PHP compilers already made, but nobody has done so for Java so far as I know. http://morepypy.blogspot.com.au/2012/07/hello-everyone.html Or do you mean, how does PyPy compare with <insert name of Java compiler here>? I don't know. There are some old benchmarks here: http://attractivechaos.wordpress.com/2011/04/25/my-programming-language- benchmarks-plb/ but the person doing the benchmarks is by his own admission not a skilled Python programmer. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-05-14 11:46 +0300 |
| Subject | Re: Fortran |
| Message-ID | <87wqdobvd2.fsf@elektro.pacujo.net> |
| In reply to | #71535 |
Steven D'Aprano <steve@pearwood.info>: > On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote: >> I'm having a hard time finding information on how well it performs wrt >> Java, for example. Did PyPy truly find the Philosophers' Stone? > > [...] do you mean, how does PyPy compare with <insert name of Java > compiler here? I don't know. There are some old benchmarks here: > > http://attractivechaos.wordpress.com/2011/04/25/my-programming-language- > benchmarks-plb/ > > but the person doing the benchmarks is by his own admission not a > skilled Python programmer. That's what I'm after. The answer from the page is: Java 1.7 2.6 67.1 6.8 13.4 6.7 314.8 PyPy 19.5 8.5 84.1 4.0 7.3 12.3 236.0 None of the benchmark tests seems all that relevant, but the one that comes closest to being interesting is Column 1: Sudoku. There, Java is an order of magnitude faster (1.7 s vs 19.5 s). When Python equals Java performance, Java will lose its raison-d'être. Marko
[toc] | [prev] | [next] | [standalone]
| From | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| Date | 2014-05-14 23:05 +0000 |
| Subject | Re: Fortran |
| Message-ID | <mailman.10024.1400108766.18130.python-list@python.org> |
| In reply to | #71518 |
Ian Kelly <ian.g.kelly@gmail.com> wrote: > Also numba, which is reminiscent of psyco, but with more features and > Python 3 support. For numerical computing with NumPy, Numba tends to give performance comparable to -O2 in C. This is because it is very easy to do type inference in most scientific array computing. Numba is still a bit immature, though, compared to e.g. Cython. Sturla
[toc] | [prev] | [next] | [standalone]
| From | GuoChao <cx63@outlook.com> |
|---|---|
| Date | 2014-05-15 20:34 +0800 |
| Subject | struct.unpack: why 's' fmt char convert to bytestring |
| Message-ID | <mailman.10033.1400157356.18130.python-list@python.org> |
| In reply to | #71518 |
[Multipart message — attachments visible in raw view] — view raw
The Python documentation gives this same example:>>> record = b'raymond \x32\x12\x08\x01\x08'
>>> name, serialnum, school, gradelevel = unpack('<10sHHb', record)
but get different results as to 's', don't know why this change in Python 3? need extra work to encode...>>> name
>>> 'raymond ' # for 2.7>>> name
>>> b'raymond ' # for 3.3
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2014-05-15 09:49 -0400 |
| Subject | Re: struct.unpack: why 's' fmt char convert to bytestring |
| Message-ID | <mailman.10038.1400161772.18130.python-list@python.org> |
| In reply to | #71518 |
On 05/15/2014 08:34 AM, GuoChao wrote:
> The Python documentation gives this same example:>>> record = b'raymond \x32\x12\x08\x01\x08'
>>>> name, serialnum, school, gradelevel = unpack('<10sHHb', record)
> but get different results as to 's', don't know why this change in Python 3? need extra work to encode...>>> name
>>>> 'raymond ' # for 2.7>>> name
>>>> b'raymond ' # for 3.3
>>>>
>>>>
Please start a new thread, don't just change the subject and hope to
hijack this existing thread on Fortran.
But you also need a problem statement. What is it you're having trouble
with? Do you have some code that works differently in 3.3 and you want
to know how to fix it? If so, show what you've tried, what resulted,
and what you expected instead.
Please post in text form. This is a text list, and many people cannot
see your html at all. Others see it as improperly wrapped, which
thoroughly masks what you're trying to do. Even when I show it as html,
it doesn't make sense. Perhaps you're trying to retype the stuff,
rather than copy/pasting it from your terminal window.
I could comment on individual portions of your query, but hopefully when
you get one that's better organized, that won't be necessary.
--
DaveA
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2014-05-15 15:47 +0100 |
| Subject | Re: struct.unpack: why 's' fmt char convert to bytestring |
| Message-ID | <mailman.10044.1400165287.18130.python-list@python.org> |
| In reply to | #71518 |
On 2014-05-15 13:34, GuoChao wrote:
> T <https://docs.python.org/2.7/library/struct.html>he Python
> documentation gives this same example:
>
>>>>record = b'raymond\x32\x12\x08\x01\x08'
>>>>name, serialnum, school, gradelevel = unpack('<10sHHb', record)
>
> but get different results as to 's', don't know why this change in
> Python 3? need extra work to encode...
>
>>>>name
>>>>'raymond ' #for 2.7 <https://docs.python.org/2.7/library/struct.html>
>
>>>>name
>>>>b'raymond ' #for _3.3 <https://docs.python.org/3.3/library/struct.html>_
>
They are actually the same result; they are both bytestrings (a string
of bytes).
In Python 2, the 'str' class is for bytestrings and the 'unicode' class
is for Unicode strings, so 'abc' (or b'abc') is a bytestring and u'abc'
is a Unicode string.
In Python 3, the 'bytes' class is for bytestrings and the 'str' class
is for Unicode strings, so b'abc' is a bytestring and 'abc' is a
Unicode string.
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-05-14 15:13 +0200 |
| Subject | Re: Fortran |
| Message-ID | <87siocsdtc.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #71509 |
Marko Rauhamaa <marko@pacujo.net> writes:
> Alain Ketterlin <alain@dpt-info.u-strasbg.fr>:
>
>> The real nice thing that makes Julia a different language is the
>> optional static typing, which the JIT can use to produce efficient code.
>> It's the only meaningful difference with the current state of python.
>
> I'm guessing the two main performance roadblocks for Python are:
>
> 1. The dot notation is a hash table lookup instead of a fixed offset to
> a vector.
>
> 2. The creation of a class instance generates a set of trampolines for
> all methods. The trampolines are ordinary fields that can be
> overridden.
Do you suggest this as a checklist to decide whether Python is the
appropriate language for a task? ("Do you really need any of these? If
yes, use python.")
> Both features are critical to Python's "sex appeal;" I wouldn't give
> them up for performance gains.
There are cases where performance matters (especially, when it is
directly related to your electricity bill).
> Producing an effective JIT for Python seems like a formidable challenge
> but not impossible in principle. After all, the developer *could*
> provide that static typing information in, like, 99.9% of the code.
Not 99% of the code; the code that runs 99% of the time.
> That would be feat worthy of a Millennium Technology Prize.
Here is a fairly interesting blog post about what the WebKit developpers
do for javascript (including profile-directed type inference, as they
call it):
https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
-- Alain.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-05-29 14:26 +0000 |
| Subject | Re: Fortran |
| Message-ID | <5387437f$0$4935$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #71509 |
In article <8761l9pi3n.fsf@elektro.pacujo.net>, Marko Rauhamaa <marko@pacujo.net> wrote: <SNIP> > >Producing an effective JIT for Python seems like a formidable challenge >but not impossible in principle. After all, the developer *could* >provide that static typing information in, like, 99.9% of the code. That >would be feat worthy of a Millennium Technology Prize. It would be like >having the cake and eating it, too. I'm totally flabbergasted by comments like this. I always thought that the real point of JIT was that it can take advantage of type information that is not available until runtime. If it can infer that something is an integer, just before entering a loop to be executed millions of times, that should be a big win, not? > > >Marko -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-05-29 17:50 +0300 |
| Subject | Re: Fortran |
| Message-ID | <87mwe0zlk7.fsf@elektro.pacujo.net> |
| In reply to | #72238 |
albert@spenarnc.xs4all.nl (Albert van der Horst):
> I always thought that the real point of JIT was that it can take
> advantage of type information that is not available until runtime. If
> it can infer that something is an integer, just before entering a loop
> to be executed millions of times, that should be a big win, not?
JIT most generally refers to on-the-fly optimization of the code. In the
case of Java, the code to be executed is bytecode that is independent of
the CPU instruction set and thus needs to be interpreted. You could
perform the optimization before the execution and save the executable
binary, but the Java gods are reluctant to do that for ideological
reasons ("compile once, run everywhere").
Python code, too, is compiled into interpreted bytecode. Again, you
could compile it into machine code ahead of execution or perform the
compilation on the fly with JIT techniques. However, Python is so
ridiculously dynamic that such compilers have an extremely difficult
time making effective optimizations.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-30 00:58 +1000 |
| Subject | Re: Fortran |
| Message-ID | <mailman.10453.1401375519.18130.python-list@python.org> |
| In reply to | #72239 |
On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa <marko@pacujo.net> wrote: > Python code, too, is compiled into interpreted bytecode. Again, you > could compile it into machine code ahead of execution or perform the > compilation on the fly with JIT techniques. However, Python is so > ridiculously dynamic that such compilers have an extremely difficult > time making effective optimizations. I'd avoid the word "ridiculously" there. Python's dynamism is a feature, not a flaw. It's a feature with consequences (but then, what isn't), and if you don't want it, use a different language, but it's not ridiculous. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-05-29 18:09 +0300 |
| Subject | Re: Fortran |
| Message-ID | <87iooozkn0.fsf@elektro.pacujo.net> |
| In reply to | #72240 |
Chris Angelico <rosuav@gmail.com>: > On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa <marko@pacujo.net> wrote: >> Python code, too, is compiled into interpreted bytecode. Again, you >> could compile it into machine code ahead of execution or perform the >> compilation on the fly with JIT techniques. However, Python is so >> ridiculously dynamic that such compilers have an extremely difficult >> time making effective optimizations. > > I'd avoid the word "ridiculously" there. Python's dynamism is a > feature, not a flaw. It's a feature with consequences (but then, what > isn't), and if you don't want it, use a different language, but it's > not ridiculous. The ridiculous dynamism is the main selling point of high-level programming languages. I wouldn't have it any other way. But from the point of view of the JIT developer, it must feel like Alice in Wonderland. Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-05-29 17:57 +0000 |
| Subject | Re: Fortran |
| Message-ID | <53877506$0$29978$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #72239 |
On Thu, 29 May 2014 17:50:00 +0300, Marko Rauhamaa wrote:
> albert@spenarnc.xs4all.nl (Albert van der Horst):
>
>> I always thought that the real point of JIT was that it can take
>> advantage of type information that is not available until runtime. If
>> it can infer that something is an integer, just before entering a loop
>> to be executed millions of times, that should be a big win, not?
>
> JIT most generally refers to on-the-fly optimization of the code.
Using information available at run-time, which was Albert's point. Why
would you delay compilation to run-time if you're only going to use
information available at edit-time? You pay all the cost of delayed
compilation and get none of the benefits.
> In the
> case of Java, the code to be executed is bytecode that is independent of
> the CPU instruction set and thus needs to be interpreted.
Not so. There are Java compilers which compile to machine code.
http://www.excelsiorjet.com/
http://gcc.gnu.org/java/
Both are AOT (Ahead Of Time) compilers, but that's not important for this
discussion. If an AOT compiler can emit machine code, so can a JIT
compiler, and that's exactly what PyPy does:
http://morepypy.blogspot.com.au/2011/08/visualization-of-jitted-code.html
> You could
> perform the optimization before the execution and save the executable
> binary, but the Java gods are reluctant to do that for ideological
> reasons ("compile once, run everywhere").
Who are these Java gods of which you speak?
> Python code, too, is compiled into interpreted bytecode.
An unjustified assertion. The Python infrastructure is incredibly rich,
and compilers include many different strategies:
- compile to byte-code for some virtual machine
(e.g. JVM, .Net, Parrot)
- static compilation to machine-code;
- JIT compilation to machine-code;
- translation to some other language (e.g. Haskell, Javascript)
followed by compilation of that code to machine code.
I've already mentioned that PyPy compiles to machine code. So did its
predecessor, Psyco. Both are JIT compilers, as are Numba and Parakeet and
Pyston and Unladen Swallow[1].
Then there's at least one AOT compiler, Nuitka, which produces machine
code. It's not optimized yet, but there's only one guy working on this
project, and it's still young.
http://nuitka.net/posts/static-compilation-that-is-the-point.html
> Again, you
> could compile it into machine code ahead of execution or perform the
> compilation on the fly with JIT techniques.
You're talking as if this were only theoretical. It is not. The state of
the art in compiler techniques has advanced a lot since the old days of
the Pascal P-Machine. Parakeet, for example[2], compiles numeric
functions to optimized machine code on the fly using decorators, using
Static Single Assignment, which some wag described as being "covered in
Fisher Price's My First Compiler"[3].
> However, Python is so
> ridiculously dynamic that such compilers have an extremely difficult
> time making effective optimizations.
Anyone who used Psyco ten years ago would laugh at that statement, and
Psyco isn't even close to cutting edge.
[1] Unladen Swallow was not a failure. It's just that expectations were
so high ("OMG OMG Google is making a Python compiler this will be more
powerful than the Death Star and faster than time travel!!!1!") that it
couldn't help but be a disappointment.
[2] http://www.phi-node.com/2013/01/a-transformative-journey-from-python-to.html
[3] http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/
--
Steven D'Aprano
http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-05-29 21:55 +0300 |
| Subject | Re: Fortran |
| Message-ID | <87k394ct3t.fsf@elektro.pacujo.net> |
| In reply to | #72246 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> You're talking as if this were only theoretical. It is not. The state
> of the art in compiler techniques has advanced a lot since the old
> days of the Pascal P-Machine. Parakeet, for example[2], compiles
> numeric functions to optimized machine code on the fly using
> decorators, using Static Single Assignment, which some wag described
> as being "covered in Fisher Price's My First Compiler"[3].
From your Parakeet link:
An eager reader may be thinking:
I can just stick that decorator atop any Python function and it
will magically run faster? Great! I'll paste @jit all over my
code and my Python performance problems will be solved!
Easy with those decorators! Parakeet is not a general-purpose
compiler for all of Python. Parakeet only supports a handful of
Python's data types: numbers, tuples, slices, and NumPy arrays.
Thus, by its own admission, it is not the Holy Grail I've been talking
about: a Python optimizer that makes Java redundant. For example, I have
never really had to deal with numeric computations; I have implemented
numerous communication protocols in C, C++, Java and Python. I would
love to stick to Python, but I haven't seen the performance numbers
posted that would support that decision.
Also, I know people who are using Java in large-scale online game
servers. Could they be using Python instead?
> [1] Unladen Swallow was not a failure. It's just that expectations
> were so high ("OMG OMG Google is making a Python compiler this will be
> more powerful than the Death Star and faster than time travel!!!1!")
> that it couldn't help but be a disappointment.
That would be *my* expectation. Until then, I'm quite happy with CPython
performance in the numerous niches where it is enough.
Marko
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web