(j3.2006) (SC22WG5.5745) Units of measure

Tom Clune Thomas.L.Clune
Sun Jul 3 11:30:23 EDT 2016


Staying out of the main fray, but I?ll make the case for ?slowing the pace? of the standard.

The problem is not so much that the F2003 features were large/difficult to implement, though they certainly were.      Rather the problem was that different vendors (justifiably) chose to implement differing features first.   This meant that users who required some degree of portability could not properly exercise the implementations until we were fairly far down the path of full-implementation.    A smaller bite would have focused the vendors on a common set of features which would have thereby enabled end-users to have to provide more immediate feedback.

As a different part of this thread points out:  when F2003 was ratified there was enough support for PDT?s and DTIO to be placed in the standard.     Surely they are still on some developers? lists of desired features, but quite possibly they would now fall low enough in priority that other features would be chosen in the standard.   

Because of these types of concerns (and by way of analogy with most modern software development approaches), a shorter  cycle would provide the greatest opportunity to ensure that the priority list is optimized across the Fortran community and implemented in time to make corrections in the subsequent standard.     The lower limit on the time scale for this cycle is determined by the processes of the committee itself for reliably incorporating an approved feature.      This would appear to be 2-3 years at the current pace of meetings.   Balancing that limit with the desire to have  a meaty enough set of features/improvements would make the current goal of 5 years seem reasonable.   (Would not oppose shorter cycles myself.)     

In short, if we (users) pack too much into a revision,  we are hurting ourselves.      Yes - I have a laundry list of things I?d like to see in the standard.   But the only way I see to enable a measurable change in the amount we can place in a single revision would be to have substantially more investment of time by committee members (more members, more meetings, longer meetings) _and_ by the vendors whose development process must impedance match the standards process.

Cheers,

- Tom





> On Jul 2, 2016, at 4:20 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
> 
> I don't understand how the paragraph quoted from the ISO directives
> precludes the possibility of publishing a TS that does not promise to
> incorporate the feature in a future standard.  Not promising to
> incorporate is not the same as promising not to incorporate. 
> 
> Bill and others have argued that units support ought to be provided by a
> preprocessor, no matter how unpalatable that is, especially if one has
> several users and several developers of the software.  If a TS were
> published, at least preprocessor vendors could claim compliance to that,
> and would hopefully all provide the same features, in the same way.
> 
> I also don't understand the argument that we shouldn't be ambitious
> because vendors found some features of 2003 difficult to implement.  If
> we had postponed incorporating them until 2015, nobody would have given
> any thought to how to implement them until now, and they would thereby
> not be available until 2025.  I don't see any advantage in that.
> Indeed, it seems to be a distinct disadvantage.  I'm very pleased that
> 2003 features are becoming available now, instead of appearing ten years
> after my retirement.
> 
> I've spend my entire half-century career working in an organization
> whose motto is "Dare Mighty Things" so perhaps I can be forgiven for
> having more ambitions for Fortran than other members seem to have.
> 
> Reliability is extremely important to my organization.  We built two
> machines that have operated unattended in the harsh deep-space
> environment for forty years, and show all signs of lasting at least
> another decade.  We promised NASA that the Spirit and Opportunity rovers
> would last ninety days on Mars.  Opportunity is still working twelve
> years after landing.  The Spirit rover lasted "only" six years.
> Reliability doesn't come without great effort, and every tool to improve
> it is welcome.  Is reliability not important to anybody else, or is
> everybody who cares about it eager to achieve it without the best tools
> possible?
> 
> JPL is a Federally Funded Research and Development Center, operated by
> Caltech.  Unlike at least a few government civil-service organizations,
> JPL and Caltech are very careful with taxpayers' money, so labor cost is
> important to us.  Reliability doesn't come for free, and every tool that
> helps to reduce the cost of achieving it is welcome.  Is labor cost not
> important to anybody else?
> 
> On Sat, 2016-07-02 at 11:50 +0100, John Reid wrote:
>> WG5,
>> 
>> N.M. Maclaren wrote:
>>> On Jun 29 2016, Bill Long wrote:
>>>>> 
>>>>> Van asks
>>>>> 
>>>>> 2. Did you ask whether my offer to remove the promise to incorporate the
>>>>> specification into a future revision of the standard made a difference
>>>>> in their positions?
>>>>> 
>>>>> For all those that attended the London meeting, I would appreciate your
>>>>> thoughts on this.
>>>>> 
>>>>> I think I should perhaps add a paragraph on 2. I think the sentiment
>>>>> was that it would obviate the whole point of a TS - to define a feature
>>>>> that WG5 intended eventually to include in the standard.
>>>> 
>>>> I agree with John that this is the operational norm for WG5 and making an
>>>> exception here weakens the norm for other proposals.
>>> 
>>> While that is true, there were people who felt that using TSs solely for
>>> that purpose was a mistake.
>> 
>> We have to work within the ISO/IEC JTC 1 rules. The latest directives say
>> 
>> "When the subject in question is still under development or where for 
>> any other reason there is the future but not immediate possibility of an 
>> agreement to publish an International Standard, the technical committee 
>> or subcommittee may decide, by following the procedure set out in 2.3, 
>> that the publication of a Technical Specification would be appropriate."
>> 
>> I have added a paragraph that includes this quotation at the end. I have
>> also split the first paragraph to add a sentence explaining that this 
>> was proposed as a TS.
>> 
>> Does this document now give a fair summary of why we made the decision
>> in London?
>> 
>> John.
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3




More information about the J3 mailing list