Re: PIZZA time again :-)

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Mon, 05 Sep 2005 00:30:15 +0200
Message-ID: <431b74e9$0$11066$e4fe514c@news.xs4all.nl>

VC wrote:

> mAsterdam wrote:

 >> mAsterdam wrote:
 >>> VC wrote:
 >>>> mAsterdam 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.
 >>
 >> On second thought I'm not sure.
 >> Does 'ordering(L1) == ordering(L2)' in the ML/Haskell sense hold for
 >> L1 = [a, b, a, c]
 >> L2 = [a, a, c]
 >> ?
 >

> Since you define ordering by the position,
> then the ordering for L1 is:

 >

> { (a,a), (a,b), (a,c), (b,a), (b,c)}

 >

> ...which is not really ordering because of lacking antisymmetry
> ( (a,b), (b,a) ). So L1 is not ordered in the
> math sense regardless of the language.
 >
> If L1 were [a,a,c,b] or [a,a,b,c], then it would be ordered.

Thank you. If it's possible to merge (in the _in_its_own_right sense :-) the lists anyway it means that the lists having some ordering is not a precondition. However, even if it is possible it may well be too difficult to start with. I'm actually trying to code something in prolog now. I am not used to that, but prolog feels like a good match for the problem (which was why I crossposted to clp - I hope you don't mind). Received on Sun Sep 04 2005 - 17:30:15 CDT