Mark Walsh on Tue, 10 Jan 2006 11:36:01 -0600 (CST)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [s-d] Antonio votes

On: 1/10/06 8:54:54 AM Antonio sent:
> Subject: Re: [s-d] Antonio votes
> >>
> >> For an example it would be perfectly legal IMHO to start with a 1 for 
> >> Wonko and end with 16 for Antonio.
> >>
> > That's kinda how I feel about it too. the initial ordering really
> > make a difference, as long as it's fixed before the dice.
> Agreed.
> Although I still think that an algorithm that is completely independent 
> of starting order is to be preferred, if only because you get to send 
> one less message to the list (the one in which you declare the starting 
> state).
> 	Antonio
I'm not so sure about that.
The Ministerial message that recognizes the reordering could declare
the initial state. Examples:
1) The order in which the items now appear on the Wiki page 
where they are displayed.
This is verifiable by the time stamp on the edits of the page.
2) The list will be ordered alphabetically by (some field name).
Players are now listed in the Roster in this fashion (although I 
beleive that a sort of present Players would probably place 
comex last by virtue of the lower case 'c'. The order could be
specified as case insensitive).
3) In ascending order of Genechip Holdings (for Players),
But what then if two players have identical holdings?

Numbering sequentially (that is, serializing) an existing list
if it is not already numbered seems the way to go. And yes,
it should be stipulated that the initial order is defined before
any randomizing method is initiated, or that the very first step
in that process is the statement of the initial order, however
that is determined.

Apologies to all for being so passionate (or obstinate if you
prefer) about this matter. My thinking was that a need to
define a reordering process is called for, and in light of comex's
Tweak, could be needed shortly. I had actually planned to
submit a prop that does just what that Tweak does, but on an
nweekly basis. Given the traffic on the matter, I guess I touched
a nerve, and that's good. Many worthy suggestions were posited
as to a means of executing this task. Wonko, in particular, has
suggested a far reaching database scheme for all Objects (which
it appears the game is now composed of). Using eir beloved
Python tools and commands would make sense in that case.
As of now, I don't have a clue, and am loath to embrace the
syntax without some practical experience (I don't even know how
to see the code of existing scripts without making an error occur).
Anyway, enough! We'll see what shakes.


spoon-discuss mailing list