Re: PIZZA time again :-)
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 03 Sep 2005 12:00:45 +0200
Message-ID: <431973d9$1$11073$e4fe514c_at_news.xs4all.nl>
>
>
> 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'
>
> Sorry, do not understand.
>
>
> 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 - 12:00:45 CEST
Date: Sat, 03 Sep 2005 12:00:45 +0200
Message-ID: <431973d9$1$11073$e4fe514c_at_news.xs4all.nl>
VC wrote:
> mAsterdam wrote:
>>VC wrote:
[snip]
>>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'
Yep.
>>Should it also respect the order /of/ (as opposed to /in/) the lists?
>
> Sorry, do not understand.
L1 = [a, c, d]
L2 = [a, b, d]
If the order /of/ the lists matters, the result is
M = [a, c, b, d]
If it doesn't, the result is
M = [a, c, b, d]
M = [a, b, c, d]
>>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 - 12:00:45 CEST