Re: Canonical DB
Date: Sat, 24 Jun 2006 00:18:31 +0200
Message-ID: <449c682e$0$31655$e4fe514c_at_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|
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 Sat Jun 24 2006 - 00:18:31 CEST