On Jan 14, 2005, at 8:28 AM, Anthony Stone wrote:

> At 23:01 on 14 January, Yasuki Arasaki wrote:
>
>> Of course the usual answer is that modern control structures
>> are better at doing what the computed goto was used for, but
>> you show a particular problem that seems not to be the case.
>
> That is my point.

These things are always judgment calls. I don't think there is any
construct that doesn't have *SOME* case where someone considers it
better. I have seen people claim to prefer every single one of the
obsolescent features, including some of the ones that I personally
consider far harder to justify.

Specifically, yes, I've seen one person (or maybe it was two) claim to
like and have application for the character*(*) function results. And
before a horde jumps in to say that they do also, realize that 99% of
the people who say that they use or would this feature don't actually
understand what the obsolescent feature is and how it really works. No,
it isn't about character*(*) dummy arguments. The one or two people in
question did actually seem to understand it - most don't.

And I've seen people who praise the benefits of fixed source form. The
terms that I'd use to describe my personal attitude on fixed source
form aren't suitable for this forum.  :-)

Of course, as often mentioned, the odds of the obsolescent features
actually going away anytime soon seem low. As an experiment in trying
to find some way to avoid infinite growth in the language, the concept
of obsolescent features doesn't seem to be being very successful.  (Too
bad, because I personally like the concept).

> It is accumulating contributions to multipole moments. Each set of
> contributions is known to be zero above a maximum rank, evaluated for
> each set and specified by "index" in the code. Although the
> higher-rank contributions are known to be zero, one doesn't want
> to execute the code for them, not only because it wastes cpu time but
> because intermediate values used in the calculation have been
> evaluated only for the non-zero ranks.

Hmm. I'm not sure whether you are looking for suggestions or just
making observations/comments. I sort of gather that it is more the
latter, so perhaps there is no need for suggestions. I'll offer
something anyway, though I'll not presume to call it a suggestion -
rather an illustration of what I might do.

 From the description, I think I'd probably code it along the lines of.
(I didn't look back at the original to get the variable names, values,
etc, but this should be adequate to illustrate the structure).

   if (index >= 1) then
      ...
   end if

   if (index >=2) then
     ...
   end if

   if (index >= 3) then
     ...
   end if

Although one could nest these, avoiding redundant tests after one
fails, I probably wouldn't bother unless the performance was critical
enough that a few extra tests were noticeable (which seems unlikely,
though I won't say it is impossible). I think it is "cleaner" without
the nesting.

I won't try to argue that this is a "better" choice than whatever one
someone else might make. I just present it as what I personally would
probably do based on the data that I now have. (And I might possibly
make a different decision if I had more data).

--
Richard Maine                |  Good judgment comes from experience;
[log in to unmask]       |  experience comes from bad judgment.
                             |        -- Mark Twain