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
- a set
- a bag (multiset)
- 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
