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
