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@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 - 05:00:45 CDT