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.
