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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Mark H Harris <harrismh777@gmail.com> |
|---|---|
| Date | 2014-05-11 14:14 -0500 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <lkoi5v$vfj$1@speranza.aioe.org> |
| In reply to | #71337 |
On 5/11/14 1:59 PM, Chris Angelico wrote:
>>> julia> prec=524288
>>> 524288
>>
>>> julia> with_bigfloat_precision(prec) do
>>> println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4)
>>> end
>
> Would it be quicker (and no less accurate) to represent pi as
> atan(BigFloat(1))*4 instead? That's how I originally met a
> pi-calculation (as opposed to "PI = 3.14" extended to however much
> accuracy someone cared to do).
No. Simple experiment will show you. The atan(x<=1) will converge
faster. For 524288 bits atan(1) formula converged in 3 seconds, and
Machin's formula atan(x<1) converged in 2 seconds. Where it becomes very
apparent is 10K and 100K or above. Also, the difference is much more
noticeable in Python than in Julia, but it is there no-the-less.
But here is the cool part: what if your π function could be broken
down into three very fast converging atan(x<1) functions like this one:
> pi = 24*atan(1/8) + 8*atan(1/57) + 4*atan(1/239) (Shanks used this)
... and then, you have julia send each piece to a separate
processor|core (it does this at its center) and they converge together,
then julia pieces them together at the end. Then things get incredibly
faster.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-05-29 14:06 +0000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <53873ef7$0$4935$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #71339 |
In article <lkoi5v$vfj$1@speranza.aioe.org>, Mark H Harris <harrismh777@gmail.com> wrote: >On 5/11/14 1:59 PM, Chris Angelico wrote: >>>> julia> prec=524288 >>>> 524288 >>> >>>> julia> with_bigfloat_precision(prec) do >>>> println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4) >>>> end >> >> Would it be quicker (and no less accurate) to represent pi as >> atan(BigFloat(1))*4 instead? That's how I originally met a >> pi-calculation (as opposed to "PI = 3.14" extended to however much >> accuracy someone cared to do). > > No. Simple experiment will show you. The atan(x<=1) will converge >faster. For 524288 bits atan(1) formula converged in 3 seconds, and >Machin's formula atan(x<1) converged in 2 seconds. Where it becomes very >apparent is 10K and 100K or above. Also, the difference is much more >noticeable in Python than in Julia, but it is there no-the-less. > > But here is the cool part: what if your π function could be broken >down into three very fast converging atan(x<1) functions like this one: > > > pi = 24*atan(1/8) + 8*atan(1/57) + 4*atan(1/239) (Shanks used this) > > >... and then, you have julia send each piece to a separate >processor|core (it does this at its center) and they converge together, >then julia pieces them together at the end. Then things get incredibly >faster. I know now how to interpret your posts. Using "incredible" for a mere factor of at most 3. Balanced views are more convincing. Groetjes Albert > -- 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 | Peter Pearson <ppearson@nowhere.invalid> |
|---|---|
| Date | 2014-05-29 17:53 +0000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <bupagcFscurU1@mid.individual.net> |
| In reply to | #72237 |
On 29 May 2014 14:06:47 GMT, Albert van der Horst wrote: > In article <lkoi5v$vfj$1@speranza.aioe.org>, > Mark H Harris <harrismh777@gmail.com> wrote: >>On 5/11/14 1:59 PM, Chris Angelico wrote: >>>>> julia> prec=524288 >>>>> 524288 >>>> >>>>> julia> with_bigfloat_precision(prec) do >>>>> println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4) >>>>> end >>> >>> Would it be quicker (and no less accurate) to represent pi as >>> atan(BigFloat(1))*4 instead? That's how I originally met a >>> pi-calculation (as opposed to "PI = 3.14" extended to however much >>> accuracy someone cared to do). >> >> No. Simple experiment will show you. The atan(x<=1) will converge >>faster. For 524288 bits atan(1) formula converged in 3 seconds, and >>Machin's formula atan(x<1) converged in 2 seconds. Where it becomes very >>apparent is 10K and 100K or above. Also, the difference is much more >>noticeable in Python than in Julia, but it is there no-the-less. >> >> But here is the cool part: what if your π function could be broken >>down into three very fast converging atan(x<1) functions like this one: >> >> > pi = 24*atan(1/8) + 8*atan(1/57) + 4*atan(1/239) (Shanks used this) >> >> >>... and then, you have julia send each piece to a separate >>processor|core (it does this at its center) and they converge together, >>then julia pieces them together at the end. Then things get incredibly >>faster. > > I know now how to interpret your posts. Using "incredible" for a mere > factor of at most 3. Balanced views are more convincing. Won't there be an additional speedup resulting from the computation of atan(x) converging faster for x=1/8 than for x=1? -- To email me, substitute nowhere->spamcop, invalid->net.
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2014-05-11 23:10 -0400 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9906.1399865515.18130.python-list@python.org> |
| In reply to | #71336 |
On 05/11/2014 02:54 PM, Mark H Harris wrote: > > >julia> sin(BigFloat(π/4)) > > 7.0710678118654750275194295621751674626154323953749278952436611913748 > > 20215180412e-01 with 256 bits of precision > That answer doesn't seem to come anywhere near 256 bits of precision. Using Python 3.2, >>> x=70710678118654750275194295621751674626154323953749278952436611913748 >>> x*x 4999999999999999693838300213161705693483516931249926767981110058185818806614907837502621065882204197129973479350206261627418690991407504 Not that this is surprising, but it does make a terrible ad for how great Julia is. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Mark H Harris <harrismh777@gmail.com> |
|---|---|
| Date | 2014-05-11 23:10 -0500 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <lkphk8$88v$1@speranza.aioe.org> |
| In reply to | #71365 |
On 5/11/14 10:10 PM, Dave Angel wrote: > On 05/11/2014 02:54 PM, Mark H Harris wrote: > >> >> >julia> sin(BigFloat(π/4)) >> > 7.0710678118654750275194295621751674626154323953749278952436611913748 >> > 20215180412e-01 with 256 bits of precision >> > > That answer doesn't seem to come anywhere near 256 bits of precision. > > Using Python 3.2, > > >>> x=70710678118654750275194295621751674626154323953749278952436611913748 > >>> x*x > 4999999999999999693838300213161705693483516931249926767981110058185818806614907837502621065882204197129973479350206261627418690991407504 > > > Not that this is surprising, but it does make a terrible ad for how > great Julia is. > Dave, you get the golden egg! I expected D'Aprano to catch it first! Yes, BigFloat does the same dumb thing Python's Decimal does. π/4 is not a BigFloat, and BigFloat simply makes the 16 digit float into a 256 bit float, the sin of which will only be 16 digits accurate (more or less). It has nothing to do with the language (Python vs. Julia) it has to do with the way the BigFloat is formed. So let's fix it by forming the π constant as a BigFloat constant: >julia> n = BigFloat(1) >1e+00 with 256 bits of precision >julia> π = atan(n/5)*16 - atan(n/239)*4 >3.141592653589793238462643383279502884197169399375105820974944592307816406286198e+00 >with 256 bits of precision >julia> S = sin(π/4) >7.07106781186547524400844362104849039284835937688474036588339868995366239231051e-01 >with 256 bits of precision >julia> S * S >4.999999999999999999999999999999999999999999999999999999999999999999999999999957e-01 >with 256 bits of precision Not too bad... marcus
[toc] | [prev] | [next] | [standalone]
| From | Mark H Harris <harrismh777@gmail.com> |
|---|---|
| Date | 2014-05-11 23:26 -0500 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <lkpiic$a27$1@speranza.aioe.org> |
| In reply to | #71366 |
On 5/11/14 11:10 PM, Mark H Harris wrote:
> On 5/11/14 10:10 PM, Dave Angel wrote:
>> On 05/11/2014 02:54 PM, Mark H Harris wrote:
>>
>>>
>>> >julia> sin(BigFloat(π/4))
>>> > 7.0710678118654750275194295621751674626154323953749278952436611913748
>>> > 20215180412e-01 with 256 bits of precision
>>>
>>
>> That answer doesn't seem to come anywhere near 256 bits of precision.
>>
>> Using Python 3.2,
>>
>> >>>
>> x=70710678118654750275194295621751674626154323953749278952436611913748
>> >>> x*x
>> 4999999999999999693838300213161705693483516931249926767981110058185818806614907837502621065882204197129973479350206261627418690991407504
>>
>>
>>
>> Not that this is surprising, but it does make a terrible ad for how
>> great Julia is.
>>
>
> Dave, you get the golden egg! I expected D'Aprano to catch it first!
>
> Yes, BigFloat does the same dumb thing Python's Decimal does. π/4 is
> not a BigFloat, and BigFloat simply makes the 16 digit float into a 256
> bit float, the sin of which will only be 16 digits accurate (more or less).
>
> It has nothing to do with the language (Python vs. Julia) it has to do
> with the way the BigFloat is formed. So let's fix it by forming the π
> constant as a BigFloat constant:
>
> >julia> n = BigFloat(1)
> >1e+00 with 256 bits of precision
>
> >julia> π = atan(n/5)*16 - atan(n/239)*4
> >3.141592653589793238462643383279502884197169399375105820974944592307816406286198e+00 >with 256 bits of precision
>
> >julia> S = sin(π/4)
> >7.07106781186547524400844362104849039284835937688474036588339868995366239231051e-01 >with 256 bits of precision
>
> >julia> S * S
> >4.999999999999999999999999999999999999999999999999999999999999999999999999999957e-01 >with 256 bits of precision
Having said that, the accuracy was not my point; in the first place. My
point is that the sin() function is built-in, takes standard floats (32
bit, 64 bit, 128 bit) and BigFloats of arbitrary precision (and does
something meaningful with it). Let's take a look at Python Deciaml:
>>> =================== RESTART ===============
>>> from decimal import * (first I have to import)
>>> from math import * (than I have to import again)
>>> π
Traceback (most recent call last):
File "<pyshell#13>", line 1, in <module>
π
NameError: name 'π' is not defined (whoops, don't know π )
>>> π=4*atan(1) (let's create it)
>>> sin(Decimal(π/4))
0.7071067811865475 (whoops sin doesn't do Decimals)
>>> from pdeclib import sin (let's get a sin that does do Decimals)
>>> sin(Decimal(π/4))
Decimal('0.707106781186547502751942956217516746261543')
>>> S=sin(Decimal(π/4)) (Whoops has the same problem as BigFloat)
>>> S**2
Decimal('0.499999999999999969383830021316170569348351')
>>>
Now let's fix it:
>>>
>>> from pdeclib import d
>>> n=d(1)
>>> from pdeclib import *
>>> n=d(1)
>>> π=atan(n/5)*16 - atan(n/239)*4
>>> S=sin(π/4)
>>> S**2
> Decimal('0.500000000000000000000000000000000000000000')
>>>
Also not bad, but slower. ;-)
marcus
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-12 14:53 +1000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9907.1399870405.18130.python-list@python.org> |
| In reply to | #71368 |
On Mon, May 12, 2014 at 2:26 PM, Mark H Harris <harrismh777@gmail.com> wrote: > Having said that, the accuracy was not my point; in the first place. My > point is that the sin() function is built-in... So what? Built-in just means that there's no namespacing of mathematical functions. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-05-12 10:44 +0200 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <87iopbtmh1.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #71336 |
Mark H Harris <harrismh777@gmail.com> writes: > On 5/11/14 12:05 PM, Alain Ketterlin wrote: >>> Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on >>> steroids. Its amazing as a dynamic language, and its fast, like >>> lightning fast as well as multiprocessing (parallel processing) at its >>> core. Its astounding, really. >> >> Hmmm... >> >>> Its number concept is unified, >> >> What exactly is unified? There is no implicit promotion between >> primitive types and BigInt/Float. > > > The built-in math functions (extensive, by the way) just work, and > they work consistently the way you might expect across types. Consider > sqrt(): [...] > You'll notice that I did not need to import anything to use sqrt(), > and sqrt() takes all types and does something meaningful with them. Sorry, i wasn't clear enough: "doing something meaningful with them" is precisely where the problem is. Every single operation requires multiple-dispatch (i.e., dynamically testing types, converting to a common type, and selecting the version of sqrt to use). That's probably more than the time it takes to actually perform the computation, a bit like what happens with x+y on integers with Python, where only a fraction of time is spent on adding integers. When you are doing scientific computation, this overhead is unacceptable, because you'll have zillions of computations to perform. 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. But then, you're not too far from Fortran, or C/C++. > The following code will produce over 100,000 digits of π (pi) in less > than 2 seconds on a low-end processor, like my mac mini dual core > 2Ghz: You seem to be discovering the power of the libraries that are behind all this (MPFR in that case)... [...] > But, like lisp, Julia's internal structures are lists, so, it can > create and modify its own code on-the-fly. [...] Sorry, I was comparing to Fortran, and it's use in scientific computing. Self modifying code is totally irrelevant there. -- Alain.
[toc] | [prev] | [next] | [standalone]
| From | Mark H Harris <harrismh777@gmail.com> |
|---|---|
| Date | 2014-05-13 00:33 -0500 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <lksarq$n5r$1@speranza.aioe.org> |
| In reply to | #71379 |
On 5/12/14 3:44 AM, Alain Ketterlin wrote:
> multiple-dispatch (i.e., dynamically testing types, converting to a
> common type, and selecting the version of sqrt to use). That's probably
> more than the time it takes to actually perform the computation, a bit
> like what happens with x+y on integers with Python, where only a
> fraction of time is spent on adding integers.
>
> 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.
> 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.
>
> But then, you're not too far from Fortran, or C/C++.
>
Right. Again, this is really about the design goals and the JIT.
>> The following code will produce over 100,000 digits of π (pi) in less
>> than 2 seconds on a low-end processor, like my mac mini dual core
>> 2Ghz: {snip}
>
> You seem to be discovering the power of the libraries that are behind
> all this (MPFR in that case)...
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.
>
>> But, like lisp, Julia's internal structures are lists, so, it can
>> create and modify its own code on-the-fly. [...]
>
> 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? FORTRAN
works well (its fast too), and there are zillions of lines of code
cranking away on huge linear arrays. Enter Julia... over the next ten
years; seriously. Because of the value adds!
Why?, glad you asked. Enter self modifying code for one. The
influence of Lisp|Scheme is potentially huge here. For scientific
computing the reason for making the switch is that the array functions
being calculated now in FORTRAN can be calculated (as fast) but more
elegantly with Julia; because the language has the ease of use of
Python, the stats of R, the array capabilities of MatLab (on steroids)
and the almost speed of C/C++ (all together in one package). There is
enough of a value add in this language to make FORTRAN users (also NumPy
SciPy) take notice.
Yes, its on a development curve right now (very much beta); but very
much out there with some serious capability --- right now. It will take
some time to mature, but I really think this language has the potential
to be around for a long long time. There needs to be some serious bench
marking on the parallel processing model, and there needs to be some
uptake on the user base to find out what 'they' really need from it, but
I think this dev group is on the ball. (maybe a little too smart for
their own good, we'll see)
I noticed from the MIT videos
http://julialang.org/blog/2013/03/julia-tutorial-MIT/ from a year ago
that the project has grown with leaps and bounds... but, there is very
much an intellectual edge here vs. a usability edge... um, the computer
scientists are still very much in control. It might be time for a
larger user group to get involved with the development direction, and
code base.
I agree with D'Aprano that languages come and go. But I think Julia
is different... like Python... for the scientific community; seriously.
And, if they really are working together with certain Python group(s) to
merge technologies, this could be big for years to come!
I'm excited about it.
Don't get me wrong anybody, I'm still a Pythonista! :)
marcus
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2014-05-13 05:48 +0000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <5371b23a$0$11109$c3e8da3@news.astraweb.com> |
| In reply to | #71427 |
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote: > there has to be a value add for scientists to move away from R or > Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its > fast too), and there are zillions of lines of code cranking away on huge > linear arrays. Enter Julia... over the next ten years; seriously. > Because of the value adds! > > Why?, glad you asked. Enter self modifying code for one. Self-modifying code is a nightmare inside the head of a Lovecraftian horror. There's a reason why almost the only people still using self- modifying code are virus writers, and the viruses they create are notorious for being buggy. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark H Harris <harrismh777@gmail.com> |
|---|---|
| Date | 2014-05-13 00:55 -0500 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <5371B3BA.1050600@gmail.com> |
| In reply to | #71429 |
On 5/13/14 12:48 AM, Steven D'Aprano wrote:
> On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
>
>> there has to be a value add for scientists to move away from R or
>> Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its
>> fast too), and there are zillions of lines of code cranking away on huge
>> linear arrays. Enter Julia... over the next ten years; seriously.
>> Because of the value adds!
>>
>> Why?, glad you asked. Enter self modifying code for one.
>
> Self-modifying code is a nightmare inside the head of a Lovecraftian
> horror. There's a reason why almost the only people still using self-
> modifying code are virus writers, and the viruses they create are
> notorious for being buggy.
>
>
no, no, no... Steven don't think self-modifying (sorry I even used
it) think meta-programming. Python accomplishes this kind of thing using
Class and function decorations (sort-uv).
Take a look at the video presentation of the concept before you turn
it into a Friday the Thirteenth virus writing horror flick... its going
to be as powerful as lisp was supposed to be with the user friendliness
of python-like code-ability but 'without' the forced indentation rule
(Julia uses 'ends' and white-space means nothing).
marcus
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-13 15:56 +1000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9937.1399960620.18130.python-list@python.org> |
| In reply to | #71429 |
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano <steve@pearwood.info> wrote: > Self-modifying code is a nightmare inside the head of a Lovecraftian > horror. There's a reason why almost the only people still using self- > modifying code are virus writers, and the viruses they create are > notorious for being buggy. Hmm... what counts as self-modifying, though? When you decorate a function to modify its behaviour (eg add caching around it), all the modification happens at compile time, but it's still executing something other than what you see as the bald code. What about a microkernel that can load altered code from the disk, compile it into memory, and replace portions of itself? I've done that a number of times (not in Python as it has little support for it, but in Pike it's easy); is that self-modifying code? Or a JIT compiler. As you run something, it gets changed in form to be more streamlined. None of these is as horrible as the loop that fiddles with its own code on the fly, but any of them, if buggy, will have the same effect. And all are useful. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2014-05-13 09:34 +0000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <5371e737$0$11109$c3e8da3@news.astraweb.com> |
| In reply to | #71433 |
On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
> On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> Self-modifying code is a nightmare inside the head of a Lovecraftian
>> horror. There's a reason why almost the only people still using self-
>> modifying code are virus writers, and the viruses they create are
>> notorious for being buggy.
>
> Hmm... what counts as self-modifying, though?
Code that modifies itself, as opposed to code that modifies other code.
> When you decorate a
> function to modify its behaviour (eg add caching around it), all the
> modification happens at compile time,
Not in Python it doesn't. Functions are created at runtime -- def is a
statement, and it runs at runtime. But that's actually irrelevant.
> but it's still executing something
> other than what you see as the bald code.
I don't think so. Whether I write:
@cache
def function(args):
...
or even the old pre-decorator style:
def function(args):
...
function = cache(function)
there's no *self-modification* going on. The trickiest thing about this
is that the code for function is now split over two places, cache and
function itself. But that's not much trickier than:
def cache(x):
...
def function(x):
cache(x)
...
or similar. You can write obfuscated code with decorators, but you can
shoot yourself in the foot with just about any tool. Fundamentally,
decorators are more or less just a way of doing function composition.
> What about a microkernel that
> can load altered code from the disk, compile it into memory, and replace
> portions of itself?
Now we're talking self-modification. But of course there are degrees of
self-modification. This isn't too bad, because it's relatively simple to
follow what happens next:
def foo(x):
global foo # Change me.
foo = new_foo
return bar(x)
This is to self-modifying code what break and continue are to GOTO --
tamed, trained, on a leash, and pretty safe.
> I've done that a number of times (not in Python as
> it has little support for it, but in Pike it's easy); is that
> self-modifying code?
Yes.
> Or a JIT compiler. As you run something, it gets
> changed in form to be more streamlined.
I wouldn't call that self-modifying code, because the compiler isn't
modifying itself. It's modifying the code being run.
But note that JIT compilers are optimizing compilers (there's little
point, otherwise), and highly optimized code is notorious for being hard
to debug and containing subtle, hard to find, harder to fix, bugs. Why
are they hard to debug? Because the code that you read is not necessarily
the same as the code being run.
> None of these is as horrible as
> the loop that fiddles with its own code on the fly, but any of them, if
> buggy, will have the same effect. And all are useful.
Many things are potentially useful, nevertheless we mostly avoid them
because the cost is greater than the benefit.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-13 20:00 +1000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9956.1399975245.18130.python-list@python.org> |
| In reply to | #71456 |
On Tue, May 13, 2014 at 7:34 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
>
>> On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> Self-modifying code is a nightmare inside the head of a Lovecraftian
>>> horror. There's a reason why almost the only people still using self-
>>> modifying code are virus writers, and the viruses they create are
>>> notorious for being buggy.
>>
>> Hmm... what counts as self-modifying, though?
>
> Code that modifies itself, as opposed to code that modifies other code.
Duh :)
>> When you decorate a
>> function to modify its behaviour (eg add caching around it), all the
>> modification happens at compile time,
>
> Not in Python it doesn't. Functions are created at runtime -- def is a
> statement, and it runs at runtime. But that's actually irrelevant.
Yes, but that's still the "initialization phase" of the code. When I
think of self-modifying code, I think of something that could do this:
def some_func(x):
if x<0:
change_bottom_of_function
x = -x
result = calculate_stuff(x)
return result # becomes "return -result" if change done
Effectively, instead of using a stack or heap entry to record state,
it uses its own code. (And the above example is buggy, too. That's
part of why this is a bad idea - it's not obvious when there are
bugs.)
With a decorated function, the change happens at the time the def is
executed. With the above example, the change happens when the function
is called. That's what I meant by "compile time", although I did pick
a poor term for it. Is there a better word for that? There's three
phases, if you like - compilation, execution of def, and execution of
function.
>> but it's still executing something
>> other than what you see as the bald code.
>
> I don't think so. ... there's no *self-modification* going on.
> You can write obfuscated code with decorators, but you can
> shoot yourself in the foot with just about any tool. Fundamentally,
> decorators are more or less just a way of doing function composition.
Right. I would agree here. It's confusing if it completely changes
itself, but it's not really self-modifying.
>> What about a microkernel that
>> can load altered code from the disk, compile it into memory, and replace
>> portions of itself?
>
> Now we're talking self-modification.
Technically not - that's why I said microkernel. The kernel never
changes *itself*, it just loads other code into memory (and can switch
out submodules). It's not so clear-cut. The program, as a whole, is
changing its own behaviour, but by separating "this bit can change"
from "this bit manages the changes", you tame the self-modification -
just as you say further down.
> But of course there are degrees of
> self-modification. This isn't too bad, because it's relatively simple to
> follow what happens next:
>
> def foo(x):
> global foo # Change me.
> foo = new_foo
> return bar(x)
>
> This is to self-modifying code what break and continue are to GOTO --
> tamed, trained, on a leash, and pretty safe.
Yeah. It's safe because it's atomic and clean.
>> Or a JIT compiler. As you run something, it gets
>> changed in form to be more streamlined.
>
> I wouldn't call that self-modifying code, because the compiler isn't
> modifying itself. It's modifying the code being run.
Again, technically. But if the compiler is deemed to be part of the
program (it often won't be - V8 with your JavaScript code and PyPy
with your Python code are separate - but it would be possible to
consider them to be the same effective unit), then it's exactly the
same as the microkernel example above: tamed self-modification, with
one piece modifying the other(s).
> But note that JIT compilers are optimizing compilers (there's little
> point, otherwise), and highly optimized code is notorious for being hard
> to debug and containing subtle, hard to find, harder to fix, bugs. Why
> are they hard to debug? Because the code that you read is not necessarily
> the same as the code being run.
Right, and that's exactly where the risk is. Every translation between
you and what's run is a potential source of horribly insidious bugs.
That's why it's absolutely essential to put bounds on the insatiable
ambition for automutability. In the microkernel case, and also with a
similar (but horribly less efficient) structure that I did a couple of
times with DLLs, there's a clear protocol with "this file provides
these public symbols", and that protocol doesn't much change with
reloads. With a JIT compiler, the code should have the exact same
effect before and after the change, and just be faster. And so on. By
clearly delineating what can change and what can't, you divide any
debugging job down to smaller pieces.
Actually, even the file system can do some of this to you. I was
checking lsof on one of my Linux systems a little while ago, and found
that I had half a dozen old versions of a program, all with the same
file name, all deleted. (When you unlink a running binary on Linux,
the program keeps running the old version, and then you can put a new
version in its place, with the same file name. Any new invocation will
pick up the new binary; existing ones keep what they have.) So a
program can unlink itself, write out a new version of itself, and
happily keep going - letting new invocations take the changed version,
safely. Again, not exactly self-modifying code... or is it? Again,
tamed by boundaries.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-05-13 03:44 -0700 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <1bd9fc22-8d4b-4a9d-872f-d76591cfb205@googlegroups.com> |
| In reply to | #71464 |
On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote: > Actually, even the file system can do some of this to you. I was > checking lsof on one of my Linux systems a little while ago, and found > that I had half a dozen old versions of a program, all with the same > file name, all deleted. (When you unlink a running binary on Linux, > the program keeps running the old version, and then you can put a new > version in its place, with the same file name. Any new invocation will > pick up the new binary; existing ones keep what they have.) So a > program can unlink itself, write out a new version of itself, and > happily keep going - letting new invocations take the changed version, > safely. Again, not exactly self-modifying code... or is it? Again, > tamed by boundaries. Your lsof example looks like a rather typical case of ugly self-modifying code Self-modifying code has many flavours; consider: $ sudo apt-get upgrade apt-get relatively harmless but self-modifying nonetheless When its more invisible its more dangerous # apt-get upgrade linux-image My understanding of Mark Harris' original reference to 'self-modifying' is a more standard, ubiquitous, ugly but indispensable example -- the use of the interactive interpreter. I write a function: def foo()... ... recursive use of foo() I then rename the foo to FOO but forget to rename the internal call For normal file/module loading one would get a straightforward error message At the interactive interpreter one gets massive confusion. Does it mean we stop playing around in the interactive environment? Hopefully not! But there are pitfalls and its good to be straight about them. As far as I can see, recursivity is the foundation of our field; self-modifying code, self-reference (y-combinator) are just some of its many faces: http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-13 20:50 +1000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9957.1399978206.18130.python-list@python.org> |
| In reply to | #71465 |
On Tue, May 13, 2014 at 8:44 PM, Rustom Mody <rustompmody@gmail.com> wrote: > On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote: >> Actually, even the file system can do some of this to you. I was >> checking lsof on one of my Linux systems a little while ago, and found >> that I had half a dozen old versions of a program, all with the same >> file name, all deleted. (When you unlink a running binary on Linux, >> the program keeps running the old version, and then you can put a new >> version in its place, with the same file name. Any new invocation will >> pick up the new binary; existing ones keep what they have.) So a >> program can unlink itself, write out a new version of itself, and >> happily keep going - letting new invocations take the changed version, >> safely. Again, not exactly self-modifying code... or is it? Again, >> tamed by boundaries. > > Your lsof example looks like a rather typical case of ugly self-modifying code > Self-modifying code has many flavours; consider: > > $ sudo apt-get upgrade apt-get > > relatively harmless but self-modifying nonetheless > Heh. Those are going to be exactly the same. (In actual fact, it was a "sudo make install" that created the situation I described.) The only difference is that you probably don't have any other instances of apt-get running, meaning the change takes place for the next run - but while that's running, you would see the old /usr/bin/apt-get as a deleted and open file. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@wdtv.com> |
|---|---|
| Date | 2014-05-13 02:31 -0400 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9940.1399962682.18130.python-list@python.org> |
| In reply to | #71429 |
On Tuesday 13 May 2014 01:48:43 Steven D'Aprano did opine And Gene did reply: > On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote: > > there has to be a value add for scientists to move away from R or > > Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well > > (its fast too), and there are zillions of lines of code cranking > > away on huge linear arrays. Enter Julia... over the next ten years; > > seriously. Because of the value adds! > > > > Why?, glad you asked. Enter self modifying code for one. > > Self-modifying code is a nightmare inside the head of a Lovecraftian > horror. There's a reason why almost the only people still using self- > modifying code are virus writers, and the viruses they create are > notorious for being buggy. People who write buggy self-modifying code aren't paying attention. And you don't want those people anywhere near your code in 107% of the cases. 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. The only time it crashed was when there was a power failure, and the backup generator, which had to be started by hand, didn't get started soon enough to keep the battery backup, an old fried & dried 6 volt gel-cell from running down. An RCA 1802 device without an assembler even, just a hex monitor for code entry, and memory in those days (1980) was $400 for 4k of static ram when I built it. By using self modifying code, I was able to do about 10k worth of code, using about 2.5k of that 4k of ram. Its all in how you reset each location that is modified on your way back to the top of the program to await the next command. 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. 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 | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2014-05-13 07:22 +0000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <5371c834$0$11109$c3e8da3@news.astraweb.com> |
| In reply to | #71439 |
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. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-05-13 07:16 -0400 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <roy-2E7517.07163613052014@news.panix.com> |
| In reply to | #71446 |
In article <5371c834$0$11109$c3e8da3@news.astraweb.com>, Steven D'Aprano <steve@pearwood.info> wrote: > And after 15 years, I daresay that includes you. 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 :-)
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-13 21:21 +1000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9958.1399980089.18130.python-list@python.org> |
| In reply to | #71469 |
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... ChrisA
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web