On Thursday, May 30, 2002, at 07:21 , Peter Scott wrote:
> At 06:20 PM 5/30/02 -0700, drieux wrote:
[..]
>> I had to do the initialization or the 'if' whined at me... and
>> yes logically it has to be $key > 0.
>
> I'm missing the reason this can't be an array. What is the domain range
> of the values of the integer keys, and what is the domain range of the
> number of keys?
Good question.... Given the fact that the indexes in the ModuloHash
run 0..9 - it might have been possible to do that.... and done
one of them
$take = $array_oh_choices[$index_val];
But I was also expecting to avoid some of this, since I did
not want to be tied to 0..N approach in the case of the
%decrHash - since when the pot is Zero - well, we would never
access that - since, 'game over'... That at present there
is a linear sequential ordering - is perchance an anomaly
in the data - and hence not something I wanted to count on.
In short putting them in hashes gives me a bit of flexibility
as to where the code evolves later on.
ultimately, I think we will be pulling
in the 'values' for these hashes from other sourcing tricks.
the code is at:
http://www.wetware.com/drieux/pbl/Auslanders/alt300.txt
and I am more playing with Lance's basic idea of a simple
player's game - and the evolution out of ungainly
if/then/elsif/.../else
branch tree's - cf: also
http://www.wetware.com/drieux/pbl/misc/HashSwitch.txt
Since at some point in the process I really think the
correct evolution would be away from 'fixed values' and
towards a 'go sub, beat state' HashSwitch of routines
based upon the current state of the pot....
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
