February 2009 - jsdl-wg - lists.ogf.org

(param sweep) Updated draft document
by geoff 28 Feb '09

28 Feb '09

Hi all, Following modifications by Donal and myself the updated draft document is available at http://forge.ogf.org/sf/go/doc14595 gef

1 0

JSDL Teleconference - 25 February 2009 **@1pm UTC**
by Andreas Savva 27 Feb '09

27 Feb '09

Agenda: 1. Agenda bashing & quick status update - Confirm OGF25 session content 2. Parameter sweep public comments discussion (cont.) - Confirm issue resolution and text review http://www.ogf.org/pipermail/jsdl-wg/2009-February/001175.html - Public comments: http://www.ogf.org/gf/docs/comment.php?id=282 3. Activity instance document schema - Review draft http://www.ogf.org/pipermail/jsdl-wg/2009-February/001171.html ===== Full call-in details ==== Date: 25 February 2009 Time: UTC 1 PM EUROPE: GMT 1 PM / CET 2 PM US: EST 8 AM ASIA: JST 10 PM Duration: 1 hour Dial-in numbers (toll): US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 207 3655269 (London) Germany: +49 (0)69 50070802 (Frankfurt) Japan: +81 3 3570 8225 (Tokyo) Other countries: http://tinyurl.com/eg48j User guide: http://tinyurl.com/qknrf Teleconference participant PIN: 4371991 Screen share: http://jsdl.glance.net/?key=0225 Note: When you dial in after the initial message in English for the PIN there is another message in Japanese only (sorry) to state your name and press '#' in order to join the call. -- Andreas Savva Fujitsu Laboratories Ltd

2 1

(Param sweep) Proposed updated looping text
by geoff 23 Feb '09

23 Feb '09

Hi all, In addition to the other requested specification modifications ("lay dog"s and XPath 1+2) please take a look at the proposed looping modifications. Frustratingly one issue still remains: Dave Meredith has raised the prospect of problems if we advise the use of ranges when performing LoopDouble Exception comparison as effectively it's a green light for inconsistency across implementations (and in some respects mismatching/inaccuracy). As we're strongly recommending the adoption of the IEEE 754 standard decimal floating point arithmetic in implementations I think that this should provide the expected consistency (even if it's consistent inaccuracy!?) without the need for ranges. Alternatively a reversal on my earlier hesitation in the adoption of the jsdl:RangeValue_Type may be required, e.g. > <sweepfunc:LoopDouble substitutes=”sweep:Function” > start=”xsd:double” > end=”xsd:double” > step=”xsd:double” > > <sweepfunc:Exception> jsdl:RangeValue_Type </sweepfunc:Exception>* > </sweepfunc:LoopDouble> gef ------------------------------------------ 4.2 LoopInteger function The LoopInteger function provides an ordered list of integer values within the inclusive range specified by the start and end values. The list begins at the start value and contains all subsequent rangebound incremented or decremented values as determined by the step value. A LoopInteger function MAY exclude certain values by including Exception Child elements. This function yields values that are calculated as follows. The first value equals the value of the start value. Any subsequent value is calculated using the following rule: nextValue ::= currentValue + valueOf( step ) If “nextValue” is beyond the range boundary specified by the end value, then “nextValue” is discarded and the LoopInteger function terminates with “currentValue”. If a value for “step” is not given, the default value of “1” MUST be used. ... [unmodified] Implementations handling the LoopInteger function may choose to : - Where possible, predetermine and validate the loop cardinality by inspection prior to running the loop operation, and confirm cardinality post-operation. - Respond appropriately if schematically valid yet questionable values are supplied, e.g. if the value 0 is encountered for step. ... [unmodified] 4.3 LoopDouble function The LoopDouble function provides an ordered list of double datatype values (corresponding to the IEEE double-precision 64-bit floating point type) within the inclusive range specified by the start and end values. The list begins at the start value and contains all subsequent rangebound incremented or decremented values as determined by the step value. ... [unmodified] The permissible value range... ....The following are therefore considered valid xsd:double values : -1E4, 1267.43233E12, 12.78e-2, 12, NaN, -0 and INF . Please note (accuracy advice): The reference to xsd:double datatype values (and double-precision 64-bit floating point types) is solely for the definition of the valid value range and format acceptable in LoopDouble functions. Implementations which process such values should have functionality that most accurately interprets and operates on such a value range and format, e.g. it is strongly recommend that implementations support IEEE 754 standard [1] decimal (base 10) floating point arithmetic, in preference to binary (base 2) arithmetic. Implementations handling the LoopDouble function may choose to : - Where possible, predetermine and validate the loop cardinality by inspection prior to running the loop operation, and confirm cardinality post-operation. - Convert xsd:double datatype values to integer values and implement only integer arithmetic processing. - Determine an acceptable range when comparing equality of a particular loop value against loop Exception values, e.g. an exception may be affirmed if a loop Exception value is within a % range of the loop value. - Encourage consistency in value format, e.g. avoid mixing scientific and non-scientific nomenclature in a LoopDouble element. - Respond appropriately should schematically valid yet questionable values such as NaN, -0, INF, -INF be encountered. Footer note: [1] IEEE 754 - 2008 http://ieeexplore.ieee.org/servlet/opac?punumber=4610933

1 0

LoopDouble comments
by Donal K. Fellows 19 Feb '09

19 Feb '09

This is a follow-up to a discussion had on the recent JSDL call w.r.t. the LoopDouble comments from the parameter sweep public comment period. As I see it, there are two key challenges with LoopDouble (above and beyond those of LoopInteger): 1) Accuracy of computed values 2) Format of computed values (this wasn't discussed; I only thought of it since) The first is an issue because it can lead to a different number of iteration steps, and it stems primarily from the fact that decimal fractions are not all exactly representable in binary arithmetic. The way to fix this is to compute the number of steps to use (probably by dividing the range by the step and rounding appropriately) and to then use integer iteration behind the scenes with an appropriate (trivial) function to convert to the floating-point values. The advantage of doing this is that it does not require the use of fancy things like decimal arithmetic packages, which are not at all universally available; while Java might have one, I'd hate to have to mandate the use of Java to process JSDL documents! IEEE double precision binary floating point arithmetic is much more common (i.e. virtually universal in hardware now). In other words, this can be fixed without schema changes. Of more of an issue is the fact that LoopDouble does not specify how to format the numbers. That is, when it wants to generate the number half way between 0.0 and 1.0, should it actually generate the string 0.5 or 0.50 or 0.500 or 5e-1 or 500e-3 or ...? You can't use the format of the arguments since XML processors that map to an object model based on the infoset won't retain the format used but will instead focus on the logical value. (And anyway, the formats could also be inconsistent...) Either we need to specify something that is "good enough" for most uses (e.g. "a maximum of 14 significant figures, but with pointless trailing zeroes stripped so long as there is at least one digit after the decimal point; no use of scientific notation") or we need to change the schema to provide control. Looking through the Stephen's public comment, I see that he's worried about Exception values. They're not actually an issue because we know what the step is and can therefore calculate a sensible epsilon for the "equality" test (e.g. 1% of the magnitude of the step). Perhaps the spec should make some mention of this to make implementors aware of the subtleties involved. Donal.

2 2

Teleconference minutes and schedule
by Andreas Savva 19 Feb '09

19 Feb '09

Minutes from recent calls uploaded to gridforge: - Jan 28, 2009: https://forge.gridforum.org/sf/go/doc15489 - Feb 18, 2009: https://forge.gridforum.org/sf/go/doc15490 Next call is Feb 25, to discuss/finalize the parameter sweep public comment resolution and review the activity instance draft. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

JSDL Teleconference - 18 February 2009 **@1pm UTC**
by Andreas Savva 18 Feb '09

18 Feb '09

Agenda: 1. Agenda bashing & quick status update - Confirm OGF25 session content 2. Parameter sweep public comments discussion (cont.) Close major issue(s) starting with thread http://www.ogf.org/pipermail/jsdl-wg/2009-January/001148.html and http://www.ogf.org/pipermail/jsdl-wg/2009-January/001164.html Other public comments http://www.ogf.org/gf/docs/comment.php?id=282 3. Activity instance document schema ===== Full call-in details ==== Date: 18 February 2009 Time: UTC 1 PM EUROPE: GMT 1 PM / CET 2 PM US: EST 8 AM ASIA: JST 10 PM Duration: 1 hour Dial-in numbers (toll): US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 207 3655269 (London) Germany: +49 (0)69 50070802 (Frankfurt) Japan: +81 3 3570 8225 (Tokyo) Other countries: http://tinyurl.com/eg48j User guide: http://tinyurl.com/qknrf Teleconference participant PIN: 4371991 Screen share: http://jsdl.glance.net/?key=0218 Note: When you dial in after the initial message in English for the PIN there is another message in Japanese only (sorry) to state your name and press '#' in order to join the call. -- Andreas Savva Fujitsu Laboratories Ltd

2 1

JSDL Generation Tool Available
by Mark Morgan 08 Feb '09

08 Feb '09

I have just completed a project which Andrew and I thought might be of interest to some of you. We are now supporting an application we call JSDLTool which aids users in creating new JSDL documents for certain types of applications and which can be used to create a series of JSDL files for an application in a parameter sweep scenario. Those keeping up with the mailing list regarding the OGF work on parameter sweeps will notice that our method of dealing with Parameter Sweeps is quite different and this stems largely from the fact that we've been doing parameter sweeps in Genesis II since nearly the beginning of the project's lifetime. As the standards work with parameter sweeps moves forward this tool may be retrofitted to support the new standard as well. In the meantime, this tool produces a batch of jsdl files, one each for each instantiation of the application inside of the parameter space. Any one interested in the application can find information about it as well as links for source code, documentation, and the application itself at http://www.cs.virginia.edu/~vcgr/wiki/index.php/JSDLTool -Mark

4 4