[jsdl-wg] (Param Sweep) - Stephen Pickles' public comment

[geoff]

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/ParameterSweepExtensionUseCases 
)

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