Re: Ping: dawn, some mvl questions
Date: Wed, 24 May 2006 01:06:20 +0200
Message-ID: <447394ac$0$31651$e4fe514c_at_news.xs4all.nl>
Keith H Duggar wrote:
> mAsterdam (mA)
> Keith H Duggar (KHD)
>
> (First mA I accidently sent you an email subject "Please
> Stop". That was a stupid accident the email had nothing to
> do with you please ignore it.)
>
> mA wrote :
>
>>No, there are several clumsy ways to represent lists using >>only relations.
>
>
> KHD wrote :
>
>>Since, on the other hand, I find relations a quite elegant >>solution for ordering,
>
>
> mA wrote :
>
>>the "numbered items" way or the "successive items" way?
>
>
> KHD wrote :
>
>>I think it would depend on my purpose. However, the >>solution I find "elegant" at the moment is the ID with an >>edge relation. I like it because it can represent any >>directed graph in addition to lists of course, you can >>have arbitrarily many DGs for a set of nodes, and since I >>still get stuck on "how" thinking sometimes, I can readily >>see how to efficiently implement such a relation and >>algorithms using it.
>
>
> mA wrote :
>
>>Let's see if I understand. We view the list as a very >>simple graph, the idea being that if we have a relation >>capable of describing any directed graph we surely can >>describe a list, right? >> >>The drawback would be that the preservation of the >>listness is not garantueed. Whithout additional >>constraints there is no stopping anyone from inserting >>nodes which make the described graph more complex. Now the >>list is gone. >> >>BTW it would be very similar to the "successive >>items" way (which also has this drawback), no?
>
> Ok so this goes to the /using/ or /manipulation/ of a list
> representation as opposed to modeling correct?
"in order to" instead of "as opposed to" here.
How do you validate a model?
One step is to play out some relevant scenarios,
stories, use cases if you will, and see if
everything necessary is there.
> And isn't this a physical or implementation
> issue as opposed to a logical issue?
I don't think it is. Is normalisation a physical / implementation issue? No. Yet it is driven by the avoidance of update anomalies.
> I assume (though I truly have no idea) that DBMS provide
> mechanisms for specifying such constraints? In other words
> it's the responsibility of an implementation to guarantee
> "listness" is maintained. Correct?
I wish you were, really. Maybe someday you are, even. I have not yet seen the constraint set capable of maintaining listness.
> mA wrote:
>
>>Let's go that way for now. Which relation representation >>of the list do we choose - is it consequential? If we >>have lists in our model, we may have performance penalties >>in our implementation, but no open door to misinformation.
>
>
> If I understand you correctly, then I honestly do not
> know. Isn't this the core physical independence question?
I try to isolate the "meaning of order" problem from physical issues by focusing on abstract lists.
How are those lists physical?
> Logical vs Physical? What vs how? See I come from a /how/
> programming background so I don't have deep experience with
> separating logical and physical concerns.
Please don't let me stop you. It is a very worthwhile effort, IME. Maybe it is from trying to hard in this respect (first what, then how), that I am bumping my head against this list vs sets topic every now and again.
> And thus I don't
> know how well they can be separated in practice. Thus far it
> seems most abstractions do come with some cost; but, perhaps
> this has more to do with bias for certain logical models in
> hardware design.
>
> KHD wrote:
>
>>Why? If information is known and deemed important what is >>preventing us from making explicit? Can you give an >>example?
>
>
> mA wrote:
>
>>Not strictly an example, just a thought. In order to >>ascertain the importance of information it has to be >>observed (explicit information) or derived (implicit >>information) first. Think of an artefact from a crime >>scene - what information is there? The potential is huge.
>
>
> Sure, we agree that any physical thing represents a vast
> information content. I'm just pointing out that information
> we do /know/ (ie observe or derive) can be made explicit if
> we choose.
In general I do agree whith you on that. I cannot confidently agree on this with regard to lists, though. Received on Wed May 24 2006 - 01:06:20 CEST