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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-05-12 02:28 +0000 |
| Subject | Re: Fortran |
| Message-ID | <537031c6$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #71358 |
On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote: > On 12/05/2014 00:51, Steven D'Aprano wrote: >> >> Cars are standardized -- there are basically two types, manuals and >> automatics. >> >> > Sadly they can still go wrong due to modern engineering practices. In > my neck of the woods some years ago people were killed when standing at > a bus stop, because the car driver was desperately pressing down on the > automatic's brake Perhaps (s)he should have steered the car away from the people. Or I suppose the steering wheel failed as well? > but EMI overrode the engine controls EMI? The record company? Wow, I knew they were evil, but I didn't realise they were *that* evil. > and the car > simply went faster. At least that is what the defence claimed at the > trial. With no expert on the prosecution to refute the claim "not > guilty" was the verdict. Sounds like the prosecution were just going through the motions. They should have either had an expert able to refute the claim, or not prosecuted in the first place. Personally, I'm rather skeptical about claims of "I kept pushing the brake but the car just accelerated". There is a long and inglorious history of people stepping on the wrong pedal when in a panic, or drunk, or distracted. I've even done it myself. (I expect *every* driver has, at some point.) And a not-quite-as-long but even more inglorious history of lawyers inventing nonsense links between the brake pedal and the accelerator in order to extort money from car manufacturers. E.g. see "Galileo's Revenge" by Peter W Huber and the case of the mythical, but amazingly profitable for the lawyers involved, Audi Sudden Acceleration Syndrome. For me personally, perhaps the most despicable part of the whole sordid story was the case of Wende Gatts, who ran over Darlene Norris, causing $300,000 in damages. Not only did she got off scot-free, thanks to the junk science invented by her "expert witness", but actual victim Norris was ordered to pay Gatts' legal fees of $64K. Of course, that was in the late 1980s, when even luxury cars still had mechanical linkage between the user and the brakes. These days, when nearly everything in the car is computer controlled, I wouldn't be *quite* so skeptical. Nevertheless, chances are almost certain that by far the majority of unexpected acceleration cases are PEBCAP errors. http://www.caranddriver.com/features/its-all-your-fault-the-dot-renders-its-verdict-on-toyotas-unintended-acceleration-scare-feature http://www.caranddriver.com/news/toyota-recall-scandal-media-circus-and-stupid-drivers-editorial -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-05-12 10:05 +0100 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9912.1399885520.18130.python-list@python.org> |
| In reply to | #71362 |
On 12/05/2014 03:28, Steven D'Aprano wrote: > On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote: > >> On 12/05/2014 00:51, Steven D'Aprano wrote: >>> >>> Cars are standardized -- there are basically two types, manuals and >>> automatics. >>> >>> >> Sadly they can still go wrong due to modern engineering practices. In >> my neck of the woods some years ago people were killed when standing at >> a bus stop, because the car driver was desperately pressing down on the >> automatic's brake > > Perhaps (s)he should have steered the car away from the people. Or I > suppose the steering wheel failed as well? The entire vehicle was perfectly sound after the event, including the brake and accelerator controls. It was only during the accident that the interference played havoc. Pure coincidence of course. > > >> but EMI overrode the engine controls > > EMI? The record company? Wow, I knew they were evil, but I didn't realise > they were *that* evil. Ho, ho, ho :) > > >> and the car >> simply went faster. At least that is what the defence claimed at the >> trial. With no expert on the prosecution to refute the claim "not >> guilty" was the verdict. > > Sounds like the prosecution were just going through the motions. They > should have either had an expert able to refute the claim, or not > prosecuted in the first place. Can't do that if you don't know in advance what the defence is :( > > Personally, I'm rather skeptical about claims of "I kept pushing the > brake but the car just accelerated". There is a long and inglorious > history of people stepping on the wrong pedal when in a panic, or drunk, > or distracted. I've even done it myself. (I expect *every* driver > has, at some point.) And a not-quite-as-long but even more inglorious > history of lawyers inventing nonsense links between the brake pedal and > the accelerator in order to extort money from car manufacturers. E.g. see > "Galileo's Revenge" by Peter W Huber and the case of the mythical, but > amazingly profitable for the lawyers involved, Audi Sudden Acceleration > Syndrome. > > For me personally, perhaps the most despicable part of the whole sordid > story was the case of Wende Gatts, who ran over Darlene Norris, causing > $300,000 in damages. Not only did she got off scot-free, thanks to the > junk science invented by her "expert witness", but actual victim Norris > was ordered to pay Gatts' legal fees of $64K. > > Of course, that was in the late 1980s, when even luxury cars still had > mechanical linkage between the user and the brakes. These days, when > nearly everything in the car is computer controlled, I wouldn't be > *quite* so skeptical. Nevertheless, chances are almost certain that by > far the majority of unexpected acceleration cases are PEBCAP errors. > > http://www.caranddriver.com/features/its-all-your-fault-the-dot-renders-its-verdict-on-toyotas-unintended-acceleration-scare-feature > > http://www.caranddriver.com/news/toyota-recall-scandal-media-circus-and-stupid-drivers-editorial > I hadn't heard about ASAS, another to add to my list of syndromes :) -- 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 | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2014-05-12 20:52 -0400 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9931.1399942390.18130.python-list@python.org> |
| In reply to | #71362 |
On 12 May 2014 02:28:22 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:
>EMI? The record company? Wow, I knew they were evil, but I didn't realise
>they were *that* evil.
>
Electro-Magnetic Interference...
As I recall the hearsay, a lot of expensive cars in the late 80s tended
to need expensive replacement parts... As they hit some point in a mountain
pass in California they'd come into the beam of a military radar unit --
and the ignition control computer would "fry".
(Actually, back then, lots of amateur radio ops had to worry too, as their
50-100W mobile transmitters would interfere with the unshielded computers;
as a precaution I bought the remote mount kit to put a dual-band
transceiver into the far rear corner of my car)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2014-05-11 11:05 -0700 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9890.1399832773.18130.python-list@python.org> |
| In reply to | #71327 |
On 05/11/2014 10:51 AM, Roy Smith wrote: > In article <871tw0s2kl.fsf@elektro.pacujo.net>, > Marko Rauhamaa <marko@pacujo.net> wrote: > >> Tomasz Rola <rtomek@ceti.pl>: >> >>> Given that Fortran is here for almost 60 years and lot of effort has >>> been spent to keep it backwards compatible (AFAIK), I wouldn't hold my >>> breath. >> >> I have seen a glimpse of the so-called scientific computing and Fortran >> programming. I can't help but think that Fortran is successful with >> people who don't know how to program and don't care. >> >> That's fine. If I were to build a cyclotron, I bet the Fortran coders >> would smile at my clumsy efforts. > > It is fine. Computers are tools. The sign of a good tool is that you > can pick it up and use it without having to read the instruction manual. > I can jump into pretty much any car, start the engine, and drive it, > without any learning curve. There's a lot of complicated organic > chemistry and thermodynamics going on inside the engine's combustion > chambers, but I don't need to know any of that to make use of the tool. That is an excellent example. For the most part cars are very similar, yet in some circumstances (such as a vehicle in front of you suddenly stopping) the exact details (such as the precise location and size and shape of the brake pedal) become excruciatingly important (having your foot stomp the floor just to the right of the current break pedal, because that's where the brake was in your last vehicle, is not going to help here). How the lights and/or windshield wipers turn on/off is also an important detail. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-12 04:33 +1000 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9891.1399833209.18130.python-list@python.org> |
| In reply to | #71327 |
On Mon, May 12, 2014 at 4:05 AM, Ethan Furman <ethan@stoneleaf.us> wrote: > For the most part cars are very similar, yet in some circumstances (such as > a vehicle in front of you suddenly stopping) the exact details (such as the > precise location and size and shape of the brake pedal) become > excruciatingly important (having your foot stomp the floor just to the right > of the current break pedal, because that's where the brake was in your last > vehicle, is not going to help here). Some things are more standardized than others. A piano keyboard is incredibly standard, to make it possible to play without having to look at your fingers (even when jumping your hands around, which doesn't happen as much on a computer keyboard); mobile phones are anything but, so you really need to get to know your particular phone (there may or may not even be brand similarities). But that's really tangential to the question of using something without gaining any skill in it; it's more a matter of how well skill gained on one device in a class translates to other devices in that class. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-05-11 14:43 -0400 |
| Subject | Re: Fortran |
| Message-ID | <roy-7E661C.14431911052014@news.panix.com> |
| In reply to | #71333 |
In article <mailman.9891.1399833209.18130.python-list@python.org>, Chris Angelico <rosuav@gmail.com> wrote: > Some things are more standardized than others. A piano keyboard is > incredibly standard, to make it possible to play without having to > look at your fingers (even when jumping your hands around, which > doesn't happen as much on a computer keyboard) Speaking of which, here's a trivia question. Without looking at your keyboard, describe how the "F" and "J" keys (assuming a US-English key layout) differ from, say, the "G" and "K" keys.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-05-11 23:15 +0000 |
| Subject | Re: Fortran |
| Message-ID | <53700493$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #71335 |
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: > In article <mailman.9891.1399833209.18130.python-list@python.org>, > Chris Angelico <rosuav@gmail.com> wrote: > >> Some things are more standardized than others. A piano keyboard is >> incredibly standard, to make it possible to play without having to look >> at your fingers (even when jumping your hands around, which doesn't >> happen as much on a computer keyboard) > > Speaking of which, here's a trivia question. Without looking at your > keyboard, describe how the "F" and "J" keys (assuming a US-English key > layout) differ from, say, the "G" and "K" keys. The F and J keys have "F" and "J" printed on them instead of "G" and "K". They're also in slightly different positions, offset one position to the left. Otherwise they are identical, to the limits of my vision and touch. (I haven't tried measuring them with a micrometer, or doing chemical analysis of the material they are made of.) -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2014-05-12 00:51 +0100 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9900.1399852263.18130.python-list@python.org> |
| In reply to | #71348 |
On 2014-05-12 00:15, Steven D'Aprano wrote: > On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: > >> In article <mailman.9891.1399833209.18130.python-list@python.org>, >> Chris Angelico <rosuav@gmail.com> wrote: >> >>> Some things are more standardized than others. A piano keyboard is >>> incredibly standard, to make it possible to play without having to look >>> at your fingers (even when jumping your hands around, which doesn't >>> happen as much on a computer keyboard) >> >> Speaking of which, here's a trivia question. Without looking at your >> keyboard, describe how the "F" and "J" keys (assuming a US-English key >> layout) differ from, say, the "G" and "K" keys. > > The F and J keys have "F" and "J" printed on them instead of "G" and "K". > They're also in slightly different positions, offset one position to the > left. Otherwise they are identical, to the limits of my vision and touch. > (I haven't tried measuring them with a micrometer, or doing chemical > analysis of the material they are made of.) > Maybe keyboards are different where you are! :-) Mine have an little ridge on the keytop of those keys.
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-05-11 20:14 -0400 |
| Subject | Re: Fortran |
| Message-ID | <roy-821A21.20141411052014@news.panix.com> |
| In reply to | #71354 |
In article <mailman.9900.1399852263.18130.python-list@python.org>, MRAB <python@mrabarnett.plus.com> wrote: > On 2014-05-12 00:15, Steven D'Aprano wrote: > > On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: > > > >> In article <mailman.9891.1399833209.18130.python-list@python.org>, > >> Chris Angelico <rosuav@gmail.com> wrote: > >> > >>> Some things are more standardized than others. A piano keyboard is > >>> incredibly standard, to make it possible to play without having to look > >>> at your fingers (even when jumping your hands around, which doesn't > >>> happen as much on a computer keyboard) > >> > >> Speaking of which, here's a trivia question. Without looking at your > >> keyboard, describe how the "F" and "J" keys (assuming a US-English key > >> layout) differ from, say, the "G" and "K" keys. > > > > The F and J keys have "F" and "J" printed on them instead of "G" and "K". > > They're also in slightly different positions, offset one position to the > > left. Otherwise they are identical, to the limits of my vision and touch. > > (I haven't tried measuring them with a micrometer, or doing chemical > > analysis of the material they are made of.) > > > Maybe keyboards are different where you are! :-) > > Mine have an little ridge on the keytop of those keys. Yup. Long before the days of computers, the F/J keys have had some sort of tactile feedback (a raised dot or whatever) so you can tell when you hands are in the home position by feel. Pyjrteodr upi vsm rmf i[ yu[omh ;olr yjod/
[toc] | [prev] | [next] | [standalone]
| From | alister <alister.nospam.ware@ntlworld.com> |
|---|---|
| Date | 2014-05-12 14:14 +0000 |
| Subject | Re: Fortran |
| Message-ID | <PG4cv.68366$Ch2.37864@fx13.am4> |
| In reply to | #71357 |
On Sun, 11 May 2014 20:14:14 -0400, Roy Smith wrote: > In article <mailman.9900.1399852263.18130.python-list@python.org>, > MRAB <python@mrabarnett.plus.com> wrote: > >> On 2014-05-12 00:15, Steven D'Aprano wrote: >> > On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: >> > >> >> In article <mailman.9891.1399833209.18130.python-list@python.org>, >> >> Chris Angelico <rosuav@gmail.com> wrote: >> >> >> >>> Some things are more standardized than others. A piano keyboard is >> >>> incredibly standard, to make it possible to play without having to >> >>> look at your fingers (even when jumping your hands around, which >> >>> doesn't happen as much on a computer keyboard) >> >> >> >> Speaking of which, here's a trivia question. Without looking at >> >> your keyboard, describe how the "F" and "J" keys (assuming a >> >> US-English key layout) differ from, say, the "G" and "K" keys. >> > >> > The F and J keys have "F" and "J" printed on them instead of "G" and >> > "K". >> > They're also in slightly different positions, offset one position to >> > the left. Otherwise they are identical, to the limits of my vision >> > and touch. >> > (I haven't tried measuring them with a micrometer, or doing chemical >> > analysis of the material they are made of.) >> > >> Maybe keyboards are different where you are! :-) >> >> Mine have an little ridge on the keytop of those keys. > > Yup. Long before the days of computers, the F/J keys have had some sort > of tactile feedback (a raised dot or whatever) so you can tell when you > hands are in the home position by feel. Pyjrteodr upi vsm rmf i[ yu[omh > ;olr yjod/ I once used an Osborn one where each key-cap was individually sculptured to fit the finger depending on its position on the keyboard. -- Bridge ahead. Pay troll.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-05-12 01:11 +0000 |
| Subject | Re: Fortran |
| Message-ID | <53701fcd$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #71354 |
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote: > On 2014-05-12 00:15, Steven D'Aprano wrote: >> On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: >>> Speaking of which, here's a trivia question. Without looking at your >>> keyboard, describe how the "F" and "J" keys (assuming a US-English key >>> layout) differ from, say, the "G" and "K" keys. >> >> The F and J keys have "F" and "J" printed on them instead of "G" and >> "K". They're also in slightly different positions, offset one position >> to the left. Otherwise they are identical, to the limits of my vision >> and touch. (I haven't tried measuring them with a micrometer, or doing >> chemical analysis of the material they are made of.) >> > Maybe keyboards are different where you are! :-) Certainly not. However they may be different where *you* are :-P I'm using an IBM keyboard, model SK-8820. > Mine have an little ridge on the keytop of those keys. I've seen keyboards with those, but not many. -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <d@davea.name> |
|---|---|
| Date | 2014-05-11 23:27 -0400 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9905.1399865248.18130.python-list@python.org> |
| In reply to | #71359 |
On 05/11/2014 09:11 PM, Steven D'Aprano wrote: > On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote: > > > Certainly not. However they may be different where *you* are :-P > > I'm using an IBM keyboard, model SK-8820. > > >> Mine have an little ridge on the keytop of those keys. > > I've seen keyboards with those, but not many. > > My experience has been the exact opposite. Except for very cheap keyboards, I believe the standard marks have been on F and J on every keyboard I've encountered (USA) in the past 30 years. They certainly are on my two Thinkpads, two Toshibas, a Dell, and an IOGear keyboard. They're also on the 5 key of the keypads for a credit card machine and remotes from Sony and Samsung. Not all Sony's, though; some are defective. I had a close friend who is blind and deaf, and counted on those marks to touch type. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2014-05-12 14:07 +0000 |
| Subject | Re: Fortran |
| Message-ID | <lkqkja$5a4$1@reader1.panix.com> |
| In reply to | #71359 |
On 2014-05-12, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
>> On 2014-05-12 00:15, Steven D'Aprano wrote:
>>> The F and J keys have "F" and "J" printed on them instead of "G" and
>>> "K". They're also in slightly different positions, offset one position
>>> to the left. Otherwise they are identical, to the limits of my vision
>>> and touch. (I haven't tried measuring them with a micrometer, or doing
>>> chemical analysis of the material they are made of.)
Really? No rised dots or ridges?
>> Maybe keyboards are different where you are! :-)
>
> Certainly not. However they may be different where *you* are :-P
>
> I'm using an IBM keyboard, model SK-8820.
>
>> Mine have an little ridge on the keytop of those keys.
>
> I've seen keyboards with those, but not many.
I would guess that at least 95% of the keyboards I've seen in the past
30 years have had them....
--
Grant Edwards grant.b.edwards Yow! One FISHWICH coming
at up!!
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2014-05-11 21:12 -0400 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9903.1399857171.18130.python-list@python.org> |
| In reply to | #71335 |
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith <roy@panix.com> declaimed the
following:
>In article <mailman.9891.1399833209.18130.python-list@python.org>,
> Chris Angelico <rosuav@gmail.com> wrote:
>
>> Some things are more standardized than others. A piano keyboard is
>> incredibly standard, to make it possible to play without having to
>> look at your fingers (even when jumping your hands around, which
>> doesn't happen as much on a computer keyboard)
>
>Speaking of which, here's a trivia question. Without looking at your
>keyboard, describe how the "F" and "J" keys (assuming a US-English key
>layout) differ from, say, the "G" and "K" keys.
On most (US) keyboards, F/J well have some sort of tactile cue (raised
dot/bar, or deeper "dish"), indicating home position for the index fingers.
Typically the same can be said for the 5 key of a numeric pad.
That said, I did encounter a keyboard years ago that put the tactile
markers on D/K.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-12 02:42 +1000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9886.1399826542.18130.python-list@python.org> |
| In reply to | #71303 |
On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola <rtomek@ceti.pl> wrote: > Given that Fortran is here for almost 60 years and lot of effort has > been spent to keep it backwards compatible (AFAIK), I wouldn't hold my > breath. Something may look like cool and great, but wait ten years and > see if after major language revision you can still (more or less) > easily run your existing huge projects with it. The Unix pipe system is still working beautifully, and will continue to do so for the next few decades. Build your system as a number of separate processes that pipe data from one into another, keep your old interpreters and compilers around, and you'll be fine. But retaining that backward compatibility is a huge cost. Sixty years ago's hardware wasn't the same as we have today. You can't simply run the exact same compiler and get the same bytes of output and run them. Someone has to maintain that old compiler, make sure it works with the latest toolchain and hardware, etc. Probably make sure it's bug-for-bug compatible with the original, too. How long do you want to keep that up? It's a huge trade-off. If a language basically says "That code you wrote two years ago? Not gonna work now", then I'd see that as a big blinking red light. But "Ten years ago's code will probably work on today's interpreter, unless it uses as identifiers what's now a keyword, or it might be unintentionally treading on now-fixed bugs in which case it might have to be fixed", that's not as big a problem. Yes, you'd need to 2to3 that old Python 2.3 code to get it to run on Python 3.4, but chances are it'll run mostly-unchanged on 2.7 (modulo string exceptions, maybe). I'm cheating a bit by citing Python 2.7, given that it's now four years old, but it's also going to be supported for a good few more years. Not sixty, presumably, but a good while. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Rola <rtomek@ceti.pl> |
|---|---|
| Date | 2014-05-11 20:04 +0200 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9887.1399831473.18130.python-list@python.org> |
| In reply to | #71303 |
On Mon, May 12, 2014 at 02:42:13AM +1000, Chris Angelico wrote: > On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola <rtomek@ceti.pl> wrote: > > Given that Fortran is here for almost 60 years and lot of effort has > > been spent to keep it backwards compatible (AFAIK), I wouldn't hold my > > breath. Something may look like cool and great, but wait ten years and > > see if after major language revision you can still (more or less) > > easily run your existing huge projects with it. > > The Unix pipe system is still working beautifully, and will continue [...] > > But retaining that backward compatibility is a huge cost. Sixty years > ago's hardware wasn't the same as we have today. You can't simply run > the exact same compiler and get the same bytes of output and run them. [...] > > If a language basically says "That code you wrote two years ago? Not > gonna work now", then I'd see that as a big blinking red light. But > "Ten years ago's code will probably work on today's interpreter, > unless it uses as identifiers what's now a keyword, or it might be > unintentionally treading on now-fixed bugs in which case it might have > to be fixed", that's not as big a problem. Yes, you'd need to 2to3 > that old Python 2.3 code to get it to run on Python 3.4, but chances > are it'll run mostly-unchanged on 2.7 (modulo string exceptions, > maybe). I'm cheating a bit by citing Python 2.7, given that it's now > four years old, but it's also going to be supported for a good few > more years. Not sixty, presumably, but a good while. > > ChrisA I can easily agree to your points. Personally I don't really care much about decades-old codes (unless I want to play with them inside some emulator). There was indeed a lot of change in OSes and hardware, and languages should keep up with it, if possible. And the "pipe extention" is one of the things I'd consider - as well as other similar means, like SOAP or REST. However, obsoleting code younger than five years does not feel good to me. AFAIK big projects take years to be written, polished up, debugged and sometimes refactored (during this time they may also be used and go throu their own big version changes), so it is really big pain to see how after all this work someone's decision changes ground under one's feet. As of remark by Marko Rauhamaa, that "Fortran is successful with people who don't know how to program and don't care" - I wrote maybe two Fortran programs so far, both very simple. I tried to obey so called rules, inserted comment lines, checked for return values and issued warnings/errors when needed, didn't use goto excessively (AFAIR), didn't make stupid things like changing index variable inside loop (other than by predefined step in one and only one place, be it by hand or by compiler). For one program I got max points to get (uni course) and for the other I have been presented with a basket of strawberries. Was I successful - or my use of Fortran :-)? OTOH I once had to work with someone else's Java code, a huge class in huge file and I found it too borked to repair so I rewrote from the scratch. Will I write some more code in Fortran - maybe, or maybe not. I don't feel any urgent need to do this. There is still a lot of things I'd like to learn and a day has only so many hours. I consider Fortran a useful tool which may possibly outlive me (but let's wait and see :-) ). As of quality of its users, sure, I consider programming a full time activity and it is very hard to find people who want to be good at it *and* in their supposed domain at the same time. Heck, I keep reading it is hard to find people who would like to be good in anything at all. Perhaps part of the problem is unwillingness to tackle it. I think majority of people would like to do things better, especially if it only requires small changes in behaviour. But they simply don't know there is better way, because nobody cared to tell them or show by example. Or nobody knew there were some people who would have been happy to hear a word of advice. Well, at least it is nice to believe in this. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-12 04:12 +1000 |
| Subject | Re: Fortran |
| Message-ID | <mailman.9888.1399831957.18130.python-list@python.org> |
| In reply to | #71303 |
On Mon, May 12, 2014 at 4:04 AM, Tomasz Rola <rtomek@ceti.pl> wrote: > And the "pipe > extention" is one of the things I'd consider - as well as other > similar means, like SOAP or REST. Yep. My point was, keep the processes separate and it's easy. There are myriad ways of doing the glue. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2014-05-11 19:05 +0200 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <87mweotfe5.fsf@dpt-info.u-strasbg.fr> |
| In reply to | #71295 |
Mark H Harris <harrismh777@gmail.com> writes: > On 5/10/14 8:42 AM, Roy Smith wrote: >> http://tinyurl.com/mr54p96 > 'Julia' is going to give everyone a not so small run for competition; > justifiably so, not just against FORTRAN. > > 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. Conversion happens because all arithmetic is overloaded for various types, and julia does multi-dispatch. There is little chance number-crunching applications will shine in julia, unless everything is statically typed. > BigFloats are by default arbitrary precision with full scientific and > transcendental functions built-in, everything complex just works, and > did I mention its fast? Yes, julia wraps GMP and MPFR, just like many compilers already do (e.g., gcc). Very good, but nothing specific to julia here. And for linear algebra, julia uses... BLAS and LAPACK. And fftw for FFT. And so on. Nothing new for a Fortran programmer, really. > The bench-marks are within 2x of C across the boards; makes Matlab > look like a rock, and is well ahead of python (NumPy SciPy) for > technical computing. 2x for syntactic sugar is a lot. But yes, numpy/scipy developers should watch out... > Julia is still very much beta in my opinion but its maturing fast. Its > open free (libre) and cross platform and did I mention it flatout > screams? Not only will it replace FORTRAN completely if things keep > progressing, but also Matlab, Mathematica, NumPy, & SciPy (and > others). Keep your eye on her fellows. Well, Fortran experts around me are skeptic. -- Alain.
[toc] | [prev] | [next] | [standalone]
| From | Mark H Harris <harrismh777@gmail.com> |
|---|---|
| Date | 2014-05-11 13:54 -0500 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <lkoh14$rpq$1@speranza.aioe.org> |
| In reply to | #71326 |
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(): > julia> sqrt(-1+0im) > 0.0 + 1.0im > julia> sqrt(complex(-1)) > 0.0 + 1.0im > julia> sqrt(2) > 1.4142135623730951 >julia> sqrt(2.0) > 1.4142135623730951 > julia> sqrt(BigFloat(2.0)) >1.414213562373095048801688724209698078569671875376948073176679737990732478462102 >e+00 with 256 bits of precision >julia> with_bigfloat_precision(1024) do > sqrt(BigFloat(2.0)) > end >1.414213562373095048801688724209698078569671875376948073176679737990732478462107 >03885038753432764157273501384623091229702492483605585073721264412149709993583141 >32226659275055927557999505011527820605714701095599716059702745345968620147285174 >18640889198609552329230484308714321450839762603627995251407989687253402e+00 >with 1024 bits of precision 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. 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: >julia> prec=524288 >524288 >julia> with_bigfloat_precision(prec) do > println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4) > end The scientific and transcendental functions (built-ins) just work. The coder sets the precision in floating point bits, and the functions just work --- at that precision. Nothing needs to be imported, and special functions are not necessary. The maths are unified, and they are fast; yet, the coder has the flexibility and ease of python coding, with a very useful repl. But, like lisp, Julia's internal structures are lists, so, it can create and modify its own code on-the-fly. Unicode characters above code point \u00A0 can be used as symbols, and constants ARE their unicode characters: >julia> sin(π/4) > 0.7071067811865475 >julia> cos(π/4) > 0.7071067811865476 >julia> sin(BigFloat(π/4)) > 7.0710678118654750275194295621751674626154323953749278952436611913748 > 20215180412e-01 with 256 bits of precision marcus
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-05-12 04:59 +1000 |
| Subject | Re: Fortran (Was: The "does Python have variables?" debate) |
| Message-ID | <mailman.9893.1399834783.18130.python-list@python.org> |
| In reply to | #71336 |
On Mon, May 12, 2014 at 4:54 AM, Mark H Harris <harrismh777@gmail.com> wrote: > 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: > >>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). ChrisA
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web