Unexpected Casts

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

Unexpected Casts

sguthery
?x is "52200.0"^^xsd:float and ?y is "26000.0"^^xsd:float. If divide ?x by ?y using

swrlm:eval(?z, "(x / y)", ?x, ?y)

then ?z is "2.00769..."^^xsd:double which is the right answer except ?z has been cast to double.

If on the other hand, I try swrlb:divide(?z, ?x, ?y) then Java crashes with a non-terminating decimal exception.

1) I don't find a spec that says when the division of two floats yields a double rather than a float.  Yes, this is correct Java but swrlm seems to cast back to float sometimes and not at others; for example when ?z is an xsd:float, 

2) Even one argues that you get a double unless you say otherwise ( swrlb:divide(?z^^float, ?x, ?y)?), why is swrlb:divide casting to decimal than going directly to double like eval?

Thanks in advance for any insight.

Cheers, Scott

_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected Casts

Lorenz Buehmann
Hi

On 17.12.19 01:37, Scott Guthery wrote:
> ?x is "52200.0"^^xsd:float and ?y is "26000.0"^^xsd:float. If divide
> ?x by ?y using
>
> swrlm:eval(?z, "(x / y)", ?x, ?y)
>
> then ?z is "2.00769..."^^xsd:double which is the right answer except
> ?z has been cast to double.

that would be a bug if it would be swrlb:divide because the SWRL the
specs are based on XPath operators the corresponding function
op:numeric-divide [1]  is clearly defined to return xsd:float in that
case [2]. For mixed arguments, type promotion [3] would be applied, so
the large datatype would be used iirc

But you're using swrlm:eval here, which is not part of SWRL specs. It's
just an extension from SWRLAPI. You could ask Martin why this happens, I
guess it's more accidentally and not intended if both operands do have
the same datatype.

>
> If on the other hand, I try swrlb:divide(?z, ?x, ?y) then Java crashes
> with a non-terminating decimal exception.
That must be a bug then. Here is still an open ticket [4]


[1] https://www.w3.org/TR/xpath-functions/#func-numeric-divide
[2] https://www.w3.org/TR/xpath-functions/#op.numeric
[3] https://www.w3.org/TR/xpath-31/#promotion
[4] https://github.com/protegeproject/swrlapi/issues/39


_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected Casts

sguthery
SWRLBuiltInLibrary in the swrlapi repo does this:

    } else if (builtInName.equalsIgnoreCase(SWRLB_DIVIDE)) {
      BigDecimal argument2 = getArgumentAsADecimal(1, arguments);
      BigDecimal argument3 = getArgumentAsADecimal(2, arguments);
      operationResult = argument2.divide(argument3);

StackOverflow suggests a couple of ways to avoid the exception:


Since this is such basic code (as well as acknowledging that I am no Java guru) I'm reluctant to make or even suggest any changes but it would seem a fix is within reach.  One can, of course, always patch one's local version.

Cheers, Scott

On Tue, Dec 17, 2019 at 2:29 AM Lorenz Buehmann <[hidden email]> wrote:
Hi

On 17.12.19 01:37, Scott Guthery wrote:
> ?x is "52200.0"^^xsd:float and ?y is "26000.0"^^xsd:float. If divide
> ?x by ?y using
>
> swrlm:eval(?z, "(x / y)", ?x, ?y)
>
> then ?z is "2.00769..."^^xsd:double which is the right answer except
> ?z has been cast to double.

that would be a bug if it would be swrlb:divide because the SWRL the
specs are based on XPath operators the corresponding function
op:numeric-divide [1]  is clearly defined to return xsd:float in that
case [2]. For mixed arguments, type promotion [3] would be applied, so
the large datatype would be used iirc

But you're using swrlm:eval here, which is not part of SWRL specs. It's
just an extension from SWRLAPI. You could ask Martin why this happens, I
guess it's more accidentally and not intended if both operands do have
the same datatype.

>
> If on the other hand, I try swrlb:divide(?z, ?x, ?y) then Java crashes
> with a non-terminating decimal exception.
That must be a bug then. Here is still an open ticket [4]


[1] https://www.w3.org/TR/xpath-functions/#func-numeric-divide
[2] https://www.w3.org/TR/xpath-functions/#op.numeric
[3] https://www.w3.org/TR/xpath-31/#promotion
[4] https://github.com/protegeproject/swrlapi/issues/39


_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev

_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected Casts

sguthery
"One can, of course, always patch one's local version."

Famous last words!

Compiling 277 source files to C:\Users\s_gut\Desktop\Protege\plugins\swrlapi\target\classes
An exception has occurred in the compiler (13.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError: Could not find exception index for type annotation @org.checkerframework.checker.nullness.qual.NonNull on exception parameter

On Tue, Dec 17, 2019 at 8:07 AM Scott Guthery <[hidden email]> wrote:
SWRLBuiltInLibrary in the swrlapi repo does this:

    } else if (builtInName.equalsIgnoreCase(SWRLB_DIVIDE)) {
      BigDecimal argument2 = getArgumentAsADecimal(1, arguments);
      BigDecimal argument3 = getArgumentAsADecimal(2, arguments);
      operationResult = argument2.divide(argument3);

StackOverflow suggests a couple of ways to avoid the exception:


Since this is such basic code (as well as acknowledging that I am no Java guru) I'm reluctant to make or even suggest any changes but it would seem a fix is within reach.  One can, of course, always patch one's local version.

Cheers, Scott

On Tue, Dec 17, 2019 at 2:29 AM Lorenz Buehmann <[hidden email]> wrote:
Hi

On 17.12.19 01:37, Scott Guthery wrote:
> ?x is "52200.0"^^xsd:float and ?y is "26000.0"^^xsd:float. If divide
> ?x by ?y using
>
> swrlm:eval(?z, "(x / y)", ?x, ?y)
>
> then ?z is "2.00769..."^^xsd:double which is the right answer except
> ?z has been cast to double.

that would be a bug if it would be swrlb:divide because the SWRL the
specs are based on XPath operators the corresponding function
op:numeric-divide [1]  is clearly defined to return xsd:float in that
case [2]. For mixed arguments, type promotion [3] would be applied, so
the large datatype would be used iirc

But you're using swrlm:eval here, which is not part of SWRL specs. It's
just an extension from SWRLAPI. You could ask Martin why this happens, I
guess it's more accidentally and not intended if both operands do have
the same datatype.

>
> If on the other hand, I try swrlb:divide(?z, ?x, ?y) then Java crashes
> with a non-terminating decimal exception.
That must be a bug then. Here is still an open ticket [4]


[1] https://www.w3.org/TR/xpath-functions/#func-numeric-divide
[2] https://www.w3.org/TR/xpath-functions/#op.numeric
[3] https://www.w3.org/TR/xpath-31/#promotion
[4] https://github.com/protegeproject/swrlapi/issues/39


_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev

_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected Casts

Martin O'Connor-2
I’ll take a look at this today and will hopefully get a new release out with the fix.

Martin

On Dec 17, 2019, at 5:14 AM, Scott Guthery <[hidden email]> wrote:

"One can, of course, always patch one's local version."

Famous last words!

Compiling 277 source files to C:\Users\s_gut\Desktop\Protege\plugins\swrlapi\target\classes
An exception has occurred in the compiler (13.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError: Could not find exception index for type annotation @org.checkerframework.checker.nullness.qual.NonNull on exception parameter

On Tue, Dec 17, 2019 at 8:07 AM Scott Guthery <[hidden email]> wrote:
SWRLBuiltInLibrary in the swrlapi repo does this:

    } else if (builtInName.equalsIgnoreCase(SWRLB_DIVIDE)) {
      BigDecimal argument2 = getArgumentAsADecimal(1, arguments);
      BigDecimal argument3 = getArgumentAsADecimal(2, arguments);
      operationResult = argument2.divide(argument3);

StackOverflow suggests a couple of ways to avoid the exception:


Since this is such basic code (as well as acknowledging that I am no Java guru) I'm reluctant to make or even suggest any changes but it would seem a fix is within reach.  One can, of course, always patch one's local version.

Cheers, Scott

On Tue, Dec 17, 2019 at 2:29 AM Lorenz Buehmann <[hidden email]> wrote:
Hi

On 17.12.19 01:37, Scott Guthery wrote:
> ?x is "52200.0"^^xsd:float and ?y is "26000.0"^^xsd:float. If divide
> ?x by ?y using
>
> swrlm:eval(?z, "(x / y)", ?x, ?y)
>
> then ?z is "2.00769..."^^xsd:double which is the right answer except
> ?z has been cast to double.

that would be a bug if it would be swrlb:divide because the SWRL the
specs are based on XPath operators the corresponding function
op:numeric-divide [1]  is clearly defined to return xsd:float in that
case [2]. For mixed arguments, type promotion [3] would be applied, so
the large datatype would be used iirc

But you're using swrlm:eval here, which is not part of SWRL specs. It's
just an extension from SWRLAPI. You could ask Martin why this happens, I
guess it's more accidentally and not intended if both operands do have
the same datatype.

>
> If on the other hand, I try swrlb:divide(?z, ?x, ?y) then Java crashes
> with a non-terminating decimal exception.
That must be a bug then. Here is still an open ticket [4]


[1] https://www.w3.org/TR/xpath-functions/#func-numeric-divide
[2] https://www.w3.org/TR/xpath-functions/#op.numeric
[3] https://www.w3.org/TR/xpath-31/#promotion
[4] https://github.com/protegeproject/swrlapi/issues/39


_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev
_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev


_______________________________________________
protege-dev mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-dev