I think, as you say, exact equality of signed and unsigned 64-bit integers is the only use case I am expecting. The addition of the explicit typing suffixes you describe would solve the problem. I'm not expecting to do very complicated queries or arithmetic operations on these values, as they represent hashed signature values in my application.
Stuart Castergine [email protected] M: 614-264-7986 O: 740-347-9300 ________________________________________ From: [email protected] [[email protected]] On Behalf Of K. John Wu [[email protected]] Sent: Wednesday, June 23, 2010 5:59 PM To: FastBit Users Subject: Re: [FastBit-users] ibis command line tool interpreting large integers as double causing == queries to fail Hi, Stuart, You are right that ardea correctly handles the 64-bit integers, however, the query processing is translating all numbers to 64-bit floating-point values, which truncates the 64-bit integers to 48-bit precision. However, this limitation is widely spread in the current version of FastBit code. It will take a major redesign to get rid off of this nasty little problem.. It would be possible to designate 64-bit integers in the query strings with special suffices such as LL and ULL, and allow such numbers in a small number of query expressions. We could implement some support for this. Do you anticipate of use cases other than "session_id == 5146415197860370806"? John On 5/27/2010 12:15 AM, Stuart Castergine wrote: > I have an index that includes values indexed (via ardea) as long. > > when querying using ibis for very large values, it looks like ibis is > interpreting the long integers in the query string as double precision, > causing them to faiil for exact integer matches. Here's an example: > > Note that the session_id 5146415197860370806 is confirmed to exist in the > data and is visible if you do range-based queries (such as session_id> 0). > > /opt/narus/fdm/default/software/site/bin/ibis -d test -q "select session_id > where session_id == 5146415197860370806" > doQuery:: evaluate(SELECT session_id FROM test WHERE session_id == > 5146415197860370806) produced 0 hit, took 0 CPU seconds, 0.146936 elapsed > seconds > If you run the query with verbosity 2 (-v=2), you see this: > > part::doScan -- evaluating session_id == 5.14642e+18 on 10 m values (total: > 1725 > 96) took 4.98295e-05 sec elapsed time and produced 0 hit > Which leads me to believe that the value is being converted to a > double-precision and is therefore unable to match the exact long integer. > > Is there a way in the query syntax to force ibis to treat the value as a long? > > Thanks, > > Stuart Castergine > [email protected]<mailto:[email protected]> > M: 614-264-7986 > O: 740-347-9300 > _______________________________________________ > 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 _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
