Type promotion/checking in max()

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Type promotion/checking in max()

frans.englich (Bugzilla)

I think I've found some bugs in Saxon's implementation of the min/max
functions:

The following functions should fail to compile(type error):

        max(QName("example.org/", "ncname"))
        max(xs:anyURI("example.org/"))
        min(QName("example.org/", "ncname"))
        min(xs:anyURI("example.org/"))

Otherwise the functions' behavior is changed, they would return value of types
other than those allowed. The xs:anyURI is an invalid type because no
promotion to xs:string is triggered(it's not specified, and the function
conversion rules doesn't do it since the argument type is xdt:anyAtomicType).

Also, I think there are bugs in type promotion, the following should evaluate
to true, but do not:

max((3.0e0, 5)) instance of xs:double
max((5, 5.0e0)) instance of xs:double

It's a funny bug; `max((xs:double(5.0e0), 5)) instance of xs:double' works
fine, so it looks like if some wrong AST-rewrite is done at some point.
However, `5.0e0 instance of xs:double' evaluates to true, as expected.

This might exercise different parts(currently evals to false):

max((xs:double("NaN"), xs:float("NaN"))) instance of xs:double

Here are some more tests, for those interested:

max((5, 3.0e0)) instance of xs:double
max((5, 3.0e0)) eq 5
max((5.0e0, 5)) instance of xs:double
max((5.0e0, 5)) eq 5
min((5, 5.0e0)) instance of xs:double
min((5, 5.0e0)) eq 5
min((5.0e0, 5)) instance of xs:double
min((5.0e0, 5)) eq 5
max((3.0e0, 5)) instance of xs:double
max((3.0e0, 5)) eq 5
max((xs:float("NaN"), xs:double("NaN"))) instance of xs:double

(I do think the numeric promotion rules for min/max are cumbersome. That
comparison requires numeric promotion is understandable, but things would be
a lot simpler if one didn't have to return numerics promoted to what the
input sequence contained.)


Cheers,

                Frans


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

RE: Type promotion/checking in max()

Michael Kay
> The following functions should fail to compile(type error):
>
> max(QName("example.org/", "ncname"))
> max(xs:anyURI("example.org/"))
> min(QName("example.org/", "ncname"))
> min(xs:anyURI("example.org/"))

These should fail with a type error, but it's permitted to raise the type
error dynamically. Saxon will often report type errors that violate the
function signature at compile time, but the function signature of min/max is
very wide.

> The xs:anyURI is an invalid type because no
> promotion to xs:string is triggered(it's not specified, and
> the function
> conversion rules doesn't do it since the argument type is
> xdt:anyAtomicType).

Yes, I agree that one should probably throw FORG0006.
>
> Also, I think there are bugs in type promotion, the following
> should evaluate
> to true, but do not:
>
> max((3.0e0, 5)) instance of xs:double
> max((5, 5.0e0)) instance of xs:double

Actually this isn't a bug. Saxon 8.5.1 implements the April 2005 draft, in
which this was the correct behavior. But I hadn't noticed the change, so
thanks for alerting me to it. I don't know why the change was made, and it
doesn't seem to be mentioned in the change log.
>
> It's a funny bug; `max((xs:double(5.0e0), 5)) instance of
> xs:double' works
> fine

That's because it's returning the first item in the sequence unchanged.

> so it looks like if some wrong AST-rewrite is done at
> some point.

No, there's no rewriting done here: it's all handled dynamically.

> However, `5.0e0 instance of xs:double' evaluates to true, as expected.
>
> This might exercise different parts(currently evals to false):
>
> max((xs:double("NaN"), xs:float("NaN"))) instance of xs:double
>
> Here are some more tests, for those interested:
>
> (I do think the numeric promotion rules for min/max are
> cumbersome. That
> comparison requires numeric promotion is understandable, but
> things would be
> a lot simpler if one didn't have to return numerics promoted
> to what the
> input sequence contained.)
>

I agree! This changed between the April and September 2005 drafts, and I
hadn't registered the change.

Michael Kay




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help