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 3 of 3 — ← Prev page 1 2 [3]

#29926

On 8/20/2014 5:50 AM, Chris Uppal wrote:
> 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.

Avoid adding stuff that could be used wrong seems as a hopeless
strategy to me.

Arne

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

#29931

On 9/7/2014 9:45 PM, Arne Vajhøj wrote:
> On 8/20/2014 5:50 AM, Chris Uppal wrote:
>> 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.
>
> Avoid adding stuff that could be used wrong seems as a hopeless
> strategy to me.

     Avoiding stuff that is seldom right seems worth while, though.

-- 
esosman@comcast-dot-net.invalid

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

#29542

On 08/03/2014 04: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.

In my proposed interface Ace is a valid Rank but Five and Five is not.
In my proposed interface I cannot see where any contract is broken by
run time variation of the natural ordering of the Rank. Sure, comparing
one Rank object at different times or places and getting different
results might seem odd but not wrong. I may be though. Please correct
me if this is the case.

>      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."
>

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

#29553

On 8/3/2014 5:19 PM, Jeff Higgins wrote:
> On 08/03/2014 04: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.
>
> In my proposed interface Ace is a valid Rank but Five and Five is not.

     What rank, then, does the Five of Spades have?

> In my proposed interface I cannot see where any contract is broken by
> run time variation of the natural ordering of the Rank. Sure, comparing
> one Rank object at different times or places and getting different
> results might seem odd but not wrong. I may be though. Please correct
> me if this is the case.

     See the Javadoc for Comparable.  The very first sentence reads:

	"This interface imposes a total ordering on the objects of each
	class that implements it."

The Javadoc for Comparator begins with a sentence fragment rather than
with a sentence, but that fragment reads:

	"A comparison function, which imposes a _total ordering_ on some
	collection of objects."

     Observe further that both interfaces expose the imposed total order
by way of pairwise comparisons; neither interface has a method to sort
N objects (much less "all" objects) simultaneously.  Therefore, when we
try to investigate the imposed total order we must do so by comparing
one pair at a time.  So: We discover X < Y *now* and Y < Z *next*, and
by virtue of the total order we can conclude X < Z *hereafter*.  We
don't even need to make the comparison; we already know the answer --
*if* there's a total ordering.  If we make the comparison anyhow and
discover Z < X we must conclude that there is *not* a total ordering,
and that the Comparable or Comparator does not behave as advertised.

     Lest you think this is all "theoretical" or something, consider how
Arrays.binarySearch() works: It compares the sought key S to some object
in the array, discovers S < X, and eliminates all elements >= X from
further consideration.  Is it justified in eliminating those elements?
Only if the total ordering holds.

     If you don't like arrays and prefer collections, consider TreeMap:
Can you explain how a TreeMap could work in the absence of a total
ordering?  Or how it could work if the ordering were somehow changed
*after* some affected keys had already been inserted?  "Ah, the sought
key compares greater than the key of the root node, so I'll follow the
right branch of the tree -- oh, wait, maybe I should follow both
branches, just in case the ordering has changed ..."

     One could (as Arne Vajhøj pointed out) implement Comparable anyhow
for Ranks, Suits, Cards, and Hands, and one could implement it in a way
that satisfies all Java's expectations.  But such Comparables would not
be able to capture the rules of popular card games, because those rules
do not always admit of a total ordering.  I do not deny that Comparable
could be implemented, but I maintain that

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

is false for many card games.

-- 
esosman@comcast-dot-net.invalid

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

#29560

On 08/04/2014 08:14 AM, Eric Sosman wrote:
> On 8/3/2014 5:19 PM, Jeff Higgins wrote:
>> On 08/03/2014 04: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.
>>
>> In my proposed interface Ace is a valid Rank but Five and Five is not.
>
>      What rank, then, does the Five of Spades have?

Does the word Rank connote a hand of cards to you?
Or that the Rank of a Card has the two attributes,
face value and suit? For me the rank(Rank) of a Card
is its face value, Ace, Two - Ten, Jack, Queen, King.

Have you looked at the interfaces I've proposed?
I will reproduce them below for reference.
I'm not especially proud of the wording of some of the Javadoc comments,
but we can leave that for later.

The Five of Spades would be a Card.
A Card has a Comparable<Rank> Rank(its face value),
and a Comparable<Suit> Suit,(its Suit)
so in this case its Rank is Five and Suit is Spades.

In my card game, which I haven't produced, much less tested,
I ask to compare two Cards: my Cards compareTo calls its Ranks
compareTo method which looks in the rule book and discovers
that at this point in this particular game your Five is greater
than my Four, Cards compareTo then calls its Suits compareTo
which determines that at this point your Spades is greater than
my Club, Cards compareTo then looks in the rule book and determines
that at this moment in this game my Card is greater than your Card.
Since this is my one card one hand game I win.

Nowhere have I described a Comparable Hand of cards - which seems to
me to to be what you are arguing about - or a Game of Cards

[snip]

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

This statement may very well be wrong because
Scott's Card class is not Jeff's Card class.
But not because of some total ordering that
Comparable requires.
If you consider that weaseling - so be it.

>
> is false for many card games.


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> {

}

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

#29561

On 08/04/2014 08:03 PM, Jeff Higgins wrote:
Ah. Now I see the problem.
"This interface is a member of the Java Collections Framework."
It's sacrosanct. Not to used for mundane comparisons - especially
when one might violate the terms of use. If I had used my JComparable
all of this lathering could have been avoided. And the potential
for disaster by someone inadvertently placing my Rank in a TreeMap also.

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

#29536

On 08/03/2014 03:00 PM, Eric Sosman wrote:
>      Given the variety of card games, Comparable is a wrong-headed
> approach for ranks, for suits, and even for hands.
>
Perhaps, but just for my own enlightenment, allow me one more interface
and then describe a *simple* game that that cannot be implemented given
the provided interfaces.

package scratch;

import java.util.Collection;

/**
  * A Card game controller.
  * While we have hands to play, compare hands.
  *
  * @author jeff
  *
  */
public interface Ruler extends Iterable<Ruler>, 
Comparable<Collection<Card>> {

}

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

#29537

On 08/03/2014 03:45 PM, Jeff Higgins wrote:
> On 08/03/2014 03:00 PM, Eric Sosman wrote:
>>      Given the variety of card games, Comparable is a wrong-headed
>> approach for ranks, for suits, and even for hands.
>>
> Perhaps, but just for my own enlightenment, allow me one more interface
> and then describe a *simple* game that that cannot be implemented given
> the provided interfaces.
>
> package scratch;
>
> import java.util.Collection;
>
> /**
>   * A Card game controller.
>   * While we have hands to play, compare hands.
>   *
>   * @author jeff
>   *
>   */
> public interface Ruler extends Iterable<Ruler>,
> Comparable<Collection<Card>> {
>
> }
>
>
Well, that could probably have been done better but you get my drift.

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

#29541

On 8/3/2014 4:01 PM, Jeff Higgins wrote:
> On 08/03/2014 03:45 PM, Jeff Higgins wrote:
>> On 08/03/2014 03:00 PM, Eric Sosman wrote:
>>>      Given the variety of card games, Comparable is a wrong-headed
>>> approach for ranks, for suits, and even for hands.
>>>
>> Perhaps, but just for my own enlightenment, allow me one more interface
>> and then describe a *simple* game that that cannot be implemented given
>> the provided interfaces.
>>
>> package scratch;
>>
>> import java.util.Collection;
>>
>> /**
>>   * A Card game controller.
>>   * While we have hands to play, compare hands.
>>   *
>>   * @author jeff
>>   *
>>   */
>> public interface Ruler extends Iterable<Ruler>,
>> Comparable<Collection<Card>> {
>>
>> }
>>
>>
> Well, that could probably have been done better but you get my drift.

     I think so.  However, I've already mentioned the "high-low" types
of Poker, where a single hand can be both higher and lower than another.
I gave one example upthread; here's another:

     With Aces high, A A A 7 7 is a "full house," a very strong hand.
It is just a little bit stronger than K K K J J, another full house,
because when two full houses meet they are ranked by their triples:
In this case, AAA beats KKK so the first hand is higher.  But play
the Aces low instead, and now KKK beats AAA so the second hand is
higher.  If the deal's final showdown involved these two hands, the
first could be *both* high and low, and win the entire pot by
trapping the second hand "in between."

     Your challenge, then, should you choose to accept it: Write a
compareTo() method for which AAA77.compareTo(KKKJJ) returns a
value that is simultaneously positive and negative.  Maybe when
quantum computing comes of age ...

     Yes, okay, I see your "*simple*" -- but I reject it as weasel-
wording: Confronted with a game for which your approach won't work,
you could just say "Oh, but that's not *simple* in the way I choose
to define it."  Problem-avoidance is a viable strategy sometimes, but
it shouldn't be mistaken for problem-solving.

-- 
esosman@comcast-dot-net.invalid

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

#29543

On 08/03/2014 05:05 PM, Eric Sosman wrote:
> On 8/3/2014 4:01 PM, Jeff Higgins wrote:
>> On 08/03/2014 03:45 PM, Jeff Higgins wrote:
>>> On 08/03/2014 03:00 PM, Eric Sosman wrote:
>>>>      Given the variety of card games, Comparable is a wrong-headed
>>>> approach for ranks, for suits, and even for hands.
>>>>
>>> Perhaps, but just for my own enlightenment, allow me one more interface
>>> and then describe a *simple* game that that cannot be implemented given
>>> the provided interfaces.
>>>
>>> package scratch;
>>>
>>> import java.util.Collection;
>>>
>>> /**
>>>   * A Card game controller.
>>>   * While we have hands to play, compare hands.
>>>   *
>>>   * @author jeff
>>>   *
>>>   */
>>> public interface Ruler extends Iterable<Ruler>,
>>> Comparable<Collection<Card>> {
>>>
>>> }
>>>
>>>
>> Well, that could probably have been done better but you get my drift.
>
>      I think so.  However, I've already mentioned the "high-low" types
> of Poker, where a single hand can be both higher and lower than another.
> I gave one example upthread; here's another:
>
>      With Aces high, A A A 7 7 is a "full house," a very strong hand.
> It is just a little bit stronger than K K K J J, another full house,
> because when two full houses meet they are ranked by their triples:
> In this case, AAA beats KKK so the first hand is higher.  But play
> the Aces low instead, and now KKK beats AAA so the second hand is
> higher.  If the deal's final showdown involved these two hands, the
> first could be *both* high and low, and win the entire pot by
> trapping the second hand "in between."
>
>      Your challenge, then, should you choose to accept it: Write a
> compareTo() method for which AAA77.compareTo(KKKJJ) returns a
> value that is simultaneously positive and negative.  Maybe when
> quantum computing comes of age ...

I've not written an interface that compares Collections of Ranks
or Suits or Cards or Decks. A Game will require such behavior.
I still believe that behavior is implementable using the interfaces
I've described, and not uncleanly. Please describe a *simple*
situation that disproves my belief, I promise not to exercise my
Weasel options.

>      Yes, okay, I see your "*simple*" -- but I reject it as weasel-
> wording: Confronted with a game for which your approach won't work,
> you could just say "Oh, but that's not *simple* in the way I choose
> to define it."  Problem-avoidance is a viable strategy sometimes, but
> it shouldn't be mistaken for problem-solving.
>

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

#29545

On 08/03/2014 05:37 PM, Jeff Higgins wrote:

> I've not written an interface that compares Collections of Ranks
> or Suits or Cards or Decks. A Game will require such behavior.
> I still believe that behavior is implementable using the interfaces
> I've described, and not uncleanly. Please describe a *simple*
> situation that disproves my belief, I promise not to exercise my
> Weasel options.

"as an ook cometh of a litel spyr". There I've done it.
One variation of my all time favorite quotation becomes
apropos if we consider the interfaces I've proposed as
part of the "litel spyr".

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

#29546

On 08/03/2014 06:19 PM, Jeff Higgins wrote:
> On 08/03/2014 05:37 PM, Jeff Higgins wrote:
>
>> I've not written an interface that compares Collections of Ranks
>> or Suits or Cards or Decks. A Game will require such behavior.
>> I still believe that behavior is implementable using the interfaces
>> I've described, and not uncleanly. Please describe a *simple*
>> situation that disproves my belief, I promise not to exercise my
>> Weasel options.
>
> "as an ook cometh of a litel spyr". There I've done it.
> One variation of my all time favorite quotation becomes
> apropos if we consider the interfaces I've proposed as
> part of the "litel spyr".
>
>
Someone please tell me if I should be concentrating on this evening's
supper of ground beef patties instead of following 
comp.lang.java.programmer.

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

#29548

On 8/3/2014 6:34 PM, Jeff Higgins wrote:
> On 08/03/2014 06:19 PM, Jeff Higgins wrote:
>> On 08/03/2014 05:37 PM, Jeff Higgins wrote:
>>
>>> I've not written an interface that compares Collections of Ranks
>>> or Suits or Cards or Decks. A Game will require such behavior.
>>> I still believe that behavior is implementable using the interfaces
>>> I've described, and not uncleanly. Please describe a *simple*
>>> situation that disproves my belief, I promise not to exercise my
>>> Weasel options.
>>
>> "as an ook cometh of a litel spyr". There I've done it.
>> One variation of my all time favorite quotation becomes
>> apropos if we consider the interfaces I've proposed as
>> part of the "litel spyr".
>>
>>
> Someone please tell me if I should be concentrating on this evening's
> supper of ground beef patties instead of following
> comp.lang.java.programmer.

     Ground lamb would be my preference, but I have no quarrel
with ground beef and agree it might be tastier than c.l.j.p.
Good night!

-- 
esosman@comcast-dot-net.invalid

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

#29549

On 08/03/2014 08:37 PM, Eric Sosman wrote:
> On 8/3/2014 6:34 PM, Jeff Higgins wrote:
>> On 08/03/2014 06:19 PM, Jeff Higgins wrote:
>>> On 08/03/2014 05:37 PM, Jeff Higgins wrote:
>>>
>>>> I've not written an interface that compares Collections of Ranks
>>>> or Suits or Cards or Decks. A Game will require such behavior.
>>>> I still believe that behavior is implementable using the interfaces
>>>> I've described, and not uncleanly. Please describe a *simple*
>>>> situation that disproves my belief, I promise not to exercise my
>>>> Weasel options.
>>>
>>> "as an ook cometh of a litel spyr". There I've done it.
>>> One variation of my all time favorite quotation becomes
>>> apropos if we consider the interfaces I've proposed as
>>> part of the "litel spyr".
>>>
>>>
>> Someone please tell me if I should be concentrating on this evening's
>> supper of ground beef patties instead of following
>> comp.lang.java.programmer.
>
>      Ground lamb would be my preference, but I have no quarrel
> with ground beef and agree it might be tastier than c.l.j.p.
> Good night!
>
I'll take it with the grain of salt it lacks.

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

#29550

On 08/03/2014 08:40 PM, Jeff Higgins wrote:
> On 08/03/2014 08:37 PM, Eric Sosman wrote:
>> On 8/3/2014 6:34 PM, Jeff Higgins wrote:
>>> On 08/03/2014 06:19 PM, Jeff Higgins wrote:
>>>> On 08/03/2014 05:37 PM, Jeff Higgins wrote:
>>>>
>>>>> I've not written an interface that compares Collections of Ranks
>>>>> or Suits or Cards or Decks. A Game will require such behavior.
>>>>> I still believe that behavior is implementable using the interfaces
>>>>> I've described, and not uncleanly. Please describe a *simple*
>>>>> situation that disproves my belief, I promise not to exercise my
>>>>> Weasel options.
>>>>
>>>> "as an ook cometh of a litel spyr". There I've done it.
>>>> One variation of my all time favorite quotation becomes
>>>> apropos if we consider the interfaces I've proposed as
>>>> part of the "litel spyr".
>>>>
>>>>
>>> Someone please tell me if I should be concentrating on this evening's
>>> supper of ground beef patties instead of following
>>> comp.lang.java.programmer.
>>
>>      Ground lamb would be my preference, but I have no quarrel
>> with ground beef and agree it might be tastier than c.l.j.p.
>> Good night!
>>
> I'll take it with the grain of salt it lacks.
>
And have a nice day! :)

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

#29544

On 08/03/2014 05:05 PM, Eric Sosman wrote:

>      Your challenge, then, should you choose to accept it: Write a
> compareTo() method for which AAA77.compareTo(KKKJJ) returns a
> value that is simultaneously positive and negative.  Maybe when
> quantum computing comes of age ...
Noone have asked for any simultaneously positive and negative value.
Since you've thrown out the "total order" term (somewhere in these 
threads) I'll throw "predicate" in there.

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

#29563

On Fri, 01 Aug 2014 18:16:33 -0700, Scott Dunning
<scottwd01@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>Here are the directions...
>Design and implement a class called Card that represents a standard 
>playing card. 

See http://mindprod.com/jgloss/homework.html

There is no doubt most of the people in this forum could solve this
problem in their sleep. But solving the problem is not the task. The
goal is to improve your skill level.  
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

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

#29566

Roedy Green wrote:
> On Fri, 01 Aug 2014 18:16:33 -0700, Scott Dunning
> <scottwd01@gmail.com> wrote, quoted or indirectly quoted someone who
> said :
>
> > Here are the directions...
> > Design and implement a class called Card that represents a standard
> > playing card.
>
> See http://mindprod.com/jgloss/homework.html
>
> There is no doubt most of the people in this forum could solve this
> problem in their sleep. But solving the problem is not the task. The
> goal is to improve your skill level.

I take it that you have read neither the rest of Scott's post, not the 
subsequence discussion.

    -- chris 

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

#29567

I wrote:

> I take it that you have read neither the rest of Scott's post, not the
> subsequence discussion.

Sorry: spellchecker.

I take it that you have read neither the rest of Scott's post, nor the
subsequent discussion.

    -- chris 

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

#29879

On 02/08/14 02:16, 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.
  <snip>

Seeing as this thread just won't die I thought I'd offer the following.
It's just a bit of fun

I particularly like the shuffle method.

Go ahead, do your worst :-)

package cards.allinone;

import java.util.ArrayList;
import java.util.Collections;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Stack;


enum Suit {
	HERTS, CLUBS, DIAMONDS, SPADES
};

enum Rank {
	ACE, KING, QUEEN, JACK, TEN, NINE, EIGHT, SEVEN, SIX, FIVE, FOUR, 
THREE, TWO
};

class Card {

	private final Rank rank;
	private final Suit suit;
	
	public Card(Rank rank, Suit suit) {
		this.rank = rank;
		this.suit = suit;
	}

	public Rank getRank() {
		return rank;
	}

	public Suit getSuit() {
		return suit;
	}
}

class Deck {

	private Stack<Card> cards = new Stack<>();
	
	public Deck() {
		for(Suit suit: Suit.values()){
			for(Rank rank: Rank.values()){
				cards.push(new Card(rank, suit));
			}
		}
	}
	
	public void printDeck(){
		for(Card card: cards){
			System.out.println(card.getRank() + " of " + card.getSuit());
		}
	}
	
	public Boolean moreCards(){
		return !cards.empty();
	}
	
	public Card nextCard(){
		return cards.pop();
	}
	
	public void shuffle(){
		Collections.shuffle(cards);
	}
}

class Hand {
	
	private List<Card> cards = null;

	public Hand() {
		cards = new ArrayList<>();
	}
	
	public void addCard(Card card){
		cards.add(card);
	}
	
	public Card getCard(int index){
		return cards.get(index);
	}

	public void printHand(){
		for(int i = 0; i < cards.size(); i++){
			System.out.println("card " + i + ":" + cards.get(i).getRank() + " of 
" + cards.get(i).getSuit());
		}
	}
}

public class CardGame {

	private Deck deck = null;
	private Map<Integer, Hand> players = null;
	
	public CardGame() {
		deck = new Deck();
		deck.shuffle();
		players = new HashMap<>();
	}
	
	public void deal(int hands, int cardsPerHand){
		for(int i = 0; i < hands; i++){
			players.put(i, new Hand());
		}
		
		for(int i = 0; i < cardsPerHand; i++){
			for(int j = 0; j < hands; j++){
				players.get(j).addCard(deck.nextCard());
			}
		}
	}
	
	public void printHands(){
		for(Integer key: players.keySet()){
			System.out.println("Player " + key + " hand:");
			players.get(key).printHand();
			System.out.println("----------");
		}
	}
	
	public void play(){
		//?
	}

	public static void main(String[] args) {
		CardGame game = new CardGame();
		game.deal(4, 7);
		game.printHands();
	}
}



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

[toc] | [prev] | [standalone]

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

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

csiph-web