ON further consideration, perhaps sizeEstimate could return a Numeric Literal Node. This would provide the ability to return very large numbers as doubles and smaller numbers as ints and we already have the code to convert those values to primitive numbers or Number instances.
On Wed, Nov 6, 2013 at 7:32 AM, Claude Warren <[email protected]> wrote: > I don't see how to transition unless we change the method name to > something like sizeEstimate and return a double. I think in most cases > size is used to determine which side of a join should go on the left for > efficiency and for unit tests. We might want to return a statistical > answer X +/- Y (sort of like the delta in the junit > assert.equals(double,double,delta) tests ) But this is probably stretching > a bit too far. > > Claude > > > On Tue, Nov 5, 2013 at 10:28 PM, Andy Seaborne <[email protected]> wrote: > >> On 04/11/13 12:22, Claude Warren wrote: >> >>> Currently graph.size() returns an int. the maximum value for an int >>> is 2,147,483,647 (2.1 billion) though the model.size() returns a long. >>> >>> Does it make sense to change the return type for graph.size() to long? >>> >>> If not and a graph exceeds 2.1B triples should size just return >>> Integer.MAX_VALUE. >>> >>> I ask as I am currently working on a project to load all of DBPedia (2.46 >>> billion triples) into a graph. >>> >>> Claude >>> >>> >> Good idea. >> >> How would you see the change being made? (any transition process?) >> >> Andy >> >> > > > -- > I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
