Re: Canonical DB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 24 Jun 2006 00:18:31 +0200
Message-ID: <449c682e$0$31655$e4fe514c@news.xs4all.nl>

Dmitry A. Kazakov wrote:
> mAsterdam wrote:
>

>>...These requirements establish K as a clean point type.
>>Aside: With the last condition deleted one can make a
>>circular K, having distance(k1, k2) <> distance(k2, k1).

>
> That won't be formally a distance, which is required to be symmetric.

Interesting. I wasn't aware of that.

The topic of this example is well outside my terrain. For the little geometry knowledge I do have, I have to perform serious brain-archeology here :-)

[big snip of agreed/understood stuff]

> Imagine that the tuple is (X,Y) where X are streets and Y are avenues. Your
> problem space has Manhattan distance. Linear sorting this table
> fundamentally cannot help you to get out of O(n) pitfall, because whatever
> order on the tuples you define it will not be a distance in 2D. The fact
> that (X,Y) are indeed facts (no pun), does not help us here.

Checking if I am understanding you:

We have two tuples,
T1(X1, Y1) and T2(X2, Y2), and
md(T1, T2) defined as |X1 - X2| + |Y1 - Y2| Sorting will not help reducing the
complexity of the md computation.

>>>...A problem can be stated in terms of the problem space distances. Most of
>>>classification/optimization/approximation problems this or that way are.
>>
>>Could you please give some problem space examples?

>
>
> Calculate sine (approximation in C-norm)
> Nearest cafe (Manhattan distance)
> Is this car good? (some multidimensional space of attributes)
> Route a road (approximation in some class of functions [curves])
> Filter anything
> ...

Ok. Thank you.

>>>Yes. "Navigational" presumes existence of some context. Your actions depend
>>>on it. It is the focus of attention. You value things depending on how
>>>close are they to the focus. This allows you to reduce resources needed, by
>>>ignoring anything out of context. It also allows using adaptive techniques,
>>>i.e. to vary your strategy from point to point or/and from time to time.
>>>But it also may lead to aberrations, dead ends etc, which are quite common
>>>for "local" methods as opposed to "global" ones.
>>>
>>>I think that local vs. global is a better dichotomy than navigational vs.
>>>not. We could find it everywhere.
>>
>>It is another dichotomy.
>>local vs. global is better for what?

>
> To express the meta-ideas behind relational and what
> some RM guys call "ad-hoc b**t."

                              it-bucke ?   Nah. No clue :-)

>>ISTM local vs. global is within the navigational realm, so 
>>inappropriate for comparisons of computations with navigational
>>vs. relational structures.

>
> I didn't meant scopes of variables. Though they are a case. I meant global
> in a more general context: scope, effect, visibility.

Ah, I see.
How about general/specialized?

> Many of the
> operations in RA are global, like join. They involve complete tables. So RA
> tend to be global. But global is not always better than local. How often
> you lift your car? Is opening a car door bad, even if does not involve all
> atoms of the car? Yet when you drive the car, you may well wish that
> nothing of the car will left on the road behind...
>
>

>>Aside: I replaced 'not' by relational.
>>Is non-navigational synonymous to relational?
>>Some are reluctant to even consider that.

>
>
> Hmm, I can't tell.
Received on Fri Jun 23 2006 - 17:18:31 CDT