Re: qbql

From: Vadim Tropashko <vadimtro_at_gmail.com>
Date: Tue, 28 Sep 2010 14:48:16 -0700 (PDT)
Message-ID: <ed753a72-8cb0-42e0-ac22-333d571de445_at_c28g2000prj.googlegroups.com>


On Sep 28, 2:17 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> On 28/09/2010 11:55 AM, Vadim Tropashko wrote:
>
> > First user?-)
>
> Yup. Downloaded jar yesterday, got some kind of cpu loop, maybe because
> I was on my third cup of wine. Don't think I've tried java since about
> 1998 so I probably have command line options mangled.

CPU loops happen:-) I just fixed one this morning. To build up some confidence I suggest to start with queries, not assertions. For example, evaluate simple things like

[r s] a 1 b 1 <AND> [s t] 1 1 2 2;

Whenever QBQL checks an assertion, it iterates through all free relvals in the assertion statement. Consider, for example, join commutativity

x <AND> y = y <AND> x.

It has two variables x and y, which are assigned all the relations defined in the database file. Specifically, Figure1.db starts with

A=[p]

   1
;
B=[p]

   1
   2
;
C=[q]

   a
;
D=[q]

   a
   b
;
...

Therefore, it would try x=A, y=A, check the assertion, then try x=A, y=B, then x=A, y=C, and so on. For two variables it iterates nested loops two level deep. If we want to check associativity, then there would be three free variables, and the iteration would be three level deep; more formally O(n^3) where n is the number of relations in the database (~20 for Figure1.db). Now you can see why evaluating assertion takes more time than a query.

The bug was misidentification of free variables so that QBQL thought that NOT,AND,OR were variables as well. It iterated nested loops 5 levels deep. Received on Tue Sep 28 2010 - 23:48:16 CEST

Original text of this message