Re: PIZZA time again :-)

From: VC <boston103_at_hotmail.com>
Date: Fri, 2 Sep 2005 19:56:24 -0400
Message-ID: <hI6dnZQ1quQCe4XeRVn-vA@comcast.com>

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:4318c6d5$0$11080$e4fe514c_at_news.xs4all.nl...
> VC wrote:

>> mAsterdam wrote:
>>>vc wrote:
>>>>mAsterdam wrote:

> [snip]

>>>>Since 'merge' is commonly defined for lists with the same ordering, the
>>>>function cannot be applied to lists with different orderings,  e.g [a,
>>>>b] and [b,a,c] (ordering is defined by an element position in the list)
>>>>clearly cannot be merged.
>>>
>>>That is the merge as used in some sorting algorithms, not a merge
>>>in it's own right. But if you feel more comfortable calling the discussed 
>>>merge mymerge, truemerge, falsemerge or
>>>order_preserving_merge - ok.
>>
>> That is the merge function as used in functional languages  like ML, 
>> Haskell or Lisp (not pure functional).  My response relied on the common 
>> usage in those languages.
>>
>> Now, what is "a merge in its own right" ?  Unless one defines 
>> 'merge_in_its_own_right',  one cannot answer the question  what 
>> 'merge_in_its_own_right' should do with lists where ordering is defined 
>> by an element position.
>

> Let's see if we can come closer to a definition by listing desiderata:

>

> merge_in_its_own_right merges a list of lists into a list. It

>


>   - should not have assumptions about an

>     intrinsic order of the listed values.

>   - should preserve the order of the values

>     and fail if it can't.


 According to you specification the function should fail otherwise the 
function will behave as an ordinary (in the ML/Haskell sense) merge : 'if 
ordering(L1) == ordering(L2) merge otherwise fail'

>
> Should it also respect the order /of/ (as opposed to /in/) the lists?

Sorry, do not understand.

>

> order_preserving_merge would, I guess - but there are two different
> orders, and assumption 1 (in the original post) only declares the order
> /in/ the lists to be of consequence. Also declaring the order /of/ the
> list of consequence makes order_preserving_merge(+, -) determististic.
> I suspect that is an advantage - but is it a good enough reason?

Well, whether one cares about the resulting ordering or not is entirely up to a specific task at hand, or I am missing something ?

E.g. if one does not care about ordering, one can just concatenate the lists and remove duplicates (emulating a union of two sets). Or just sort-merge using arbitrary (but the same) ordering.

> I don't know.
Received on Fri Sep 02 2005 - 18:56:24 CDT