On Tue, Apr 24, 2012 at 11:41 AM, Jos Groot Lipman <donts...@home.nl> wrote:
> 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 > I think you're misunderstanding my check-in comment (which is admittedly terse). The regular RTree module supports both float-point and integer coordinates, but it always uses floating-point computations internally. The change above provides a compile-time option to use only integer computations internally - for use on embedded devices that lack floating-point hardware. It is a compile-time option only. And the coordinates are still stored as 32-bit integers. > -- > 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 > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
