[J3] 18-156

[Van Snyder]

On Mon, 2018-02-26 at 23:24 +0000, Bill Long via J3 wrote:
> > On Feb 26, 2018, at 4:25 PM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:

> >> I don't understand how degree trigonometric functions are helpful
> >> without units support.  Units support would allow generic resolution to
> >> select the correct one.
> > 
> > If, upon reflection, you really do not see how the degree trig
> functions are helpful without units support, please contact me.   I?ll
> either phone or write something up.   Seems fairly self-evident to me,
> and I?m thinking that this is just a back-door argument into a
> well-trodden tangent.
> 
> The degree trig functions are for programmers who know what they are
> doing.  Unrelated to UNITS. Particularly since Radians intentionally
> do not have units. 

Sorry, but I actually know what I'm doing, and have known for half a
century.  Among other problems, I have to struggle with modules given to
me that have procedures with arguments named "latitude" and "height"
with no comments that specify the units.  It usually requires
significant reverse engineering if I have the source code, or "black
box" probing if I don't have source code, to determine the units the
codes expect.  And I mean measure, not fundamental units.  Using length
instead of angle is rare.  Using degrees instead of radians, or meters
instead of kilometers is common.  If I can actually find and contact the
author, the answer is frequently "Gee, I don't remember" or "Do you have
a charge number?"  When I'm maintaining or augmenting existing code I
have to do some reverse engineering to track down the units, even in
code I've been working on for twenty years, because it's a third of a
million lines, and developed by a dozen or so colleagues who have died,
retired, resigned, or are now working on something else.  Every time I
work out the measure of something, I insert comments, but the processor
doesn't respect them or use them to tell me there's a mistake.  This has
significant and recurring nonzero cost.

If Bill had read any of the units proposals, which have been through 19
revisions, each revision only getting a new number because somebody
commented upon the previous one, he would know that it proposes that
units be used for generic resolution, and in particular it proposes an
intrinsic RADIAN unit (the only proposed intrinsic unit) that would be
used for generic resolution and checking.  Adding an intrinsic DEGREE
unit would be trivial.

Sorry, but Radian is an SI derived unit, just like kilogram.  The base
quantities are angle and mass.  Radian and steradian are dimensionless,
but are SI units nonetheless.

Read David Parnas's paper in December 1970 Communications of the ACM.
He pointed out, 47 years ago, that the cost of a change to a program is
more likely proportional to the size of the program than the size of the
change, because the representations of objects are exposed in their
syntax of usage.  Read the article by Douglas T. Ross in "Software
Engineering," Academic Press (1969), J. T. Tou (Ed).  Read the paper by
Charles M. Geschke and James G. Mitchell in IEEE Transactions on
Software Engineering SE-1, 2 (June 1975).  We're now proposing to
perpetuate that the cost of a change to a program is proportional to the
size of the program, not the size of the change, by requiring to use SIN
or SIND, depending upon the representation of the argument.  What
happened to abstraction?  Have we not learned anything?  Putting an
annotation on the declaration of an object, instead of on or near every
reference to it, goes a long way toward reducing the cost of a change
from "size of the program" to "size of the change."

> Van knows that UNITS were killed at the London WG5 meeting.  I assume
> he informed his colleagues that this was a dead issue. 

When I asked what the objections were, Dan and John produced a document
that says "nobody asked for it."  Grant Petty asked for it.  I asked for
it on behalf of dozens of my colleagues who develop and maintain
software for engineering and scientific applications, not device drivers
or video games or web pages.  Others supported it in comp-fortran-90 and
comp.lang.fortran.  Marcus Foster wrote about it recently.  Students at
Cambridge thought it was important enough to develop a toy that does a
tiny fraction of the job.  I still have no idea what the real objections
are.

How did the proposal go from "Yeah!" to "yeah" to "maybe" to "maybe not"
to "Hell NO!" during the last fourteen years?  The problems it addresses
haven't gone away, and we haven't done anything to address them by other
means.

The last two revisions of the standard were entirely focused on
performance.  Can we ever do anything about reliability, and reducing
labor costs?

For the present revision we insist upon use cases.  Does anybody have a
use case more extreme than having lost a $200 million project?  It's a
charade.  The "hide the ball" answer provoked a conclusion among my
colleagues that there's something else going on.