Hi, Michael, I remember that you mentioned that you have to split some files into small pieces, would mind send us the split version? We will check them into SVN as split files. This would make it easier for you to move to the later versions when you need to.
John On 8/29/12 12:04 PM, Michael Beauregard wrote: > The strange thing is that the lower number is actually the correct > one. I suspect that this will require some concrete data for you to > understand what's happening. I'll see if I can get a simple dataset > for you that demonstrates the issue. > > Thanks, > > Michael > > On Wed, Aug 29, 2012 at 11:41 AM, K. John Wu <[email protected]> wrote: >> Hi, Michael, >> >> Glad to hear that you are making good progress. Regarding the >> off-by-one issue, here are a couple guesses on what could be going on. >> >> - The column named 'something' might have NULL values and one of the >> NULL values happen to be included in the result set. FastBit does not >> return any NULL values. >> >> - The retrieval function might have a bug. I would appreciate a >> sample data to track down this bug. >> >> Thanks. >> >> John >> >> >> On 8/29/12 11:18 AM, Michael Beauregard wrote: >>> Thanks to John, I'm making decent progress with integrating FastBit >>> into an iPad application. It builds and executes on my iPad and has >>> better size and speed metrics than sqlite. So far so good. >>> >>> During testing I noticed that a certain FastBit aggregation was off by >>> one compared to my sqlite result. Digging into a little, I noticed >>> something that appears odd to me, but could just be a misunderstanding >>> on my part. >>> >>> I would expect the aggregation result of the following query: >>> >>> ibis -d tmp/data -q 'SELECT count(*) WHERE thing_to_count = 16298' >>> >>> to match the number of hits returned by this query: >>> >>> ibis -d tmp/data -q 'SELECT something WHERE thing_to_count = 16298' >>> >>> However, I see that the two are off by one. The first query returns an >>> aggregated value of 1195 and the second returns 1194 hits. >>> Interestingly, for some reason the following query: >>> >>> ibis -d tmp/data -q 'SELECT thing_to_count WHERE thing_to_count = >>> 16298' >>> >>> returns 1195 hits. I would expect all three queries to indicate the >>> same number of matching rows since the conditions are exactly the >>> same. For what it's worth, my sqlite result is 1194 and I'd consider >>> that to be correct for my data. >>> >>> Any ideas? >>> >>> Michael >>> _______________________________________________ >>> FastBit-users mailing list >>> [email protected] >>> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users >>> _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
