Playing cards.

Playing cards.

[rieachus]

I am working on a package which provides playing cards (and a surface) for programs that need.  I'm working on a program for testing bridge bidding systems. In other words to find hands that have no defined bid, or more than one bid in a must situation.

I would like to avoid using GTK if possible, to make installation easier, but if anyone already has such a package no need to duplicate effort.  Package spec is below.  If you want to discuss the random number issues, start a new discussion. I am sure it will get long quickly. ;-)

package Cards is
-- an object, model, view of a deck of cards and a playing surface.
-- decks can be single or double, regular or pinocle, with or without jokers.
-- Cards can be invisible, located on the table, or in a "hand", cards may be
-- assigned to a stack or stacks on the table, and are face up or down.

   type Card is private;
   type Deck is array (Integer range <>) of Card;

   type Decks is (Single, Double, Single_Pinochle, Double_Pinochle,
     One_Joker, Two_Jokers);

   function Create_Deck(Deck_Type: Decks) return Deck;

   type Rank is (Ace, Deuce, Trey, Four, Five, Six, Seven, Eight, Nine,
                 Ten, Jack, Queen, King);

   type Suit is (Spade, Heart, Diamond, Club, Joker);
   -- Joker rank is undefined, but can be assigned, for example when
   -- showing a poker hand.

   function Rank_Is (C: in Card) return Rank;
   function Suit_Is (C: in Card) return Suit;

   procedure Shuffle(D: in out Deck);
   -- all cards are set to in_hand, face_down. And
   -- well shuffled.  Long note:  A 52 card deck has 52! (~8x10^67)
   -- possible orders.  Game mechanics lower the number of different
   -- deals. For example there are only 5.36x10^28 differen bridge
   -- deals.  Obviosly, a 32-bit (around 4 billion if unsigned)
   -- pseudo-random number generator won't do justice. A 64-bit PRNG
   -- is not much better.  The method used here is to use four
   -- different unsigned PRNGs to assign values to cards in turn,
   -- then sort on these values.  It is a task left to the reader to
   -- compute what percentage of the possible bridge deals can
   -- actually occur. ;-)

   procedure Face (C: in Card);
   -- make a card visible;

   procedure Face_Down (C: in Card);
   -- show the back of the card if/when it is displayed.

   function Face_Up return Boolean;

   type Position is record
      X: Positive;
      Y: Positive;
   end record;

   procedure Create_Table(Far_Corner: Position := (320, 320));
   -- Initial value is really there it insure that tables always have sizes.

   procedure Play(C: Card; P: Position);
   -- move the card from its current location to the table and turn it face
   -- up if necessary.

   procedure Discard(C: Card; P: Position; Display: Boolean := True);
   -- same intent as Play but with the card face down, or completely gone
   -- from the display. Note that discarded cards are still part of the
   -- deck.

   procedure In_Hand(C: Card);
   -- place a card in the hand.

   function In_Hand (C: Card) return Boolean;

   function Hand return Deck;
   -- the deck in this case is an array of cards usually smaller than the
   -- original deck. returns a full array from 1 to n of the cards
   --  currently in the hand.

   procedure Sort_Hand (Suits: Boolean := True; Up: Boolean := True);
   -- sort the hand.  Suits first if suits is true; higher ranking cards
   -- get higher numbers if Up is true.

   procedure Update;
   -- Update the physical display to match the current card locations.
   -- Fancy transition graphics optional.

private

  type Real_Card;

  type Card is access all Real_Card;

  -- Model magic is going on here.  Creating a deck does not need to
  -- use the heap, and will usually create an array of Real_Cards on
  -- the stack.  When you leave the scope of a Deck, everything goes
  -- away in finalization.

end Cards;

Re: Playing cards.

[Nasser M. Abbasi]

On 3/26/2016 1:50 PM, rieachus@comcast.net wrote:

>
>     type Card is private;
>     type Deck is array (Integer range <>) of Card;
>

Is there a reason why not to use (Natural range <>)?

--Nasser

Re: Playing cards.

[rieachus]

> Is there a reason why not to use (Natural range <>)?

It seems like a simple question, but digging through my mind, I dug out why.

I have plans for this type, and all my plans involve indexes from 1 to n.  Someone else may have different plans, but that is their choice.  In my case though, I expect to do lots of arithmetic to arrive at the correct index.  Is it possible that some intermediate will have a zero or negative value?  Sure.  Should an Ada compiler try to do that gotcha range check?  No.  But if at some point there is a parameter or function return that should not be range checked, this works.

More, this tells the user of the package that any range checking will be bounds checking for a particular object.

Re: Playing cards.

[Randy Brukardt]

<rieachus@comcast.net> wrote in message 
news:060566e9-c555-4eee-a40d-8ed338643d9e@googlegroups.com...
>> Is there a reason why not to use (Natural range <>)?
>
>It seems like a simple question, but digging through my mind, I dug out 
>why.
>
>I have plans for this type, and all my plans involve indexes from 1 to n. 
>Someone
>else may have different plans, but that is their choice.  In my case 
>though, I expect
>to do lots of arithmetic to arrive at the correct index.  Is it possible 
>that some
>intermediate will have a zero or negative value?  Sure.  Should an Ada 
>compiler try
>to do that gotcha range check?  No.  But if at some point there is a 
>parameter or
>function return that should not be range checked, this works.

As I'm sure you know, all intermediate results in Ada are of the base type, 
and are never range checked. That only happens when the expression value is 
stored or otherwise consumed (i.e. used as an array index).

And in the rare case that someone needs negative numbers, they can use 
'Base. (i.e. Natural'Base).

But I would complain about using either Natural or Integer. That puts the 
range of the array as implementation defined, and it sometimes ends up 
smaller than one might expect. I always suggest using a dedicated type for 
anything other than throwaway uses. I suppose that's not quite as critical 
in this case, but then again, large indexes are just as goofy as negative 
ones for this use (what card deck has 100_000 cards?).

                                Randy.

Re: Playing cards.

[Dennis Lee Bieber]

On Mon, 28 Mar 2016 16:13:16 -0500, "Randy Brukardt" <randy@rrsoftware.com>
declaimed the following:

>ones for this use (what card deck has 100_000 cards?).
>
	If one counts all variants, Magic the Gathering may be getting close
(granted, a player deck is normally only around 60 cards... and current
tournament practice is to limit one to cards released in the last two years
-- but that could still be 2400 different cards from which to choose --
~275 cards per release, four release a year)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Playing cards.

[rieachus]

> As I'm sure you know, all intermediate results in Ada are of the base type, 
> and are never range checked. That only happens when the expression value is 
> stored or otherwise consumed (i.e. used as an array index).

Or when passed to a constrained parameter, and the gotcha that I did run into with Position.  I declared Position's component's Positive, and of course, they should be Natural to allow 0,0 as a location.

I've also started a restructuring--I realized that having a generic package is the right way to deal with choice of decks, maximum hand size, and possibly display type.  I'll probably wait until I have at least one running program before posting more.  But if anyone wants to help let me know.