[Newbies] Arrays within arrays

[Yoshiki Ohshima]

At Fri, 5 Sep 2008 02:59:08 -0700,
Charles Gray wrote:
> 
> Gee, that was easy. Thanks. I never guessed that you had to leave
> the #'s off inside the array.

  I still wonder what version of image you are using.  In the image I'm
using, I can evalute:

#((0 0 0 0) (0 0 0 0) (0 0 0 0) (0 0 0 0) (0 0 0 0) (0 0 0 0)
 (2 1 0 0) (8 4 0 1) (14 6 0 2) (30 12 1 4)) =
#(#(0 0 0 0) #(0 0 0 0) #(0 0 0 0) #(0 0 0 0) #(0 0 0 0) #(0 0 0 0)
 #(2 1 0 0) #( 8 4 0 1) #(14 6 0 2) #(30 12 1 4))

and get true.

> Those particular numbers
> don't mean anything. They were just an example of my problem. In my bridge dealer program, there are four sets of values
> assigned to each card. The first two numbers give the relative strength of a card when playing in a suit contract and
> when playing in a notrump contract. The numbers are based on the extensive double-dummy analysis performed by Thomas
> Andrew. The third number is is what some players of the Moscito bidding system call AKQ or slam points, and the fourth
> number is simply a binary representation that I use for determining loser count. I wasn't trying to be sneaky. The real
> numbers from 8 up to ace are:
> #((2 1 0 0) (4 3 0 1) (10 6 0 2) (23 14 0 4) (43 27 1 8) (74 51 2 16) (115 82 3 16)).
> The totals are #(271 184 6 31). In the case of the first two numbers, I add them up for each suit, multiply by ten and
> divide by the total giving me a number from 0 to 40 that is similar to the work point count commonly used to evaluate
> bridge hands using 4, 3, 2, 1 for ace through jack for strength evaluation. Now that I think about it I can simply
> multiply each of the original numbers by 10 to eliminate that step.
> 
> I know that's more than you what to know about the numbers but you asked. The traditional 4, 3, 2, 1 evaluation
> undervalues aces and kings. Different numbers are used for suit play and notrump play because there is no chance that a
> card will be trumped during play. A human would find it difficult to use this method of evaluation but it is no problem
> for a computer. By the way, I was just converting procedures I had written in Forth and Ruby to Smalltalk. Now if I
> could just learn not to think in sequential terms.

  Thank you!

-- Yoshiki