The next version of Sqlite will very likely support 64 bit integers as RTree values. Would that solve your problems? http://www.sqlite.org/src/info/02b7640f51 -- Jos Groot Lipman
> -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Shish > Sent: maandag 23 april 2012 19:37 > To: sqlite-users@sqlite.org > Subject: [sqlite] rtree value rounding > > The rtree docs say that as well as 2D geometry, it could be > used to index ranges of time - this is what I'm doing, but > I've found a problem and workaround: > > It seems that the indexed values are stored as a small > floating-point value, and thus large numbers (for example, > the current timestamp as seconds since 1970) will be > approximated. The date right now, for example (1335201433) is > rounded to the nearest 128 seconds, where I need accuracy to > thousandths of a second. Once I'd realised what was > happening, the workaround was to store the date of the first > sample in a different table, and then index the offset from > that date. Having to subtract and re-add the offset every > time I'm looking up indexed data is annoying, but nothing fatal. > > If a larger float could be stored without breaking speed and > compatibility, that would be good; if not, could the docs at > least point out that while rtree indexes are generally > suitable for time ranges, they aren't suitable for > high-precision-seconds-since-epoch > time ranges? (Listing all the things a bit of software isn't > suitable for would be silly, but I think in this case it > deserves mention as it's the most simple and intuitive > approach that doesn't quite work) > > -- Shish > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
