Thank you for the clarification. I only glanced at what it seemed to do but I apparently underestimated the complexity.
> -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Richard Hipp > Sent: dinsdag 24 april 2012 17:52 > To: General Discussion of SQLite Database > Subject: Re: [sqlite] rtree value rounding > > 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
