On Tuesday, July 2, 2002, at 03:08 PM, Janek Schleicher wrote:
> James E Keenan wrote at Sun, 30 Jun 2002 04:56:12 +0200: > >> This would require consideration of the question: "How do I define >> equality?" Is the list qw(1 2 >> 3) equal to the list qw(1 2 3 3)? I.e., "How do I treat multiple >> instances of the same element >> within a list?" > > In fact. > A list doesn't stand for any fixed implementation. > A list can be regarded as > - an array an array is a standard perl data structure defined as a list with a name. Example: @A = (1,2,3); we have a list ( 1, 2, 3) which has a name (@A) > - a set hmm, sets can't have repeating elements, right? thus lists are not as restricted wrt contents as a set. > - a bag (multiset) I have forgotten what a bag is. Anyone mind explaining? > - a way of ordering > - ... > > So I would expect that a list can be given in multiple forms > and would be regarded in multiple forms. > > So given two arrays to List::Compare, > we can look to them as arrays, as sets, as bags or something else. > > It makes sense to me to unify this comparisons into one module, > because it's very comfortable to say > use List::Compare instead > > of use Array::Compare, > use Set::Compare, > use Bag::Compare and so on. > > It makes also sense to use it on the same objects. > Assume that we'll implement a shuffle algorithm. > > my @new_card_stack = (1 .. 52); > my @shuffeld_cards = shuffle @new_card_stack. > > Now we would expect, > that my $stack_compare = List::Compare->new(@new_card_stack, > @shuffeld_cards) > ok $stack_compare->are_equal_sets; > ok $stack_compare->arent_equal_arrays; # > 99.9999% cases > > > Let's check whether anybody has corrected his fortune a little bit: > my @winner_stack = ( (1 .. 52), 49, 50, 51, 52 ); # 4 aces more > > So it would be very comfortable to have one module doing this job for > us. > > Now to the ordering. > Let's think to a modified Black Jack game. > Both, the bank and the player has the right to destroy one card they > got. > > So all cards are @shuffled_cards, > the player uses @player_cards, > and the bank @bank_cards. > > So now we would expect > my $player_cards_comp = > List::Compare->new(@shuffeld_cards,@player_cards); > ok $player_cards_comp->is_BsubsetA; # and > ok $player_cards_comp->is_BsuborderA; > >> There's no single correct answer to these questions. How you answer >> depends on what you need to >> do with the information reported by the method call. > > Indeed, TMTWTDI. > However, the lazy way is often the best one :-) > >> >> The original objective of List::Compare (with the exception of the >> get_bag() method) was a humble >> one: to put some simple object-oriented wrapping around the Cookbook >> code for comparison of 2 >> lists. The Cookbook code uses hash-lookup tables to achieve its >> results -- thereby flattening >> multiple instances and ignoring order within the lists. I would be >> inclined to say that any new >> methods added to List::Compare should take that approach, at least as >> their default options. At >> the very least, if you want to treat the order of elements as >> significant, you cannot use hash >> lookup tables to determine that; hence, you should probably look >> elsewhere. > > No, I only mean, that the comparing of lists can be regarded > with AND without significant ordering. > Both is useful - and with too much, both should be implemented. > > > Good luck, > Janek > >
