Re: PIZZA time again :-)
From: VC <boston103_at_hotmail.com>
Date: Fri, 2 Sep 2005 19:56:24 -0400
Message-ID: <hI6dnZQ1quQCe4XeRVn-vA_at_comcast.com>
> [snip]
> 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 it also respect the order /of/ (as opposed to /in/) the lists?
> 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?
Date: Fri, 2 Sep 2005 19:56:24 -0400
Message-ID: <hI6dnZQ1quQCe4XeRVn-vA_at_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?
>
> 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 Sat Sep 03 2005 - 01:56:24 CEST