Re: Code as documentation

glen herrmannsfeldt wrote:
mecej4 wrote:
Paul van Delst wrote:
(snip)

So ... X/Y*Z is looked upon with disfavour?

This case is confusing because the Fortran meaning differs from that
in a mathematical text. In algebra, the convention is that a/bc means
<Fortran> a/(b*c) </Fortran>, as opposed to <Fortran> a*c/b)
</Fortran>

As far as I know, a/bc in algebra means (a/b)*c, but in a
book you can write:

a
-----
b c

which means a/(b*c). You can't do that in Fortran.

I am not so sure that the current algebraic precedence wasn't
borrowed back from Fortran, though.

In fact I have several math books older than Fortran and I can't,
on quick perusal, even find forms like a/bc in them. They always
write the horizontal line with 'a' on top and 'bc' on the bottom.
It's doubtful that such a form was even used, much less that it
had a specific meaning. Now, they do often use things like x/y,
with only one thing top and bottom. I can't even find instances
of things like ab/c. The only common multiletter form is dy/dx,
but there the numerator and denominator are still single entities.

The / operator probably shouldn't associate. That is, all uses of
it where either operand is an expression with another operator of
the same precedence should probably be required to be parenthesized
to clarify meaning:

a/(b*c) or (a/b)*c and not a/b*c
(a/b)/c or a/(b/c) and not a/b/c
(a*b)/c or a*(b/c) and not a*b/c

You could have Fortran generate a warning message of any of the
non-parenthetical forms above are used. It can't be a fatal error
because of backward compatibility.

The same argument might be applied to subtract (-), except there
*is* an existing mathematical interpretation for that.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


.

Relevant Pages