[Mulgara-dev] trouble with doubles

David Smith DMS at viewpointusa.com
Tue Aug 5 13:48:17 UTC 2008


Got it, thanks 

-----Original Message-----
From: mulgara-dev-bounces at mulgara.org
[mailto:mulgara-dev-bounces at mulgara.org] On Behalf Of Alex Hall
Sent: Monday, August 04, 2008 3:54 PM
To: Mulgara Developers
Subject: Re: [Mulgara-dev] trouble with doubles

David Smith wrote:
> Thanks for looking at this.
> 
> 1) As far as the patch, I get what you're saying, but was simply 
> trying to fix the specific problems.

Understood.  That comment was targeted mostly at other developers on the
list. 
I don't see any harm in applying the patch that you attached to fix
ordering (assuming it passes the tests) but I wanted to first get input
from other developers.  If we're taking the wrong approach to ordering,
then I would rather do things the right way than fix a misguided
implementation.

This also brings another issue to mind.  Now that we support SPARQL, the
ordering imposed by the OrderByRowComparator should really be ordering
rows based on the ordering imposed by SPARQL.  I believe that SPARQL
defines at least a partial ordering of RDF terms, and I'm not sure if
TQL's existing ordering complies with this.  Paul, any comments here?

> 2) BTW, the "Query Error" also occurs with a literal "0", not just 
> negative numbers (could still be the Double.Min)
> 
> Thanks for the hint... 
> 
> The fix is to change the MIN_VALUE and MAX_VALUE to 
> NEGATIVE_INFINITY/POSITIVE_INFINITY in 
> IntervalConstraintDescriptor.java "resolve" method. Double.MIN_VALUE 
> is the smallest positive number that can be represented (ie 2-1074)

Good catch.  I've applied and committed your patch.

> What I'm not sure of, is how does this fix the QUERYERROR I was
getting?

The in-memory stringpool is backed by a java.util.SortedSet, and the
stringpool slicing operation ultimately causes a call to
SortedSet.subset(fromElement, toElement).  In this case, subset() was
being called with fromElement = Double.MIN_VALUE and toElement = -1 (or
0).  This method throws an IllegalArgumentException if fromElement >
toElement.

> 3) I understand the issues with the different datatypes, but would 
> suggest it needs to be type agnostic (at least among numerics and
> date/times)

It's mainly a question of which implementation is most efficient to
implement. 
If we want to support type-agnostic comparisons among numerics and
date/times, that would require globalizing individual terms and
interpreting their lexical values.  This is an expensive operation, and
one that we try to avoid making during query evaluation whenever
possible.  Getting a stringpool range, on the other hand, allows us to
stay in local space and is much more efficient.  If you want
type-agnostic comparisons, you're better served following Paul's
suggestion of using a SPARQL filter.  This defers globalizing the nodes
until after the query evaluation is complete, which is the proper place
to do that work.

Regards,
Alex
_______________________________________________
Mulgara-dev mailing list
Mulgara-dev at mulgara.org
http://mulgara.org/mailman/listinfo/mulgara-dev



More information about the Mulgara-dev mailing list