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
