Re: Alleged Relational Stumper


Dmitry A. Kazakov wrote:
On 29 Jan 2007 15:03:36 -0800, topmind wrote:

On Jan 29, 12:06 pm, "Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx>
wrote:
On 29 Jan 2007 11:22:43 -0800, topmind wrote:

Dmitry A. Kazakov wrote:
On 29 Jan 2007 06:41:04 -0800, freb...@xxxxxxxxx wrote:

The relational model makes a distinction between logical an physical
data structures. Relations are a logical data structure. B-trees or kd-
trees are physical data structures. The logical and physical data
structures are independent of each other. A database which provides
relations, may still use any kind of physical structures.
I see. A poster with a car is logical structure of that car. The car in the
garage is the physical structure of. Are are selling me posters?

Please readhttp://www.inconcept.com/JCM/May2002/pascal.htmlandyou
have a deeper explaination about the difference between logical and
physical levels. Athttp://www.acm.org/classics/nov95/s1p2p2.html, you
can read what Dr Codd have to say about separating the choice of index
from the application (separation of concerns).I am impressed, bright colors, glossy paper, great.
Now what about the car?
Show me the data structure and the code for f.

If you think you will get an index and query optimizer implementation,
I can tell you that this is not going to happen.

As we rushing to full agreement, maybe, the last final question. Is it so
that just you cannot solve the problem, or nobody can?

Are you claiming it is not solvable period, or that it cannot be
integrated into relational? I think Freb is just saying that he will
not show the details of how it is done.

If such an index *is* implementable outside of relational, it is
possible to integrate into a RDBMS. My simplest suggestion from
several months ago was to implement it as a function that returns the
primary key of matching points.

// Radius example - Within 12 units of coordinates 7, 8
SELECT * FROM points
WHERE pointID IN withinRadius(points, x, y, 12, 7, 8)

// Closest matches example - Closest 50 matches of 7,8
SELECT * FROM points
WHERE pointID IN closest(points, x, y, 50, 7, 8)This is not a solution of the problem:

1. It does not find the best match. To determine the minimal radius is an
essential part of the problem.

It does too. Use the closest() function with a setting of 1.

Ah, now I see, what you meant. No, that cannot work at all. Such "closest"
would not be a function of its arguments.

Please clarify.


2. It does not show that the complexity is any better than O(n). Where it
follows from? White Unicorns again?

It don't have to. RELATIONAL DOES NOT DICTATE IMPLEMENTATION.

Sorry, I fail to understand this. A program IS an implementation. Do you
mean that relational is not about programming? (Hmm, I always doubted it)

"About"? It is one of many tools for programming.


Here is the solution:

1. Write the solution in YOUR favorite language using YOUR favorite
algorithm,
2. Stick a relational query language on top of your favorite language
(or the app).
3. DONE!

Why should I have TWO languages? The language 1 is for solving problems.
The query language 2 is for what? (For mantras perhaps?)

This was to illustrate that your requirements could be satisfied.
Whether it is practical to do such is another matter. The example is
optimized to illustrate a point, not necessarily to be practical. This
is not the say that a practical description that satisfies your
requirements couldn't be built. It could, but would take too long to
describe.

It appears you didn't dissagree with its fitness to your original
requirements. Thus, it served its purpose.


3. It is not relational for it does not show a relational implementation of
index.

Relational is really about "container rules", not domain math. You are
over-focusing on domain-math issues.

No, it is solely about those rules. The problem is that RA has rules which
don't map the domain (Euclidean space). They are sufficiently different
algebraic structures when digitized into finite presentations.

Horse feathers. You are confusing SQL with relational.

No, I don't. I explicitly stated that RA is an unsuitable description of
the problem. The solutions you might find (if you could) within RA would be
worse than O(n).

Like I said, one could take an implementation that satisfies O(n), and
stick a relational query language on top of it. (Other stuff outside
of your requirements may run slow, but that is another issue. My point
is to prove that your original claim is false. If you expand or alter
your claim later, then so be it.)


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

-T-

.

Relevant Pages

  • Re: GMP vs. straight C arithmetic
    ... ordinary data structures that don't impose an additonal performance ... Side-effects are another crucial part of the language. ... > Take the tree structure example I gave earlier. ... determined at compile time, is this a compile time error? ...
    (comp.programming)
  • Re: Alleged Relational Stumper
    ... trees are physical data structures. ... A poster with a car is logical structure of that car. ... Stick a relational query language on top of your favorite language ... over-focusing on domain-math issues. ...
    (comp.object)
  • Re: Factor
    ... emphasis on idiomatic programming is the greatest challenge. ... it sure is nice when a language gives you a rich and ... flexible set of data structures and algorithms that are designed so ... There is no reason to believe that my implementation of lists is ...
    (comp.lang.forth)
  • Re: why learn C?
    ... programming beginner. ... Any language that allows subroutines is procedural based. ... you can learn about algorithms and data structures ...
    (comp.lang.c)
  • Re: Alleged Relational Stumper
    ... trees are physical data structures. ... A poster with a car is logical structure of that car. ... Stick a relational query language on top of your favorite language ... that Dr. Codd explicitedly limited the domain math to something, ...
    (comp.object)