(j3.2006) (SC22WG5.5040) Decision on Units TS proposal

Van Snyder Van.Snyder
Thu Jul 25 18:24:26 EDT 2013

On Thu, 2013-07-25 at 10:11 +0200, Tobias Burnus wrote:

> On the other hand, implementing all the features suggested in N1970
> will be a very large effort for compiler implementers

I have been told on more than one occasion that it wouldn't be nearly as
difficult as some imagine it to be.  One developer told me that the
necessary work in expressions just isn't that difficult, while argument
checking and generic resolution would be similar to and based upon
treatment of kind type parameters.  Creating conversion functions is
trivial.  The most difficult part would be checking and converting units
during input (which I have done, without tremendous difficulty, in the
"little language" configuration files that drive three of our program).
This could rely on some of the infrastructure necessary for namelist
(connecting names of units to addresses of conversion functions instead
of variables), but it would also require duplicating some of the simpler
aspects of generic resolution at run time (by "simpler" he meant only
those aspects dealing with kind parameters for one argument functions,
not type, rank, number of arguments, optional and keyword arguments, or
allocatable vs. pointer).

> and I fear that it will also divert the attention of the committee
> from more pressing issues.

Support for units is proposed as a TS precisely so that it WILL NOT
INTERFERE with the next revision's work plan!  If you take the trouble
to look at N1969, not just the necessarily superficial slides in N1970,
you'll see that the project, as an ISO publication, is finished already.
I made the point during the presentation in Delft that it has already
had seventeen rounds of off-line review since I began work on the
document in its present form in 2009.  I have given the problem a great
deal of thought since I and my colleagues first proposed it in 1978 to
the developers of the requirements for what became Ada.  Development of
it has taken NO TIME at J3 or WG5 meetings.  Administrative issues
("could we please do this?") have taken fewer than 90 minutes of J3 and
WG5 time during the last 23 years, since I first proposed it for
Fortran.  This is precisely how development of a TS should proceed,
although not on a decades-long schedule.  My opinion is that we could
finish it by saying "OK, let's do it," have a letter ballot, and send it
to ISO for publication.

What "more pressing issues" would be displaced by units from the next
revision's work plan? (!!!)  N1982, appended below, is a collection of
vapid trivialities!  For example, US-12 requires deleting "SIZE=" at two
places and "nonadvancing" at one place -- and that's a complete work
item, over which J3 agonized twice and WG5 once!  The only reason it's
on the work plan, and not in 13-008 (where there are far more
complicated revisions), is that this is a "new feature" instead of
cannonball polishing.

We have chosen such a meaningless revision because a more ambitious one
couldn't be done on the schedule we have, but the problem of meeting the
schedule is a problem of our own making!  The current standard was
finished five years ago.  Since that time, neither WG5, nor J3 nor any
other member body of which I am aware, gave any thought to developing
requirements for the next standard -- pressing issues or not -- until
late fall of last year.

I characterized that as "sitting on our hands," to which Malcolm took
exception, but I don't know what else to call "doing nothing" to prepare
for the next revision, for five years.  Somehow, we managed to find
eight years to piss away (I can't think of a more polite but still
accurate description) on a pointless favor for WG23, which material
should have been in textbooks, not an international standard, but we
couldn't find time to do anything to increase reliability of Fortran
programs by developing our own standard.

WG5 and J3 have chosen not to tackle anything substantial, at least not
in the work plan for the standard.  Further features for parallel
programming and C interoprability were tackled as technical
specifications that had independent schedules and a different project
editor, precisely so that they would NOT INTERFERE with the work plan
for further development of the standard proper -- but there was no work
on further development of the standard proper being done at that time!

Perhaps you're thinking of TS 18508, concerning further coarray parallel
programming features?  The experience at Delft demonstrated that this
project is not ready for prime time.  Much more thought (and
correspondence) needs to be put into this before it appears again at J3
or WG5 meetings.  We should not be developing major facets of it in
subgroup, on Thursday at a meeting, and then voting it into stone at the
next meeting, or worse, on Friday.  Diverting attention from this
project might well be a good thing.

If there really are "pressing issues," perhaps J3 ought to revert to a
schedule of four meetings per year, with separate instead of joint J3
and WG5 meetings, as was the case when we actually had "pressing issues"
in Fortran 2003.  Much more could also be done by e-mail between J3 and
WG5 meetings.

If N1969 were to appear as a TS, processor developers would put
independent priorities on developing support for it, exactly as they
have done with parameterized derived types, coarrays, submodules, and
new interoperability features.  Users appreciate having descriptions of
new features in the standard or a TS, even if they're not yet widely
available, and developers respond to the weight of their customers'
opinions concerning where to concentrate their efforts.

> PS: You wrote in N1970 that "Incorrect use of physical units is the
> third most common error in scientific or engineering software". I
> wonder where the numbers come from

That came from software development notebooks in the 1970's.  It was the
reason for proposing a system of units during the requirements phase for
what became Ada, at the "woodenman" stage, if I remember correctly.  I
wouldn't be surprised if Les Hatton had some numbers instead of the
vague handwaving I was left with.

>  and what are first two.

Page v in the introduction in N1696 says

        "The most common errors in scientific and engineering software,
        that a language and its processor might be expected to
        ameliorate, are mismatched, missing or excess actual arguments
        in procedure references, followed by out-of-bounds array
        references, and then incorrect use of physical units of measure.
        Explicit interfaces largely solve the first problem and help to
        avoid the second problem, but do nothing directly for the

(my emphasis here).

> With the software I had to do with, "<" instead of ">", missing terms,
> wrong signs and similar issues seem to play a much larger role than
> units. - More common than those are of course out of bounds,
> uninitialized variables and other such problems. 

Changes to Fortran, or indeed any feature of any language, will not help
with "<" instead of ">", missing terms, wrong signs, incorrect
constants, uninitialized variables....  There is no fruitful comparison
between these problems and those that can be addressed by language

Concerning subscripts being out of bounds, Ada goes further than Fortran
by providing named subranges of integers, which names can be used to
declare array bounds.  Thereby, if the subscript is declared by
reference to the same named subrange, there can be no bounds violation
at the point of reference.  The only place that needs to be checked is
where the subscript variable gets its value assigned.  If it's an
induction variable that gets its limits by referenced to the subrange
name, e.g., "for i in my_subrange loop ... end loop;", the processor can
prove a compile-time theorem that no bounds violation can occur.  I
proposed something along these lines for Fortran.

> PPS: At least two of the codes I used, have internally atomic units
> (hbar = 1, electron charge = 1, Bohr radius = 1, electron mass =1. As
> alpha has to remain at ~1/137 [unitless!], the speed of light c =
> 1/alpha; energy and time are measure in units of 1). Given that most
> expressions are done unitless (conversion factor is 1), I wonder
> whether the programmers would move to your proposed units feature in
> those codes, if it were available.

What happens if you add unitless "mass" to unitless "charge?"  Is that
really meaningful?  Maybe you can eliminate conversion units, and
possibly even composite units, but can you really eliminate atomic
(i.e., indivisible, as defined in N1969) units?

One of the theorems of dimensional analysis is that if your problem has
variables with M units, based upon N fundamental quantities, you can
eliminate at most M-N (composite or conversion) units.  So maybe you can
eliminate the distinction between pounds and Newtons, or radians and
degrees, but not between length, time, temperature....

It's hard to imagine that spacecraft altitude, range, velocity, ..., or
an instrument's spectrometer channel power measurement, ..., will be
reported using unitless quantities.  Even if one can eventually develop
a formulation wherein analogues of those quantities enter in an unitless
manner, somewhere along the line, the original data must be put in that
form.  That's a step where an error in units could cause a catastrophic
error.  My university diploma says "system engineering."  I have spent
my entire career pondering entire problems, entire systems, not single
lines of code, single procedures, or even single programs.


The following items are identified by WG5 as deficiencies and discrepancies in
Fortran 2008 to be addressed in Fortran 2015 development.  For detailed
information on each item see the referenced papers.

UK items (N1975):
  UK-02 (Specifiable default accessibility for USEd module's entities)
  UK-03 (RECL= for umlimited records)
  UK-04 subitem 1 only (allow E0.d, ES0.d, EN0.d edit descriptors)
  UK-05 (Improve generic disambiguation rules)
  UK-06 (Remove restriction on ERROR STOP)
  UK-08 (New reduction intrinsic REDUCE)
  UK-09 see US-14.
  UK-10 except subitems 2c and 3
        (Delete arithmetic IF, shared DO termination, and DO termination other
         than on CONTINUE and ENDDO;
         Obsolesce EQUIVALENCE, COMMON, label on block DO, specific intrinsics,

US items (J3/13-244r1):
  US-01 (Allow g0.d)
  US-03 (Require diagnosability of nonstandard intrinsic modules et al)
  US-04 (Control of host association), see J3/13-238.
  US-05 (Improve DIM= argument handling in intrinsics), see interp F08/0038.
  US-08 (Specify explicit specification of EXTERNAL attribute is required)
  US-12 (Allow SIZE= with advancing input)
  US-14 (Compatibility with ISO/IEC 60559:2010).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20130725/ce05b0eb/attachment.html 

More information about the J3 mailing list