Hi all, I took a much closer look at Steve's input on the subject of looping through values ( http://www.ogf.org/gf/docs/comment.php?id=282 ) and, contrary to what I was saying in the teleconf yesterday (which was based on not having given it suitable forethought - big sorry! :( ), before proceding I have the following points relating to Steve's concerns : I'll use this convention throughout : Option (A) : start, step and end values (as per current spec.) Option (B) : start, step and loop count values (Steve's proposal) Point 1 : Following a very small survey on a few local users I received roughly equal preference for each option based on the following principles: Option (A) : Useful when ranges (e.g. physiological ranges) are known, so little or no concern for the number of loops to perform. As per examples ( http://forge.ogf.org/sf/wiki/do/viewPage/projects.jsdl-wg/wiki/ParameterSwee... ) Option (B) : Useful when a specific number of iterations are required, e.g. having 10 values to test. Note: There was some uncertainty, in that a loop count of "n" would generate "n+1" values, i.e, a loop count of 0 will still produce a single loop value! This would require clarification by documentation. Conclusion : We need to ensure that the specification doesn't prevent either of these options for job submission data entry. Point 2 : After reading up about Fortran the best official-looking (i.e. I'm not a Fortran user/expert) explanation I could find is : "3.2 Real & double precision DO variables This was a feature copied from Algol 60 to Fortran 77 at a time when there was a move to relax the strict type rules of Fortran 66. Subsequently it was realized by IFIP that it was a mistake in Algol and the feature did not appear in Algol 68. The problem is that because of the nature of real arithmetic it is not possible, without detailed knowledge of the arithmetic and implementation of a system, to predict the behaviour of a program using this feature. Thus use contradicts the first purpose of the standard, the promotion of portability of programs. Since this deficiency has been known for over twenty years, the feature has been relatively little used in Fortran and programs are readily convertible to use an integer control variable. Fortran should recognize that a mistake was made and the feature should now be deleted from the language." ( http://www.open-std.org/JTC1/SC22/WG5/436 ) Conclusion : Fortran, no doubt as many other programming languages, suffers from non-integer accuracy problems. IMHO though this should be considered a problem solely for implementors to resolve using their own solutions, but it should not however influence the determination of a specification by which grid users want to submit their jobs (i.e. our role). To emphasise the implementation-specific nature Java provides out-of-the-box ability to perform IEEE 754 standard ( http://en.wikipedia.org/wiki/IEEE_754 ), base 10 / decimal arithmetic by use of the BigDecimal class ( http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html ) (note: values of which should be initialised using string representations), which is considerably more accurate than Float or Double classes which use base 2 arithmetic. ( http://www.ddj.com/java/184405721 ) and could meet the accuracy needs of the vast majority of users. In another official-looking document I understand that Fortran has moved towards adopting decimal floating point arithmetic IEEE 754 ( http://grouper.ieee.org/groups/754/email/msg01921.html ) Point 3 : I believe that Option (A) delivers a stronger contract for accuracy by implementations by explicitly specifying three verifiable values, rather than Option (B) which provides just two, i.e. just start and step. Conclusion : Option (A) should take precedence over Option (B) as the former specifies a limit condition (and hence accuracy is explicit) whereas the latter doesn't. Point 4 : We must assume that the user is competent and accurate, although occasionally distracted. Conclusion : It's for implementors to worry about determining suitability of data entered. Overall conclusion: I feel we should stick 100% with the current specification and leave the ability to provide Option (B) input to interface implementations. I'd be very grateful for feedback to this email, particular from Steve Pickles, hence I've Cc'd him. Now that I've managed to document my concerns, and hopefully in a form which is more coherent (and with accessible references) than the views expressed during teleconfs, it'll be easier to see why I remain reluctant to change. Thanks, gef