[Bug 2456] Changes to min() and max()

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2456





------- Additional Comments From mike@saxonica.com  2006-01-10 14:28 -------
I've been thinking more about this, and beyond my original reasons given in
comment #2, I think there are further reasons why the original spec is better.
For example, consider max(($DEC, $FLT, $DBL)) where $DEC > $FLT and $DEC < $DBL.
Can I get the right result in a pipelined implementation? According to the spec,
all the values need to be converted to doubles before any comparisons are done.
If we try to pipeline this, there's a danger of getting the wrong answer. If I
start by comparing ($DEC, $FLT) by converting $DEC to float, I risk hitting a
boundary case where the result of converting $DEC to float is greater than $DBL
even though $DEC itself is less than $DBL (this includes the case where
float($DBL) is +INF). 

I can avoid these errors by retaining $DEC (the original value) as the value of
"max so far", and at the same time keeping track of the "highest type
enountered", and at the end converting the "max so far" to the "highest type
encountered". But it's extra work, and all it achieves is to give a poorer
result (one that loses precision). I think it's better for the user, and easier
for the implementor, if the result is always one of the numeric values actually
present in the sequence: "max so far" without further conversion.

Michael Rys' argument seems to be based on the ability to reuse implementations
that exist in other environments. It seems to me unlikely that such
implementations would accept streamed input in the right form, and therefore
unlikely that a high-performance XQuery implementation would choose to use them.
But perhaps he is relying on the ability of static analysis to determine the
target type in advance. Unfortunately we don't all have that luxury.

Received on Tuesday, 10 January 2006 14:28:35 UTC