Dennis Cote wrote:
> John Stanton wrote:
>> But for practical arithmetic probability or possibility is not close
>> enough. It must be certainty.
>
> There is a possibility that your code could be asked to compare two
> equal floating point numbers. To be correct, it must handle that case.
In relation with the floating point number and its IEEE internal
representation, may be of interest:
http://babbage.cs.qc.edu/IEEE-754/
HTH
Adolfo
___
sqlite-users mailing list
sqlite-users@sqlite.org
Hence the word "SOME"... :)
Asif Lodhi <[EMAIL PROTECTED]> wrote: Hi Ken,
On 6/6/08, Ken wrote:
> Some numbers can be represented exactly using the
> floating point type. .
Here is a reference from "The C++ Programming Language, 3rd Edition"
by Bjarne Stroustrup, Page 835, section
Hi Ken,
On 6/6/08, Ken <[EMAIL PROTECTED]> wrote:
> Some numbers can be represented exactly using the
> floating point type. .
Here is a reference from "The C++ Programming Language, 3rd Edition"
by Bjarne Stroustrup, Page 835, section - C.6.2.6:
John Stanton wrote:
>
> But for practical arithmetic probability or possibility is not close
> enough. It must be certainty.
There is a possibility that your code could be asked to compare two
equal floating point numbers. To be correct, it must handle that case.
If it does not, it is
One of the things that people fail to understand is that floating point
numbers are stored in *binary*. In fact, I bet a number of people who
understand the exact binary formatting of integers don't understand that the
technique translates pretty much directly into floating point: a floating
Some numbers can be represented exactly using the floating point type.
According to ieee 754 spec:
"All integers that are a power of 2 can be stored in a 32 bit float without
rounding
Precision decreases exponentially as the exponent increases"
So for those numbers equality is necessary.
John Stanton wrote:
>
> The point about using floating point is that there is no equal, only
> less or greater, because it is an approximation. If you want to use
> equality you must use some form of integer or fixed ppint numbers.
>
That's not true at all. While it is not reliable to use
Steve Kallenborn wrote:
> D. Richard Hipp wrote:
>> On Jun 4, 2008, at 7:13 AM, Derrell Lipman wrote:
>>
>>> On Wed, Jun 4, 2008 at 10:01 AM, D. Richard Hipp <[EMAIL PROTECTED]>
>>> wrote:
>>>
Let me strongly reiterate that you look into using the new R-Tree
virtual table available for
On Jun 5, 2008, at 12:55 AM, Shane Harrelson wrote:
> Once you get it working with your data, you may want to play around
> with the
> defines at the top of rtree.c.
>
>
>> /* Either, both or none of the following may be set to activate
>> ** r*tree variant algorithms.
>> */
>> #define
> If you aren't storing the lat and long data in the main table anymore,
> you will have to join the RTree table on the id to get that data. I'm
> guessing about your tables definitions, but you should get the idea from
> this:
>
Yes, that is my setup, however, the new query is slow as
Christophe Leske wrote:
> I need lat and long pos from CityLoc.
>
> I got this currently,
>
> sqlite> Select cities.*, citylookup.longitude_min from cities,citylookup
> where c
> ities.id in (select id from citylookup where
> (citylookup.longitude_min>-45.0
> 0 and
Dennis Cote schrieb:
> Shane Harrelson wrote:
>
>>> -- a further simplification of the general case that removes
>>> -- redundant terms
>>> select * from City
>>> where id in
>>> (
>>> select id from CityLoc
>>> where (lat_min < :max_lat and lat_max >
Shane Harrelson wrote:
>> -- a further simplification of the general case that removes
>> -- redundant terms
>> select * from City
>> where id in
>> (
>> select id from CityLoc
>> where (lat_min < :max_lat and lat_max > :min_lat)
>> and (long_min <
In addition to playing with the splitting algorithms, since you are
compiling your own DLL, you can customize the R-Tree module for 2 dimensions
-- i.e. hard-code it for 5 columns of data.
This would *roughly* be accomplished by replacing all occurrences of
pRtree->nDim
with
(2)
and
Regarding:
-- 21290 -- full globe view
... is way to slow, it blocks the app 21 seconds - granted, it is the
inital start up, but still.
Well, some people aren't satisfied unless they can have the whole world,
apparently.;-)
1) Have you already exhausted tuning the database with larger
The default R-Tree code uses the "R*-tree algorithm" for splitting. While
this should typically perform better than the other two variants (Guttman
Quadratic and Linear splitting), you may want to test them with your data
set and queries to see if either performs better. You will need to
Christophe Leske wrote:
> Shane Harrelson schrieb:
>> Dennis-
>>
>> Your last "simplification":
>>
> I never got that email from Dennis, I would be very interested in it.
>
> Dennis, this is actually what i am currently doing.
>
> However:
>
> i see no speed up for large areas (half the
> I added an index on the ID field for the search in the city database,
> that helped a bit, but i am dissapointed that the rtree search is not
> faster than the normal search for bigger areas..
Here are the query times in ms for full globe view with zooming in to
Romania:
-- 21290 -- full
Shane Harrelson schrieb:
> Dennis-
>
> Your last "simplification":
>
I never got that email from Dennis, I would be very interested in it.
Dennis, this is actually what i am currently doing.
However:
i see no speed up for large areas (half the globe, e.g.), but
considerable ones for small
> Is this how you expect the RTree tables to be used in a case like the OP
> is interested in?
>
> create table City (
> id integer primary key,
> nametext,
> lat real,
> longreal,
> class integer
> );
>
> create
Dennis-
Your last "simplification":
> -- a further simplification of the general case that removes
> -- redundant terms
> select * from City
> where id in
> (
> select id from CityLoc
> where (lat_min < :max_lat and lat_max > :min_lat)
> and
D. Richard Hipp wrote:
>
> Let me strongly reiterate that you look into using the new R-Tree
> virtual table available for SQLite. R-Trees are specifically designed
> to do exactly the kind of query you are asking to do. See
>
>
Once you get it working with your data, you may want to play around with the
defines at the top of rtree.c.
> /* Either, both or none of the following may be set to activate
> ** r*tree variant algorithms.
> */
> #define VARIANT_RSTARTREE_CHOOSESUBTREE 0
> #define VARIANT_RSTARTREE_REINSERT 1
>
> You should modify the rtree.c source file and add the following before each
> public function:
>__declspec(dllexport)
>
> So for instance, line 2772:
>int sqlite3_extension_init(
> becomes:
>__declspec(dllexport) int sqlite3_extension_init(
>
Thank you, I got it to work!!!
Now,
Without creating a .DEF file for MSVC to use, you need to tell it which
functions to "export".
The easiest way to do this is with the __declspec(dllexport).
You should modify the rtree.c source file and add the following before each
public function:
__declspec(dllexport)
So for instance, line
Cole,
thanks for your help.
> I doubt that you will. They are going to produce the same code. I would
> stick with between since it is logically clearer.
>
Yes, this is also what I am seeing here from my timings so far.
> I would also use a single index on either longitude or latitude not
>
Christophe Leske wrote:
> Hi,
>
> i am still fiddling around with my database and was wondering which kind
> of query would be quicker?
>
> I have three values i am interested in my request:
>
> - longitude_dds
> - latitude_dds
> - class_dds (being the importance of the city, with 1 = capital
On Jun 4, 2008, at 8:05 AM, Steve Kallenborn wrote:
> In the same document:
> "For each pair of real values, the first (leftmost) must be
> less than or greater than the second."
>
> should presumable read "less than or equal to"
>
OK. Try
> If you can tell me what platform you're compiling for (processor, O/S
> version, etc.), and what build tools
> (cygwin/gcc, mingw, MSVC, etc.) you're using, I will try and walk you
> through the steps for building the
> RTree module as a separate DLL.
>
Shane,
I got a version, but it is
D. Richard Hipp wrote:
> On Jun 4, 2008, at 7:13 AM, Derrell Lipman wrote:
>
>> On Wed, Jun 4, 2008 at 10:01 AM, D. Richard Hipp <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Let me strongly reiterate that you look into using the new R-Tree
>>> virtual table available for SQLite. R-Trees are
Sorry, I was too quick - i now got a 80Kb rtree.dll file which seems
fine. I will test it.
Thanks to everyone for your support,
Christophe Leske
www.multimedial.de - [EMAIL PROTECTED]
http://www.linkedin.com/in/multimedial
Lessingstr. 5 - 40227 Duesseldorf - Germany
0211 261 32 12 - 0177 249
> If you can tell me what platform you're compiling for (processor, O/S
> version, etc.), and what build tools
> (cygwin/gcc, mingw, MSVC, etc.) you're using, I will try and walk you
> through the steps for building the
> RTree module as a separate DLL.
>
Hi,
i am on Windows, and I got
This wiki page (http://www.sqlite.org/cvstrac/wiki?p=LoadableExtensions)
talks about
SQLite's loadable extension functionality.
If you can tell me what platform you're compiling for (processor, O/S
version, etc.), and what build tools
(cygwin/gcc, mingw, MSVC, etc.) you're using, I will try and
> To compile the R-Tree extension, you only need rtree.c and rtree.h,
> which you can pull directly from the website without having to use
> CVS. (OK, you'll probably also need sqlite3.h and sqlite3ext.h, but I
> assumed you already have those.)
>
Hi,
thank you for this, i got the
Hi Christophe,
On 6/4/08, Christophe Leske <[EMAIL PROTECTED]> wrote:
> ..
> AND (latitude_DDS BETWEEN 44.261771 and 44.424779)
You might want to check if you can somehow store this data *without*
the decimal point (with the point implied - counting six digits from
right to left)
On Jun 4, 2008, at 7:13 AM, Derrell Lipman wrote:
> On Wed, Jun 4, 2008 at 10:01 AM, D. Richard Hipp <[EMAIL PROTECTED]>
> wrote:
>
>>
>> Let me strongly reiterate that you look into using the new R-Tree
>> virtual table available for SQLite. R-Trees are specifically
>> designed
>> to do
On Jun 4, 2008, at 7:06 AM, Christophe Leske wrote:
>
>> Let me strongly reiterate that you look into using the new R-Tree
>> virtual table available for SQLite. R-Trees are specifically
>> designed
>> to do exactly the kind of query you are asking to do. See
>>
>>
On Wed, Jun 4, 2008 at 10:01 AM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
>
> Let me strongly reiterate that you look into using the new R-Tree
> virtual table available for SQLite. R-Trees are specifically designed
> to do exactly the kind of query you are asking to do. See
>
>
>I understand that BETWEEN gets translated to >= and =< (bigger or
>equal, and small or equal).
Some time ago I tested and observed different behaviour for BETWEEN in
SQLite (sometime as >= and =<, sometime >= and <), so test it for yourself.
I think it is better to use comparison signs (=,<,>)
> Let me strongly reiterate that you look into using the new R-Tree
> virtual table available for SQLite. R-Trees are specifically designed
> to do exactly the kind of query you are asking to do. See
>
> http://www.sqlite.org/cvstrac/fileview?f=sqlite/ext/rtree/README=1.2
>
> R-Trees
On 6/4/08, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
>
> On Jun 4, 2008, at 6:53 AM, Christophe Leske wrote:
>
> > Hi,
> >
> > i am still fiddling around with my database and was wondering which
> > kind
> > of query would be quicker?
> >
>
>
> Let me strongly reiterate that you look into
On Jun 4, 2008, at 6:53 AM, Christophe Leske wrote:
> Hi,
>
> i am still fiddling around with my database and was wondering which
> kind
> of query would be quicker?
>
Let me strongly reiterate that you look into using the new R-Tree
virtual table available for SQLite. R-Trees are
43 matches
Mail list logo
