Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29504 > unrolled thread

Help with Deck of cards assignment and getting it to deal...

Back to article view | Back to comp.lang.java.programmer

Contents

  Help with Deck of cards assignment and getting it to deal... Scott Dunning <scottwd01@gmail.com> - 2014-08-01 18:16 -0700
    Re: Help with Deck of cards assignment and getting it to deal... Roedy Green <see_website@mindprod.com.invalid> - 2014-08-02 01:42 -0700
      Re: Help with Deck of cards assignment and getting it to deal... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-02 10:19 +0000
        Re: Help with Deck of cards assignment and getting it to deal... Roedy Green <see_website@mindprod.com.invalid> - 2014-08-03 15:54 -0700
          Re: Help with Deck of cards assignment and getting it to deal... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-04 13:00 +0000
            Re: Help with Deck of cards assignment and getting it to deal... Arne Vajhøj <arne@vajhoej.dk> - 2014-08-19 17:48 -0400
              Re: Help with Deck of cards assignment and getting it to deal... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-20 10:48 +0100
                Re: Help with Deck of cards assignment and getting it to deal... Arne Vajhøj <arne@vajhoej.dk> - 2014-09-07 21:42 -0400
                Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-09-07 22:04 -0400
                  Re: Help with Deck of cards assignment and getting it to deal... Arne Vajhøj <arne@vajhoej.dk> - 2014-09-07 22:08 -0400
    Re: Help with Deck of cards assignment and getting it to deal... Mike Amling <mamling@chaff.us> - 2014-08-03 07:38 -0500
    Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 10:23 -0400
      Re: Help with Deck of cards assignment and getting it to deal... lipska the kat <lipskathekat@example.com> - 2014-08-03 18:52 +0100
        Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 14:16 -0400
          Re: Help with Deck of cards assignment and getting it to deal... lipska the kat <lipskathekat@example.com> - 2014-08-03 19:21 +0100
            Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 14:38 -0400
              Re: Help with Deck of cards assignment and getting it to deal... lipska the kat <lipskathekat@example.com> - 2014-08-03 19:41 +0100
      Re: Help with Deck of cards assignment and getting it to deal... Mike Amling <mamling@chaff.us> - 2014-08-03 16:05 -0500
    Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 11:08 -0400
      Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 11:41 -0400
        Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 13:25 -0400
          Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 13:36 -0400
            Re: Help with Deck of cards assignment and getting it to deal... David Postill <david.postill@gmail.com> - 2014-08-04 09:00 +0200
          Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 13:47 -0400
            Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 13:52 -0400
              Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 14:10 -0400
          Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 15:00 -0400
            Re: Help with Deck of cards assignment and getting it to deal... Arne Vajhøj <arne@vajhoej.dk> - 2014-08-03 15:26 -0400
              Re: Help with Deck of cards assignment and getting it to deal... lipska the kat <lipskathekat@example.com> - 2014-08-03 20:34 +0100
              Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 16:49 -0400
                Re: Help with Deck of cards assignment and getting it to deal... Arne Vajhøj <arne@vajhoej.dk> - 2014-08-03 17:01 -0400
                  Re: Help with Deck of cards assignment and getting it to deal... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-04 20:32 +0100
                    Re: Help with Deck of cards assignment and getting it to deal... Arne Vajhøj <arne@vajhoej.dk> - 2014-08-19 17:45 -0400
                      Re: Help with Deck of cards assignment and getting it to deal... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-20 10:50 +0100
                        Re: Help with Deck of cards assignment and getting it to deal... Brixomatic <brixomatic@yahoo.com> - 2014-08-31 10:17 +0200
                          Re: Help with Deck of cards assignment and getting it to deal... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-04 15:14 +0100
                            Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-09-04 10:55 -0400
                              Re: Help with Deck of cards assignment and getting it to deal... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-04 16:12 +0100
                                [OT] Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-09-04 15:05 -0400
                              Re: Help with Deck of cards assignment and getting it to deal... Gene Wirchenko <genew@telus.net> - 2014-09-05 10:03 -0700
                        Re: Help with Deck of cards assignment and getting it to deal... Arne Vajhøj <arne@vajhoej.dk> - 2014-09-07 21:45 -0400
                          Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-09-07 22:13 -0400
                Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 17:19 -0400
                  Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-04 08:14 -0400
                    Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-04 20:03 -0400
                      Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-04 20:29 -0400
            Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 15:45 -0400
              Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 16:01 -0400
                Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 17:05 -0400
                  Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 17:37 -0400
                    Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 18:19 -0400
                      Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 18:34 -0400
                        Re: Help with Deck of cards assignment and getting it to deal... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-03 20:37 -0400
                          Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 20:40 -0400
                            Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 20:49 -0400
                  Re: Help with Deck of cards assignment and getting it to deal... Jeff Higgins <jeff@invalid.invalid> - 2014-08-03 18:09 -0400
    Re: Help with Deck of cards assignment and getting it to deal... Roedy Green <see_website@mindprod.com.invalid> - 2014-08-04 18:43 -0700
      Re: Help with Deck of cards assignment and getting it to deal... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-05 11:19 +0100
        Re: Help with Deck of cards assignment and getting it to deal... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-05 11:28 +0100
    Re: Help with Deck of cards assignment and getting it to deal... lipska the kat <lipskathekat@example.com> - 2014-08-31 17:31 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#29521

On 08/03/2014 11:41 AM, Eric Sosman wrote:
> On 8/3/2014 11:08 AM, Jeff Higgins wrote:
>> On 08/01/2014 09:16 PM, Scott Dunning wrote:
>>> Hello, I have an assignment for my summer class.  FYI, I'm super new to
>>> programming in general and this is my first time with java and it's a
>>> summer class so it's going super fast (please be nice!) lol.
>>
>> No. It seems to be going slowly. The last three assignments you've
>> brought here are rehashes. Surely by now you should have gone into
>> interfaces and collections.
>>
>> Your Card class will be more easily used if it implement the
>> java.lang.Comparable<T> interface
>
>      I'd advise against this,

>  because the ordering depends not on the
> Card, but on the rules of whatever game is being played.

Exactly.

>  There are
> games where Ace is high, games where it is low, games where it can
> be either at the discretion of the player, and for all I know there
> may be games where Ace can lie between King and Deuce.  And then
> there's the question of suit: How does the Seven of Hearts compare
> to the Jack of Clubs? Would knowing whether Hearts are trumps affect
> your answer?
>
>      Scott: Don't Go There; you'll just get lost.
>
Scott: If you don't go there you'll never find your way.

package scratch;

/**
  * The face value of a {@link Card}.
  *
  * Rank specifies one of 13 distinct,
  * implementation defined values and their order.
  *
  * The default values and order for Rank are:
  * Ace, Two through Ten inclusive, Jack, Queen, King.
  *
  * @author jeff
  *
  */
public interface Rank extends Comparable<Rank> {

}

package scratch;

/**
  * The suit of a {@link Card}.
  *
  * Suit specifies one of an implementation defined
  * number of distinct values and their order(if any).
  *
  * The default values and their order(highest to lowest)
  * for Suit are: Spades, Hearts, Diamonds, Clubs.
  *
  * @author jeff
  *
  */
public interface Suit extends Comparable<Suit> {

}

package scratch;

/**
  * A playing card.
  *
  * @author jeff
  *
  */
public interface Card extends Comparable<Card> {

   /**
    * Returns one of the 13 distinct values represented
    * in the implementation of the {@link Rank} interface.
    *
    * @return the Rank of this Card.
    */
   Rank getRank();

   /**
    * Returns one of the distinct values represented
    * in the implementation of the {@link Suit} interface.
    *
    * @return the Suit of this Card.
    */
   Suit getSuit();

}

package scratch;

/**
  * An ordered set of playing {@link Card}s.
  *
  * @author jeff
  *
  */
public interface Deck extends Iterable<Card> {

}

Implement the Rank and Suit interfaces using the default values as 
immutable concrete classes.
Implement an immutable Card interface using your concrete Rank and Suit 
classes.
Implement the Deck interface, including its java.lang.Iterator<E> 
implementation, as an immutable concrete class.
Design and implement a Game class using the above implemented classes.
The game is to deal a hand of five Cards from the Deck and compare hands 
until no further hands may be dealt.

[toc] | [prev] | [next] | [standalone]

#29522

On 08/03/2014 01:25 PM, Jeff Higgins wrote:

> package scratch;
>
> /**
>   * The face value of a {@link Card}.
>   *
>   * Rank specifies one of 13 distinct,
>   * implementation defined values and their order.
>   *
>   * The default values and order for Rank are:
>   * Ace, Two through Ten inclusive, Jack, Queen, King.
>   *
>   * @author jeff
>   *
>   */
> public interface Rank extends Comparable<Rank> {
>
> }
>
For a more universal appeal the restriction to 13 may be relaxed.

[toc] | [prev] | [next] | [standalone]

#29552

In article <lrlrug$6nk$1@dont-email.me>, on Sun, 03 Aug 2014 13:36:12
-0400, Jeff Higgins wrote:

| On 08/03/2014 01:25 PM, Jeff Higgins wrote:
| 
| > package scratch;
| >
| > /**
| >   * The face value of a {@link Card}.
| >   *
| >   * Rank specifies one of 13 distinct,
| >   * implementation defined values and their order.
| >   *
| >   * The default values and order for Rank are:
| >   * Ace, Two through Ten inclusive, Jack, Queen, King.
| >   *
| >   * @author jeff
| >   *
| >   */
| > public interface Rank extends Comparable<Rank> {
| >
| > }
| >
| For a more universal appeal the restriction to 13 may be relaxed.

I was wondering what happened to the Jokers in the pack ;)
-- 
David Postill
Dance your Life - Biodanza in Alkmaar, Holland - <http://www.danceyourlife.eu>

[toc] | [prev] | [next] | [standalone]

#29523

On 08/03/2014 01:25 PM, Jeff Higgins wrote:

> package scratch;
>
> /**
>   * A playing card.
>   *
>   * @author jeff
>   *
>   */
> public interface Card extends Comparable<Card> {
>
>    /**
>     * Returns one of the 13 distinct values represented
>     * in the implementation of the {@link Rank} interface.
>     *
>     * @return the Rank of this Card.
>     */
>    Rank getRank();
>
>    /**
>     * Returns one of the distinct values represented
>     * in the implementation of the {@link Suit} interface.
>     *
>     * @return the Suit of this Card.
>     */
>    Suit getSuit();
>
> }
>
Hint: java.lang.Comparator<T>
Hint II: java+comparable+vs+comparator
How to implement the Comparable interface using a Comparator?

[toc] | [prev] | [next] | [standalone]

#29524

On 08/03/2014 01:47 PM, Jeff Higgins wrote:
> Hint:
Once agin the Java Tutorials come through.
<http://docs.oracle.com/javase/tutorial/collections/interfaces/order.html>

[toc] | [prev] | [next] | [standalone]

#29526

On 08/03/2014 01:52 PM, Jeff Higgins wrote:
> On 08/03/2014 01:47 PM, Jeff Higgins wrote:
>> Hint:
Two of your classmates spend some of their spare time studying the
fine manual. They will soon be writing exciting Java programs for
fun and profit. See if you can pick them out. They have already
sussed out their * classmates.

[toc] | [prev] | [next] | [standalone]

#29531

On 8/3/2014 1:25 PM, Jeff Higgins wrote:
> On 08/03/2014 11:41 AM, Eric Sosman wrote:
>> On 8/3/2014 11:08 AM, Jeff Higgins wrote:
>>> On 08/01/2014 09:16 PM, Scott Dunning wrote:
>>>> Hello, I have an assignment for my summer class.  FYI, I'm super new to
>>>> programming in general and this is my first time with java and it's a
>>>> summer class so it's going super fast (please be nice!) lol.
>>>
>>> No. It seems to be going slowly. The last three assignments you've
>>> brought here are rehashes. Surely by now you should have gone into
>>> interfaces and collections.
>>>
>>> Your Card class will be more easily used if it implement the
>>> java.lang.Comparable<T> interface
>>
>>      I'd advise against this,
>
>>  because the ordering depends not on the
>> Card, but on the rules of whatever game is being played.
>
> Exactly.
>
>>  There are
>> games where Ace is high, games where it is low, games where it can
>> be either at the discretion of the player, and for all I know there
>> may be games where Ace can lie between King and Deuce.  And then
>> there's the question of suit: How does the Seven of Hearts compare
>> to the Jack of Clubs? Would knowing whether Hearts are trumps affect
>> your answer?
>>
>>      Scott: Don't Go There; you'll just get lost.
>>
> Scott: If you don't go there you'll never find your way.
>
> package scratch;
>
> /**
>   * The face value of a {@link Card}.
>   *
>   * Rank specifies one of 13 distinct,
>   * implementation defined values and their order.

     "Poker" is the name for a popular family of card games in which
this approach Absolutely Will Not Work.  I've already mentioned that
Ace can be lower than Deuce, Deuce lower than Trey, ..., Queen lower
than King, and King lower than (oops!) Ace.  The "total ordering"
required by Comparable simply doesn't exist, and any attempt to
implement Comparable is just plain doomed.

     It gets worse: There are situations where Ace compares unequal
to Ace, that is, where one Ace compares lower/higher than another,
as in A 2 3 4 5 (the lowest possible straight) vs. T J Q K A (the
highest possible).  The result of `ACE.compareTo(ACE)' could be
negative, zero, or positive depending on the situation -- and the
compareTo() method doesn't have access to situational information.

     But wait! That's not all; it gets even worse still! There are
situations where the very same instance of an Ace is both high and
low at the same time!  Ordinary poker variants award the entire pot
to the highest-ranking hand, but "high-low" variants divide it between
the highest and the lowest hand.  If you hold A 2 3 4 5 you have a
chance of being both the lowest *and* the highest: Call the Ace low
and you've got a straight (not a rock-crusher, but a fairly good hand),
or call it high and have a bust with one high card (not the worst
possible hand, but pretty weak).  In this situation the very same
instance of Ace is both higher *and* lower than Deuce, both higher
*and* lower than itself!  And you want to capture this in Comparable?

     Given the variety of card games, Comparable is a wrong-headed
approach for ranks, for suits, and even for hands.

     Scott: Don't Go There; you'll just get lost.

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29534

On 8/3/2014 3:00 PM, Eric Sosman wrote:
> On 8/3/2014 1:25 PM, Jeff Higgins wrote:
>> On 08/03/2014 11:41 AM, Eric Sosman wrote:
>>> On 8/3/2014 11:08 AM, Jeff Higgins wrote:
>>>> On 08/01/2014 09:16 PM, Scott Dunning wrote:
>>>>> Hello, I have an assignment for my summer class.  FYI, I'm super
>>>>> new to
>>>>> programming in general and this is my first time with java and it's a
>>>>> summer class so it's going super fast (please be nice!) lol.
>>>>
>>>> No. It seems to be going slowly. The last three assignments you've
>>>> brought here are rehashes. Surely by now you should have gone into
>>>> interfaces and collections.
>>>>
>>>> Your Card class will be more easily used if it implement the
>>>> java.lang.Comparable<T> interface
>>>
>>>      I'd advise against this,
>>
>>>  because the ordering depends not on the
>>> Card, but on the rules of whatever game is being played.
>>
>> Exactly.
>>
>>>  There are
>>> games where Ace is high, games where it is low, games where it can
>>> be either at the discretion of the player, and for all I know there
>>> may be games where Ace can lie between King and Deuce.  And then
>>> there's the question of suit: How does the Seven of Hearts compare
>>> to the Jack of Clubs? Would knowing whether Hearts are trumps affect
>>> your answer?
>>>
>>>      Scott: Don't Go There; you'll just get lost.
>>>
>> Scott: If you don't go there you'll never find your way.
>>
>> package scratch;
>>
>> /**
>>   * The face value of a {@link Card}.
>>   *
>>   * Rank specifies one of 13 distinct,
>>   * implementation defined values and their order.
>
>      "Poker" is the name for a popular family of card games in which
> this approach Absolutely Will Not Work.  I've already mentioned that
> Ace can be lower than Deuce, Deuce lower than Trey, ..., Queen lower
> than King, and King lower than (oops!) Ace.  The "total ordering"
> required by Comparable simply doesn't exist, and any attempt to
> implement Comparable is just plain doomed.
>
>      It gets worse: There are situations where Ace compares unequal
> to Ace, that is, where one Ace compares lower/higher than another,
> as in A 2 3 4 5 (the lowest possible straight) vs. T J Q K A (the
> highest possible).  The result of `ACE.compareTo(ACE)' could be
> negative, zero, or positive depending on the situation -- and the
> compareTo() method doesn't have access to situational information.
>
>      But wait! That's not all; it gets even worse still! There are
> situations where the very same instance of an Ace is both high and
> low at the same time!  Ordinary poker variants award the entire pot
> to the highest-ranking hand, but "high-low" variants divide it between
> the highest and the lowest hand.  If you hold A 2 3 4 5 you have a
> chance of being both the lowest *and* the highest: Call the Ace low
> and you've got a straight (not a rock-crusher, but a fairly good hand),
> or call it high and have a bust with one high card (not the worst
> possible hand, but pretty weak).  In this situation the very same
> instance of Ace is both higher *and* lower than Deuce, both higher
> *and* lower than itself!  And you want to capture this in Comparable?
>
>      Given the variety of card games, Comparable is a wrong-headed
> approach for ranks, for suits, and even for hands.
>
>      Scott: Don't Go There; you'll just get lost.

I must admit that I can not follow you.

The fact that different games may use a different ordering is
not an argument against Comparable<>.

Comparable<> is not the one and only ordering. Comparable<> is
just the natural ordering. It is perfectly valid to have a
Comparable<> with the natural ordering and a bunch of
Comparator<> to handle the context specific orderings.

Arne

[toc] | [prev] | [next] | [standalone]

#29535

On 03/08/14 20:26, Arne Vajhøj wrote:
> On 8/3/2014 3:00 PM, Eric Sosman wrote:
>> On 8/3/2014 1:25 PM, Jeff Higgins wrote:
>>> On 08/03/2014 11:41 AM, Eric Sosman wrote:
>>>> On 8/3/2014 11:08 AM, Jeff Higgins wrote:
>>>>> On 08/01/2014 09:16 PM, Scott Dunning wrote:

<snip>

>>      Given the variety of card games, Comparable is a wrong-headed
>> approach for ranks, for suits, and even for hands.
>>
>>      Scott: Don't Go There; you'll just get lost.
>
> I must admit that I can not follow you.
>
> The fact that different games may use a different ordering is
> not an argument against Comparable<>.
>
> Comparable<> is not the one and only ordering. Comparable<> is
> just the natural ordering. It is perfectly valid to have a
> Comparable<> with the natural ordering and a bunch of
> Comparator<> to handle the context specific orderings.

Exactly, and what better way to encapsulate the rules of a game than in 
a Comparator.

You can develop Deck and Shuffle and Hand etc etc and simply (well 
perhaps not 'simply') implement different games by implementing 
different Comparators ... Sounds 'OO' to me.


-- 
lipska the kat - treacherous feline.
Proudly nominated for IPOTY 2014 - LIGAF
GNU/Linux user #560883 - linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#29538

On 8/3/2014 3:26 PM, Arne Vajhøj wrote:
>[...]
> I must admit that I can not follow you.
>
> The fact that different games may use a different ordering is
> not an argument against Comparable<>.
>
> Comparable<> is not the one and only ordering. Comparable<> is
> just the natural ordering. It is perfectly valid to have a
> Comparable<> with the natural ordering and a bunch of
> Comparator<> to handle the context specific orderings.

     Although one could select different Comparators for different
games -- one for Ace-low, say, and another for Ace-high -- there
is no way a Comparator could work for "Ace-either" games like Poker
(and certainly not for "Ace-both" games like high-low Poker!).  Like
Comparable, Comparator reflects a _total ordering_ on the objects it
compares, and a total ordering must be transitive:

	If X < Y and Y < Z then X < Z, for all X,Y,Z.

In Poker, one can have

	Ace < Five and Five < Ten but Ten < Ace

... violating transitivity, so the ranks do not follow a total order.

     One could, of course, implement a Comparator (or a Comparable)
that broke the rules and violated its "contractual obligation" to
impose a total order.  But a Comparable/Comparator that didn't behave
as it should would make mockery of the claim

 > Your Card class will be more easily used if it implement the
 > java.lang.Comparable<T> interface

... because none of the Comparable- or Comparator-based utility
classes and methods would behave properly: Collections.sort(),
Arrays.binarySearch(), SortedMap(), ...  Something that simply
doesn't work cannot be "more easily used."

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29539

On 8/3/2014 4:49 PM, Eric Sosman wrote:
> On 8/3/2014 3:26 PM, Arne Vajhøj wrote:
>> [...]
>> I must admit that I can not follow you.
>>
>> The fact that different games may use a different ordering is
>> not an argument against Comparable<>.
>>
>> Comparable<> is not the one and only ordering. Comparable<> is
>> just the natural ordering. It is perfectly valid to have a
>> Comparable<> with the natural ordering and a bunch of
>> Comparator<> to handle the context specific orderings.
>
>      Although one could select different Comparators for different
> games -- one for Ace-low, say, and another for Ace-high -- there
> is no way a Comparator could work for "Ace-either" games like Poker
> (and certainly not for "Ace-both" games like high-low Poker!).  Like
> Comparable, Comparator reflects a _total ordering_ on the objects it
> compares, and a total ordering must be transitive:
>
>      If X < Y and Y < Z then X < Z, for all X,Y,Z.
>
> In Poker, one can have
>
>      Ace < Five and Five < Ten but Ten < Ace
>
> ... violating transitivity, so the ranks do not follow a total order.
>
>      One could, of course, implement a Comparator (or a Comparable)
> that broke the rules and violated its "contractual obligation" to
> impose a total order.  But a Comparable/Comparator that didn't behave
> as it should would make mockery of the claim

So maybe a game need something more advanced than a Comparator<>, but
that does still not show that a Card class should not be
Comparable<>.

Arne

[toc] | [prev] | [next] | [standalone]

#29558

Arne Vajhøj wrote:

> So maybe a game need something more advanced than a Comparator<>, but
> that does still not show that a Card class should not be
> Comparable<>.

How about: "Because making it easier to get things wrong than to get things 
right is rarely a good idea" ?

    -- chris 

[toc] | [prev] | [next] | [standalone]

#29746

On 8/4/2014 3:32 PM, Chris Uppal wrote:
> Arne Vajhøj wrote:
>> So maybe a game need something more advanced than a Comparator<>, but
>> that does still not show that a Card class should not be
>> Comparable<>.
>
> How about: "Because making it easier to get things wrong than to get things
> right is rarely a good idea" ?

You think that because Card is Comparable<> then people would mess up
the core game logic of comparing hands?

I am not so worried about that. That is one thing that will typical
be very well-defined in the game rules.

Arne

[toc] | [prev] | [next] | [standalone]

#29759

Arne Vajhøj wrote:

> > How about: "Because making it easier to get things wrong than to get
> > things right is rarely a good idea" ?
>
> You think that because Card is Comparable<> then people would mess up
> the core game logic of comparing hands?
>
> I am not so worried about that. That is one thing that will typical
> be very well-defined in the game rules.

What I'd expect to see is people attempting to use the Comparable<> interface 
regardless of the game rules.  And then patching their logic with ad-hoc 
special cases when they realised that the pre-defined Comparable<> didn't do 
exactly what the rules require.

Better not to set traps for the unwary.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#29878

In article <Jd6dnaYWEdDi7WnOnZ2dnUVZ8jidnZ2d@bt.com>, Chris Uppal 
(chris.uppal@metagnostic.REMOVE-THIS.org) says...

> > You think that because Card is Comparable<> then people would mess up
> > the core game logic of comparing hands?
> 
> What I'd expect to see is people attempting to use the Comparable<> interface 
> regardless of the game rules.  And then patching their logic with ad-hoc 
> special cases when they realised that the pre-defined Comparable<> didn't do 
> exactly what the rules require.
> 
> Better not to set traps for the unwary.

Better not use Comparable at all. Put a Comparator implementation in sme 
public final field and use that instead, always.

While overriding hashCode and equals is often beneficial and correct, I 
find that implementing Comparable is often a mistake.

I've hat it numerous times that I ran into problems because some people 
implemented Comparable for some special purpose (like "sorting by 
name"), but did not implement equals and hashCode accordingly, because 
that would have messed up the rest (like equals was "equality by ID" or 
"all fields equal" and that must not be changed). What you end up with 
is objects that are equal according to "compareTo", but not equal 
according to "equals" and "hashCode".

And correcting that mistake later is a pain in the butt:
Try to find all arrays, lists, sets and other usages, where this class 
of objects might end up, search where these may be sorted or comparedto 
use a Comparator object instead.

Sure, you might run your test suite and set a breakpoint in the 
comparable implementation, but that will only take you so far as your 
test suite goes and let's be real: most programs have a rather lousy 
unit test coverage.

To put it with Glenn Danzig's words: "Do you want to cross that line? 
Cause it's a long way back from hell, and you don't want to go with me."

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

[toc] | [prev] | [next] | [standalone]

#29907

Brixomatic wrote:
> In article <Jd6dnaYWEdDi7WnOnZ2dnUVZ8jidnZ2d@bt.com>, Chris Uppal
> (chris.uppal@metagnostic.REMOVE-THIS.org) says...
>
> > > You think that because Card is Comparable<> then people would mess up
> > > the core game logic of comparing hands?
> >
> > What I'd expect to see is people attempting to use the Comparable<>
> > interface regardless of the game rules.  And then patching their logic
> > with ad-hoc special cases when they realised that the pre-defined
> > Comparable<> didn't do exactly what the rules require.
> >
> > Better not to set traps for the unwary.
>
> Better not use Comparable at all. Put a Comparator implementation in sme
> public final field and use that instead, always.

Yes. Or a bunch of 'em for commonly occurring situation (Ace high, Ace low, 
...).   Though I'd be inclined to skip the predefined interfaces altogether 
(for cards) since the comparison is more likely to be between /hands/.


> While overriding hashCode and equals is often beneficial and correct, I
> find that implementing Comparable is often a mistake.
>
> I've hat it numerous times that I ran into problems because some people
> implemented Comparable for some special purpose (like "sorting by
> name"), but did not implement equals and hashCode accordingly, because
> that would have messed up the rest (like equals was "equality by ID" or
> "all fields equal" and that must not be changed). What you end up with
> is objects that are equal according to "compareTo", but not equal
> according to "equals" and "hashCode".

That makes sense.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#29908

On 9/4/2014 10:14 AM, Chris Uppal wrote:
> [... about Comparable/Comparator for Cards ...]
>
> Yes. Or a bunch of 'em for commonly occurring situation (Ace high, Ace low,
> ...).   Though I'd be inclined to skip the predefined interfaces altogether
> (for cards) since the comparison is more likely to be between /hands/.

     It depends on the game at, er, hand.  There's been much mention
of Poker in this thread, a game in which hands are in fact compared
(but not in a way Comparable/Comparator can always model).  But games
like Bridge do not compare hands, though they compare cards.

     ... and the comparison is not amenable to Comparable.  For example,
if the Ace of Spades, King of Spades, seven of Clubs, and four of Hearts
are played to one trick, which card ranks the highest?  We can infer
that it's not the King of Spades, but any of the other three cards might
be the one that takes the trick:

     - The Ace wins if either it or the King was led first and neither
       Hearts nor Clubs are trumps, or if Spades are trumps,

     - The seven wins if Clubs are trumps, or if it was led first and
       neither Spades nor Hearts are trumps,

     - The seven wins if Hearts are trumps, or if it was led first and
        neither Spades nor Clubs are trumps.

     To implement this properly, I think you'd need a suite of different
Comparators: One for each possible first-led suit, and one for each
possible choice of trump suit.  (Some economies are possible: The
Comparator for a no-trump contract with a Spade lead would give the
same result as that for a Spades contract with a spade lead, so I think
you'd only need sixteen different Comparators, not twenty.)

     Tomorrow, we'll discuss Slap-Jack.  ;-)

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29910

Eric Sosman wrote:
> On 9/4/2014 10:14 AM, Chris Uppal wrote:
> > [... about Comparable/Comparator for Cards ...]
> >
> > Yes. Or a bunch of 'em for commonly occurring situation (Ace high, Ace
> > low, ...).   Though I'd be inclined to skip the predefined interfaces
> > altogether (for cards) since the comparison is more likely to be
> > between /hands/.
>
>     It depends on the game at, er, hand.  There's been much mention
> of Poker in this thread, a game in which hands are in fact compared
> (but not in a way Comparable/Comparator can always model).  But games
> like Bridge do not compare hands, though they compare cards.

True. Or at least, I shall happily take your word for it -- I have never been 
able to make any sense at all of Bridge[*].

And there are games where comparison, as such, doesn't come into it at all 
(Cheat is the example I'm thinking of -- one of the few card games I have ever 
enjoyed playing and felt I truly understood :-).

    -- chris

[*] Always feels an axiom system with some of the axioms missing. 

[toc] | [prev] | [next] | [standalone]

#29912 — [OT] Re: Help with Deck of cards assignment and getting it to deal...

On 9/4/2014 11:12 AM, Chris Uppal wrote:
> Eric Sosman wrote:
>> [...]
>>      It depends on the game at, er, hand.  There's been much mention
>> of Poker in this thread, a game in which hands are in fact compared
>> (but not in a way Comparable/Comparator can always model).  But games
>> like Bridge do not compare hands, though they compare cards.
>
> True. Or at least, I shall happily take your word for it -- I have never been
> able to make any sense at all of Bridge[*].
>
> And there are games where comparison, as such, doesn't come into it at all
> (Cheat is the example I'm thinking of -- one of the few card games I have ever
> enjoyed playing and felt I truly understood :-).
>
> [*] Always feels an axiom system with some of the axioms missing.

     Bridge is a lot like Java: The fundamentals are simple, but
nobody understands the class libraries.

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29922

On Thu, 04 Sep 2014 10:55:18 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

>On 9/4/2014 10:14 AM, Chris Uppal wrote:
>> [... about Comparable/Comparator for Cards ...]
>>
>> Yes. Or a bunch of 'em for commonly occurring situation (Ace high, Ace low,
>> ...).   Though I'd be inclined to skip the predefined interfaces altogether
>> (for cards) since the comparison is more likely to be between /hands/.
>
>     It depends on the game at, er, hand.  There's been much mention
>of Poker in this thread, a game in which hands are in fact compared
>(but not in a way Comparable/Comparator can always model).  But games
>like Bridge do not compare hands, though they compare cards.
>
>     ... and the comparison is not amenable to Comparable.  For example,
>if the Ace of Spades, King of Spades, seven of Clubs, and four of Hearts
>are played to one trick, which card ranks the highest?  We can infer
>that it's not the King of Spades, but any of the other three cards might
>be the one that takes the trick:

     Poker with wild cards would be another fun one to try.  And after
determining that two hands are the same with regard to what card
values have been assigned to the wild cards, then you have to count
wild cards as the fewer wild cards, the higher the hand ranks.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web