Another class of "DO10I=" bug [Fortran]

Prev: select specified columns in ch. array
Next: Format with implied do loop

From: robin on 1 Feb 2010 08:39

From: robin on 1 Feb 2010 08:39

"Carlie Coats" <carlie(a)jyarborough.com> wrote in message news:7sdj45FmphU1(a)mid.individual.net...
| Arjen Markus wrote:
| [snip...]
| > That said, yes, array assignments can be visually misleading.
| > I prefer to emphasize them by putting empty lines around
| > them, making them stand out a bit. (But I am not sure I do
| > that consistently ;)).
|
| And what I'm saying is: that's not good enough. One can not
| visually tell the following apart; only (4) and mismatched-shape
| versions of (2) are syntax errors, and (3) is a dangerous implicit
| type conversion which requires (probably off-screen) declaration
| info to realize it's happening:
|
| (1) <scalar> = <scalar>
| (2) <array> = <array>
| (3) <array> = <scalar>
| (4) <scalar> = <array>
|
| My contention is that I wish (3) were also a syntax error,
| with functionality replaced by
|
| (3) <array> = SHAPE( <scalar>, <dimension-list> )
|
| so that the accidental, erroneous, *damnably*-hard-to-find
| uses of (3) would be caught at compile time.

In what way would that be an error?

From: Paul van Delst on 4 Feb 2010 10:20

Carlie Coats wrote:
> Paul van Delst wrote:
> [snip...]
>> I have to agree with you here. In my world, these sorts of
>> problems are more due to lack of experience/know-how on
>> the part of the programmer. What % of scientists/engineers/etc
>> that write Fortran90/95/2003 code today have had formal
>> training in a) Fortran90/95/2003 or b) software design/
>> construction? I bet the magnitude of the latter category
>> is larger than the first.
>>
>> One way I have tried to combat these errors from occurring
>> is to encourage people to write short procedures rather than
>> the more usual monolithic ones in which it is very easy to
>> lose the context. But, it's pretty hard to break the
>> "everything and the kitchen sink" > type of programming
>> habit (me included).
>
> Gordon Sande wrote:
> [snip...]
>> Or being distracted after one has figured which array but
>> before one has figured out exactly what subscipt to apply...
>
> Training and mis-training for scientists and engineers
> *is* a big problem. Among meteorologists, for example,
> it seems that many of them have been encouraged to get
> loop-order vs subscript order exactly backwards. And man
> other evil practices.
>
> Distraction is also a major problem. Getting time uninterrupted
> can be almost impossible for some people at some offices (I think
> that *is* what happened in this last case). And their work shows it.
> But the PHBs don't believe you when you complain.
>
> So is complexity, and managing it properly.

Yeah, that was the main/starting message of my last seminar on Fortran95/2003 ("What can
modules do for you?") - managing complexity.

I brought up the usual buzzwords (encapsulation, decoupling, etc..) but had to move on to
describing syntax when the eyes of the folks in the audience started to defocus.

> For environmental models, the problem frequently is manipulating
> the programmatic representation of a complex state. The way
> I prefer to do this is to implement each sub-model as a large
> MODULE containing its state as PRIVATE variables, CONTAINing
> only PUBLIC routines necessary to input, manipulate, and output
> that state (which may further call upon otherPRIVATE routines).
> For a land surface model, this can lead to 3000-line modules
> mostly consisting of a number of subroutines.

We've taken that sort of approach with the model I work on. I'd say we've been about
halfway successful - it's one of those cases where early design decisions based on naivet�
were just bad decisions. But, refactoring and unit testing has proven useful. Nevertheless
we still battle the "quick and easy" types of solution because managers want to see
milestones met and results need to be shown at conferences and journal articles need to be
written etc. etc.

I have to say that as the years go by and the complexity of our model increases (i.e. our
parameterisations get closer and closer to approximating reality), I view an object
oriented approach much much more favourably purely from the standpoint of code
maintenance. My use of the PRIVATE statement within derived type definitions has been
increasing of late. :o)

>
> This seems to me far better than the competing ideas:
>
> (1) the whole model is a vast conspiracy to manipulate
> that state, which is contained either in a set of COMMONs
> or as PUBLIC variables in modules whose only purpose is
> to host those variables (this is the most-common strategy,
> as in MM5 or SMOKE);
>
> (2) Everything is a subroutine argument (this holds second
> place) (frankly, I don't find subroutines with 50 or more
> arguments maintainable, as in the NOAH LSM);
>
> (3) The entire model state is a derived-type variable,
> with hundreds of fields, and which is INTENT(INOUT) for
> all the subroutines (as in the solver part of WRF);
>
> (4) The subroutines are small, but the call trees are
> *very* deep: in order to understand the I/O structure
> of WRF, you need to understand at one time 14 levels of
> a 17-level call tree, for which two of the calls are
> indirect, to a subroutine passed to its caller as an
> argument: the entire I/O structure is hard-coded into
> this call-tree.

I seem to recall reading somewhere (maybe "Code Complete"?) that a nesting of more than a
handful of levels has been shown to be A Bad Thing.

> Then again, the software-engineering literature suggests
> that "moderate"-sized routines of typically 200-500 lines
> minimize the bug-count.

And they're easier to test individually, too, since there tend to be fewer dependencies.

> FWIW -- Carlie

Yes, anyhoo..... :o)

cheers,

paulv

First | Prev |
Pages: 1 2 3 4
Prev: select specified columns in ch. array
Next: Format with implied do loop