Functions with side effects
in [Fortran]
|
From: nmm1 on 15 Jul 2010 17:53 In article <i1nsuc$dg1$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >nmm1(a)cam.ac.uk wrote: >> In article <i1nr9c$2r5$1(a)newsreader5.netcologne.de>, >> Thomas Koenig <tkoenig(a)netcologne.de> wrote: >(snip) > >>>Let's say the compiler writer introduces an optimizatio that >>>replaces an expression like > >>> b = f(x) + f(x) > >>>with > >>> aux = f(x) >>> b = aux + aux > >>>even if f is not known to be PURE? > >>>Would that compiler writer introduce a bug into his/her compiler? > >> No. > >OK, but how about: > > a = f(x) > b = a+f(x) >with > b = 2*f(x) > >Or even more: > > a=0 > do i=1,10 > a=a+f(x) > enddo > >with a=10*f(x) In a word, "no". Regards, Nick Maclaren.
From: mecej4 on 16 Jul 2010 08:36 nmm1(a)cam.ac.uk wrote: <-- CUT --> > Old fogies (who me?) will optimise that manually and automatically > as we code, because that's what we did; I assume that you do. But > people who were taught programming style will often write loops > like the above, because they were/are taught to write what the > algorithm says. And the compiler can get a BIG speedup by moving > the function call out of the loop, of course. > > And, as you know, practical code is rarely that simple, so the > issue arises in many unobvious contexts. Doing the optimisation > manually often obfuscates the code considerably, and that's very > bad for maintainability. But most old fogies are also very good at reading manually optimized code and mentally reconstructing the more straightforward unoptimized code, no? -- mecej4
From: nmm1 on 16 Jul 2010 08:59 In article <i1pjof$3bv$1(a)news.eternal-september.org>, mecej4 <mecej4.nyetspam(a)operamail.com> wrote: > >> Old fogies (who me?) will optimise that manually and automatically >> as we code, because that's what we did; I assume that you do. But >> people who were taught programming style will often write loops >> like the above, because they were/are taught to write what the >> algorithm says. And the compiler can get a BIG speedup by moving >> the function call out of the loop, of course. >> >> And, as you know, practical code is rarely that simple, so the >> issue arises in many unobvious contexts. Doing the optimisation >> manually often obfuscates the code considerably, and that's very >> bad for maintainability. > >But most old fogies are also very good at reading manually optimized code >and mentally reconstructing the more straightforward unoptimized code, no? Only in simple cases. When you have a 3,000 line procedure, with some expressions moved hundreds of lines across several levels of DO-loop, we all have trouble. And that's not unusual for ones created by Matlab or Mathematica. Regards, Nick Maclaren.
From: gmail-unlp on 16 Jul 2010 21:33 > >I'm saying that in this particular case it becomes undefined. That > >means you or I can't reliably and portably predict what its value will > >be. I cannot associate this definition with any of the "Events that cause variables to become undefined" in section 16.5.6 of the 2003 standard... What am I losing? > So, then, having N in COMMON is the same as being global? -- > it's still undefined? Would you please write the example? I get confused with the current "n", which is defined in the MODULE... Fernando.
From: gmail-unlp on 16 Jul 2010 21:37
On Jul 16, 10:33 pm, gmail-unlp <ftine...(a)gmail.com> wrote: > > >I'm saying that in this particular case it becomes undefined. That > > >means you or I can't reliably and portably predict what its value will > > >be. > > I cannot associate this definition with any of the "Events that cause > variables to become undefined" in section 16.5.6 of the 2003 > standard... > What am I losing? > Sorry, I was losing " When an object is given a valid value during program execution, it is said to become defined. This is often accomplished by execution of an assignment or input statement. " in section 2.5.5, so, n is defined... Fernando. |