At 07:11 AM 5/31/02 -0700, drieux wrote: >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....
Fair enough.. but in the mean time, since nothing deletes or inserts from %ModuleHash, make it an array. And there's no good reason to put 'hash' in the name of a variable, you can tell it's a hash by looking at it. I haven't looked at the 300 coins thread so may be way off base, but just from the code alone, nothing adds to or deletes from %decrHash either, so that can be an array also. If you're going to replace these constructs later on for flexibility, it looks like the same amount of work whether you're starting from a hash or an array... for instance your code assumes that the keys 1 thru 6 are all defined in %decrHash. It looks like a fundamental assumption that's best represented by an array... but you could make it smarter later on by tieing the array. -- Peter Scott Pacific Systems Design Technologies Boston Perl Classes in July: http://www.perldebugged.com/ http://stemsystems.com/class/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
