From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Jul 26 00:24:45 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id B5E78357193; Fri, 26 Jul 2013 00:24:45 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by www.open-std.org (Postfix) with ESMTP id 6A1A33570D9 for ; Fri, 26 Jul 2013 00:24:29 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6PMORMc020878 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Thu, 25 Jul 2013 15:24:27 -0700 Subject: Re: (j3.2006) (SC22WG5.5038) Decision on Units TS proposal From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: <51F0DD9B.6040802@net-b.de> References: <20130724235846.299F4357176@www.open-std.org> <51F0DD9B.6040802@net-b.de> Content-Type: multipart/alternative; boundary="=-CceyigBperngTM7sItG/" Organization: Yes Date: Thu, 25 Jul 2013 15:24:26 -0700 Message-ID: <1374791066.9751.901.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-30.el6) X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk --=-CceyigBperngTM7sItG/ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 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 third." (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 design. 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, FORALL.) 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). --=-CceyigBperngTM7sItG/ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 2013-07-25 at 10:11 +0200, Tobias Burnus wrote:
On the other hand, implementing all the fea= tures suggested in N1970 will be a very large effort for compiler implement= ers

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

and I fear that it will also divert the att= ention of the committee from more pressing issues.

Support for units is proposed as a TS precisely so that it WILL NOT INTERFE= RE with the next revision's work plan!  If you take the trouble to loo= k at N1969, not just the necessarily superficial slides in N1970, you'll se= e that the project, as an ISO publication, is finished already.  I mad= e the point during the presentation in Delft that it has already had sevent= een rounds of off-line review since I began work on the document in its pre= sent form in 2009.  I have given the problem a great deal of thought s= ince 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 TIM= E 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 pr= ecisely how development of a TS should proceed, although not on a decades-l= ong schedule.  My opinion is that we could finish it by saying "O= K, let's do it," have a letter ballot, and send it to ISO for publicat= ion.

What "more pressing issues" would be displaced by units from the = next revision's work plan? (!!!)  N1982, appended below, is a collecti= on of vapid trivialities!  For example, US-12 requires deleting "= SIZE=3D" at two places and "nonadvancing" at one place -- an= d that's a complete work item, over which J3 agonized twice and WG5 once!&n= bsp; 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&qu= ot; instead of cannonball polishing.

We have chosen such a meaningless revision because a more ambitious one cou= ldn't be done on the schedule we have, but the problem of meeting the sched= ule 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 m= ember 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 manag= ed to find eight years to piss away (I can't think of a more polite but sti= ll accurate description) on a pointless favor for WG23, which material shou= ld have been in textbooks, not an international standard, but we couldn't f= ind time to do anything to increase reliability of Fortran programs by deve= loping 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 program= ming and C interoprability were tackled as technical specifications that ha= d independent schedules and a different project editor, precisely so that t= hey would NOT INTERFERE with the work plan for further development of the s= tandard proper -- but there was no work on further development of the stand= ard proper being done at that time!

Perhaps you're thinking of TS 18508, concerning further coarray parallel pr= ogramming features?  The experience at Delft demonstrated that this pr= oject is not ready for prime time.  Much more thought (and corresponde= nce) needs to be put into this before it appears again at J3 or WG5 meeting= s.  We should not be developing major facets of it in subgroup, on Thu= rsday at a meeting, and then voting it into stone at the next meeting, or w= orse, 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 issu= es" in Fortran 2003.  Much more could also be done by e-mail betw= een 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 pa= rameterized derived types, coarrays, submodules, and new interoperability f= eatures.  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 conc= entrate their efforts.

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

That came from software development notebooks in the 1970's.  It was t= he reason for proposing a system of units during the requirements phase for= what became Ada, at the "woodenman" stage, if I remember correct= ly.  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, fo= llowed by out-of-bounds array references, and then incorrect use of physica= l units of measure. Explicit interfaces largely solve the first problem and= help to avoid the second problem, but do nothing directly for the third.&q= uot;

(my emphasis here).

With the software I had to do with, "&= lt;" instead of ">", missing terms, wrong signs and simil= ar issues seem to play a much larger role than units. - More common than th= ose are of course out of bounds, uninitialized variables and other such pro= blems.

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

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 t= he same named subrange, there can be no bounds violation at the point of re= ference.  The only place that needs to be checked is where the subscri= pt variable gets its value assigned.  If it's an induction variable th= at 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-ti= me theorem that no bounds violation can occur.  I proposed something a= long these lines for Fortran.

PPS: At least two of the codes I used, have= internally atomic units (hbar =3D 1, electron charge =3D 1, Bohr radius = =3D 1, electron mass =3D1. As alpha has to remain at ~1/137 [unitless!], th= e speed of light c =3D 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 program= mers would move to your proposed units feature in those codes, if it were a= vailable.

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

One of the theorems of dimensional analysis is that if your problem has var= iables with M units, based upon N fundamental quantities, you can eliminate= at most M-N (composite or conversion) units.  So maybe you can elimin= ate 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 formu= lation wherein analogues of those quantities enter in an unitless manner, s= omewhere 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.&nbs= p; My university diploma says "system engineering."  I have = spent my entire career pondering entire problems, entire systems, not singl= e lines of code, single procedures, or even single programs.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

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

UK items (N1975):
  UK-02 (Specifiable default accessibility for USEd module's entities)
  UK-03 (RECL=3D 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, COM=
MON, label on block DO, specific intrinsics,
         FORALL.)

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=3D argument handling in intrinsics), see interp F=
08/0038.
  US-08 (Specify explicit specification of EXTERNAL attribute is requi=
red)
  US-12 (Allow SIZE=3D with advancing input)
  US-14 (Compatibility with ISO/IEC 60559:2010).

--=-CceyigBperngTM7sItG/--