Weird parsing difference

[Claude Warren <cl...@xenei.com>]

If I use an ARQParser to parse the string "?x < 10"
I get an E_LessThan object with the expected var and and XMLSchema#integer

If I use NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral(
10 )) I get the XMLSchema#int.

This means that the following fails
{noformat}
E_LessThan lt1 = new E_LessThan( new ExprVar(Var.alloc( "x" )),
NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral( 10 ));
E_LessThan lt2 = ARQParser.parse( "?x < 10" )

ElementFilter ef1 = new ElementFilter( lt1 );
ElementFilter ef2 = new ElementFilter( lt2 );

assertTrue( ef1.equalTo( ef2 ) );
{noformat}

It fails because ElementFilter.equalTo executes lt1.equalsBySyntax( lt2 )
and by syntax they are different.  Even though they will return the same
results for any set of data.

Should E_LessThan and other similar functions do something more akin to the
NodeValue.compare() to determine if the functions are equal?

I'm not sure what a good solution would be here but I think this is a
problem.

comments?

Claude






Now this doesn't make a difference during evaluation as they both evaluate
as BitInteger.  However, when comparing the


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Weird parsing difference

[Andy Seaborne <an...@apache.org>]

On 02/07/2021 15:36, Claude Warren wrote:
> If I use an ARQParser to parse the string "?x < 10"
> I get an E_LessThan object with the expected var and and XMLSchema#integer
> 
> If I use NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral(
> 10 )) I get the XMLSchema#int.
> 
> This means that the following fails
> {noformat}
> E_LessThan lt1 = new E_LessThan( new ExprVar(Var.alloc( "x" )),
> NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral( 10 ));
> E_LessThan lt2 = ARQParser.parse( "?x < 10" )
> 
> ElementFilter ef1 = new ElementFilter( lt1 );
> ElementFilter ef2 = new ElementFilter( lt2 );
> 
> assertTrue( ef1.equalTo( ef2 ) );
> {noformat}

because equalTo is "same term" - syntactic appearance.

"+10"^^xsd:int is different again.

> It fails because ElementFilter.equalTo executes lt1.equalsBySyntax( lt2 )
> and by syntax they are different.  Even though they will return the same
> results for any set of data.

So do a lot of other forms:
"10"^^xsd:decimal
"+10"^^xsd:int
"10e0"^^xsd:double

which are different terms but same value.

While this example comparison is the same for any data, other 
expressions are not because of overflow.


> Should E_LessThan and other similar functions do something more akin to the
> NodeValue.compare() to determine if the functions are equal?

ElementFilter records what was written. The syntax.

ARQ also prints Elements (the AST) out when doing Query.toString, 
preserving the original input.


> 
> I'm not sure what a good solution would be here but I think this is a
> problem.
> 
> comments?

Don't use

   LiteralLabelFactory.createTypedLiteral( 10 )

use

   LiteralLabelFactory.create( String lex, RDFDatatype dtype)

or better yet use NodeFactory.

10 - unquoted in SPARQL is defined to be "10"^^xsd:integer

LiteralLabelFactory.createTypedLiteral( Object ) is concerned with 
mapping between java values and RDF terms.

int 10 Java is a 32 bit signed quantity
It is closest match to xsd:int

If you had uses 10L you get xsd:long.
If you had uses 10.0 you get xsd:double not xsd:decimal.

     Andy

> 
> Claude
> 
> 
> 
> 
> 
> 
> Now this doesn't make a difference during evaluation as they both evaluate
> as BitInteger.  However, when comparing the
> 
>