From: Carlie Coats on
Ron Shepard wrote:
> In article <7sdj45FmphU1(a)mid.individual.net>,
> Carlie Coats <carlie(a)jyarborough.com> wrote:
>
>> (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.
>
> I'm curious how many times you have made this error in your code and
> had trouble finding it...

Twice in someone else's code I've been trying to help fix, just this
past month. -- Carlie

From: dpb on
Carlie Coats wrote:
> Ron Shepard wrote:
>> In article <7sdj45FmphU1(a)mid.individual.net>,
>> Carlie Coats <carlie(a)jyarborough.com> wrote:
>>
>>> (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.
>>
>> I'm curious how many times you have made this error in your code and
>> had trouble finding it...
>
> Twice in someone else's code I've been trying to help fix, just this
> past month. -- Carlie

I'm having trouble visualizing this specific error as anything other
than a logic error in the program that would seem hard to expect the
syntax to solve. In these cases, what was intended to be loaded if not
an array load; surely it must have been a case of using the wrong
variable name or similar?

That is, it seems to me the error must arise from either just
remembering the wrong name for the intended variable and getting one
that is in use by mischance or deliberately using the scalar and having
a mistaken idea of what is or is needed to be accomplished by the code
in question on the problem specification at that point.

Maybe I'm missing the obvious (wouldn't be first time... :) )

--


From: Paul van Delst on
dpb wrote:
> Carlie Coats wrote:
>> Ron Shepard wrote:
>>> In article <7sdj45FmphU1(a)mid.individual.net>,
>>> Carlie Coats <carlie(a)jyarborough.com> wrote:
>>>
>>>> (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.
>>>
>>> I'm curious how many times you have made this error in your code and
>>> had trouble finding it...
>>
>> Twice in someone else's code I've been trying to help fix, just this
>> past month. -- Carlie
>
> I'm having trouble visualizing this specific error as anything other
> than a logic error in the program that would seem hard to expect the
> syntax to solve. In these cases, what was intended to be loaded if not
> an array load; surely it must have been a case of using the wrong
> variable name or similar?

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).

I can't see any hand-holding syntax making these sorts of issues go away (without
obfuscating the source code even further). Seems to me to be more of a training problem.

Anyway....

cheers,

paulv


>
> That is, it seems to me the error must arise from either just
> remembering the wrong name for the intended variable and getting one
> that is in use by mischance or deliberately using the scalar and having
> a mistaken idea of what is or is needed to be accomplished by the code
> in question on the problem specification at that point.
>
> Maybe I'm missing the obvious (wouldn't be first time... :) )
>
> --
>
>
From: Gordon Sande on
On 2010-01-28 14:48:32 -0400, dpb <none(a)non.net> said:

> Carlie Coats wrote:
>> Ron Shepard wrote:
>>> In article <7sdj45FmphU1(a)mid.individual.net>,
>>> Carlie Coats <carlie(a)jyarborough.com> wrote:
>>>
>>>> (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.
>>>
>>> I'm curious how many times you have made this error in your code and
>>> had trouble finding it...
>>
>> Twice in someone else's code I've been trying to help fix, just this
>> past month. -- Carlie
>
> I'm having trouble visualizing this specific error as anything other
> than a logic error in the program that would seem hard to expect the
> syntax to solve. In these cases, what was intended to be loaded if not
> an array load; surely it must have been a case of using the wrong
> variable name or similar?
>
> That is, it seems to me the error must arise from either just
> remembering the wrong name for the intended variable

Or being distracted after one has figured which array but before one
has figured out
exactly what subscipt to apply. This is more likely if it is part of a
cut and paste.

> and getting one that is in use by mischance or deliberately using the
> scalar and having a mistaken idea of what is or is needed to be
> accomplished by the code in question on the problem specification at
> that point.
>
> Maybe I'm missing the obvious (wouldn't be first time... :) )


From: Carlie Coats on
dpb wrote:
> Carlie Coats wrote:
>> Ron Shepard wrote:
>>> In article <7sdj45FmphU1(a)mid.individual.net>,
>>> Carlie Coats <carlie(a)jyarborough.com> wrote:
>>>
>>>> (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.
>>>
>>> I'm curious how many times you have made this error in your code and
>>> had trouble finding it...
>>
>> Twice in someone else's code I've been trying to help fix, just this
>> past month. -- Carlie
>
> I'm having trouble visualizing this specific error as anything other
> than a logic error in the program that would seem hard to expect the
> syntax to solve. In these cases, what was intended to be loaded if not
> an array load; surely it must have been a case of using the wrong
> variable name or similar?
>
> That is, it seems to me the error must arise from either just
> remembering the wrong name for the intended variable and getting one
> that is in use by mischance or deliberately using the scalar and having
> a mistaken idea of what is or is needed to be accomplished by the code
> in question on the problem specification at that point.
>
> Maybe I'm missing the obvious (wouldn't be first time... :) )

The most recent one looked somewhat like the following:

MODULE M
...
INTEGER, ALLOCATABLE :: KQ( :,: )
...
SUBROUTINE S( M, N, <etc> ) ! 1500 lines later
...
INTEGER K
...
DO R = 1, M
DO C = 1, N
...
KQ = K !! should have been "KQ(C,R) = K
...

Sloppy omission/error, just like "DO10I=1.10" was...

-- Carlie