On 8 Oct 2016 at 15:32, Christopher Sean Hilton wrote:

> After more investigation the generator isn't working properly with
> postgresql either. I've done a bunch of work trying to find this my
> current theory is that somehow the random number generator's state is
> being change out of my control due to my using. I think it may be
> reseeding itself to ensure high quality. I'm thinking this because I
> just discovered that the results are exactly the same for the first
> half of the sector and then they diverge. If indeed the random number
> generator is reseeding itself then I can handle that too.

I'm going to repeat a suggestion I made in private mail in case
there's anybody else out there doing system/character/whatever
generation.

For testing the algorithms/routines, you *don't* want to use the
random number generator. Instead you want to generate each of the
possible rolls *once*

That way you exhaustively test *all* the paths thru the algorithm in
the shortest possible time.

Here's an example in BASIC using the rules from the Traveller Book

FOR Size = 2 to 12 : REM 2d-2
  size = size-2 :REM range 0 to 10
  FOR ATM = 2 to 12 : REM 2d-7 + size
    atm = atm-7 : REM range -5 to 5
    atm = atm+size : REM range -5 to 15
    IF size = 0 THEN ATM = 0 :REM range -4 to 15
    REM atm less than zero is going to be a problem, yes?
    if atm < 0 then ATM =0 :REM range 0 to 15
    FOR hydro = 2 to 12 : REM 2d-7+ atm
      hydro = hydro-7 :REM range -5 to 5
      hydro = hydro +atm : REM range  -5 to 20
      if size = 0 then hydro = 0
      if atm < 2 then hydro = 0
      if atm > 9 then hydro=hydro-4
      rem stick logic to save results here
    NEXT hydro
  NEXT atm
NEXT size

When I ran something like this way back in the 80s, I
first did a run with logic to save the mave and min for each
variable.

Theose told me what range I had to deal with. And spotted bugs like
the atm less than zero problem.

Once I fixed the less than zero problem, I could set up 3 dimensional
array with a dimension for each variable (size, atm & hydro) all
dimensioned from 0 to the max possible value.

Then at the "stick logic here" bit, I'd add 1 to the value of the
appropriate element of the array.

At the end I could print out all possible results with how often they
occured. (note that this won't be the actual frequency because you
are using a flat 2-12 distribution instead of the sum of two 1-6
distributions)

Repeat this sort of thing for each "independent" section of the
generation.

Then try it on the next one. In this case, that'd be pop, law and
gov.

Once you get the bugs out of *that* then you can combine the two with
all the nested loops and add stuff like TL and trade codes.

System generation gets a lot messier, but taking it step by step with
exhaustive testing of all possible rolls like this, you can spot the
"gotchas" and the "we never thought of that" situations.

Unlike testing with generated random numbers, where you may never get
some combos, you will have tested every single possible rool and
combo. So you'll have caught all the "specification level" (is what
the rules say) bugs, and a lot of the other bugs as well.

You'll still have to figure out what to do with the stuff they didn't
think of in the rules (like negative numbers for hydro or ATM).

Fortunately, *most* of the time the fix is obvious. Where it isn't
you just note it as a "house rule" if the program is just for you and
your players, or list it as a "here's how I decided to handle X" if
you are going to distribute it.

--
Leonard Erickson (aka shadow)
shadow at shadowgard dot com