PIZZA time again :-)

PIZZA time again :-)

Post by mAsterda » Sat, 03 Sep 2005 06:54:15


Assume
1. there is a meaningful (or at least consequential)
difference between:

toppings([salami, mozarella, onions]).
and
toppings([mozarella, onions, salami]).

2. A, B, C are lists (conforming to the as yet to
be published Spight LIST grammar in relational context).

What should
merge ([A,B], C). % merge list of lists into list
mean ?

I think it should merge A and B into C,
preserving order, and fail if it can't.

Or, if merge(+, +) just fail if C isn't a merge.

(google for C3, Dylan, Perl)

(clp - sorry for bothering you :-)
 
 
 

PIZZA time again :-)

Post by Paul » Sat, 03 Sep 2005 21:46:06


Of course there is. If you had the onions at the bottom, they would't
cook right, although as a BOM for billing, there's no problem.


Paul...


--

plinehan __at__ yahoo __dot__ __com__

XP Pro, SP 2,

Oracle, 9.2.0.1.0 (Enterprise Ed.)
Interbase 6.0.1.0;

When asking database related questions, please give other posters
some clues, like operating system, version of db being used and DDL.
The exact text and/or number of error messages is useful (!= "it didn't work!").
Thanks.

Furthermore, as a courtesy to those who spend
time analysing and attempting to help, please
do not top post.

 
 
 

PIZZA time again :-)

Post by mAsterda » Sat, 03 Sep 2005 22:56:53


So, you agree assumption 1 has value. Good.

Consider

merge(ListOfLists, MergedList).

Now

merge ([[salami, mozarella, onions][mozarella, onions, salami]], M).

should fail because salami is before mozarella in the first list,
and after it in the second. It can't preserve the order.


Should

merge([[salami, buttonmushroom, mozarella, onions][salami, artichoke,
mozarella]], M).

succeed with
M = [salami, buttonmushroom, artichoke, mozarella, onions]
M = [salami, artichoke, buttonmushroom, mozarella, onions]

or just the first one (because of the order of the lists)?
 
 
 

PIZZA time again :-)

Post by Duncan Pat » Sun, 04 Sep 2005 01:35:46

On Fri, 02 Sep 2005 15:56:53 +0200





Which is the most truest answer me!!!

This is a "Whois fairest of them all", sort of thing, but has useful
application if you can limit the semantic expression of underlying
features to something simple and comprehensible. The problem becomes
when something more is read into the order than went into the
ordering. It's important to put the onions on top so they cook
but when you get into voodoo over who should get the cherry on top,
its mebbe time to skip the cherry.

Dhu



--
???????????????????????????????????????

Can't get good help?

Contact Fubar the Hack: fubar AT neotext.ca

Area code seven eight zero, Exchange four six six, Local zero one zero nine

Highland terms, Canadian workmanship.

All persons named herein are purely fictional victims
of the Canidian Bagle Breeder's Association.

Save the Bagle!

Sun u

???????????????????????????????????????
 
 
 

PIZZA time again :-)

Post by dawn » Sun, 04 Sep 2005 03:52:07


I don't know how you define a merge when there isn't an ordering
defined on the type. Is there such a function? Your lists are
ordered here, but your domain/type is not, unless you choose something
like alpha order.

I can imagine an interleave function that alternates ingredients from
both lists and yields a pizza with salami on it twice (I think I'll
pass on it, however). --dawn
 
 
 

PIZZA time again :-)

Post by mAsterda » Sun, 04 Sep 2005 04:32:22


[snip]

That is another way of asking the same question.
What should 'merge' do when the order is not
in the values (as it would be if we took the
ordering defined on the type) but just in
their position, relative to other values.
It is what I'm trying to find out.


So that is not the desired behaviour.
The resulting pizza will be richer than the
originals, but I would like to see one you
would like to eat.
 
 
 

PIZZA time again :-)

Post by mAsterda » Sun, 04 Sep 2005 04:43:17


[snip]
[snip]

I think

merge([[salami, buttonmushroom, buttonmushroom, mozarella],
[salami, mozarella, onions]], M).

should succeed with:
M = [salami, buttonmushroom, buttonmushroom, mozarella, onions].
 
 
 

PIZZA time again :-)

Post by vc » Sun, 04 Sep 2005 05:05:06


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.
 
 
 

PIZZA time again :-)

Post by A.L. » Sun, 04 Sep 2005 05:07:35

On Thu, 01 Sep 2005 23:54:15 +0200, mAsterdam < XXXX@XXXXX.COM >



It can be yes or not, whatever you like


It can be both, whatever you like

A.L.
 
 
 

PIZZA time again :-)

Post by mAsterda » Sun, 04 Sep 2005 05:21:56


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.
 
 
 

PIZZA time again :-)

Post by dawn » Sun, 04 Sep 2005 05:29:09


Perhaps it should do the same thing as a sort on a set where no
ordering has been defined - ?


I'd like plenty of mozarella, olives (black or green), tomatoes, and
maybe even some pepperoni on either a whole wheat crust or a thin crust
-- oh, and pineapple too. The ordering does make a difference, as does
the city in which I'm eating the pizza -- in Chicago I'm OK with
reversing the order and adding sausage to the pizza. I'm sitting in
the biggest pork producing county in the U.S. right now and people
order pizza with "swine" on it here.

I talked students through a pizza example from the Head Frist Design
Patterns book last year -- a fun book for anyone wanting to teach or
learn OO design patterns.

cheers! --dawn
 
 
 

PIZZA time again :-)

Post by VC » Sun, 04 Sep 2005 06:05:02


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.
 
 
 

PIZZA time again :-)

Post by mAsterda » Sun, 04 Sep 2005 06:40:55


[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 not have assumptions about an
intrinsic order of the listed values.
- should preserve the order of the values
and fail if it can't.

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?
I don't know.
 
 
 

PIZZA time again :-)

Post by Duncan Pat » Sun, 04 Sep 2005 07:32:57

On Fri, 02 Sep 2005 21:43:17 +0200






Sure. But why? A consistent rational needs to be included.

Dhu



--
???????????????????????????????????????

Can't get good help?

Contact Fubar the Hack: fubar AT neotext.ca

Area code seven eight zero, Exchange four six six, Local zero one zero nine

Highland terms, Canadian workmanship.

All persons named herein are purely fictional victims
of the Canidian Bagle Breeder's Association.

Save the Bagle!

Sun u

???????????????????????????????????????
 
 
 

PIZZA time again :-)

Post by mAsterda » Sun, 04 Sep 2005 08:16:37


In unix, the cherry on top is root.
In CODASYL databases it's OOAK (One Of A Kind).
In RM there is none.