-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike,

I have to thank you for this.  It helped me figure out the
correlation between the uniformity factor that I called x (which I
will be renaming in this post to u (don't worry I'll mark it
clearly)).

> Brendan Moran wrote:
> >
> > Looks great, mike, but try setting the initial bias
> > values to 42,42,42,43,43,43
> > I think you'll find that the result is having code
> > that fits better in a PIC.  Those bias values will
> > always sum to 255.
> >
> > Like I said, similar ideas, only mine was designed
> > with 8-bit math in mind.  I could run it on a 12C
> > device, which is a great benefit.
>
>  Brendan,
> I can't believe you have no one spare register to
> hold 16 bit sum.

You're right, mike, it's not a big deal to use one more register.
It's just a little nicer to not use that extra one, it's just a
little easier to do, and if I were to attempt to put this on a
PIC12C50X, all the space I can save counts ;)

> And is it a big trouble to add
> six 8-bit registers into 16-bit two registers value
> using carry bit for example?

I know how to do a 16-bit add.  It's not difficult.  It's just that
it adds that one more level of complexity.

> Are these 12CXXX so weak?

I have heard many people say that the PIC12CXXX are amazing little
controllers.  But for all that, the code size limitation is there.
They have close to the same instruction set as the PIC16F series (a
few differences)

>  I tried 42...43; the result is too predictable.

Fair enough, I'll accept that.  But I would like to know if you
tested your random number generator's randomness first, and if so,
how did you test it, and how you define "good enough".

Now, with that little criticism (sorry 'bout that) I will say that
you're probably right.  That would, I expect, produce a result that
is too predictable.  I can see how that would happen.

But, thanks to you, I finally have figured out how to correlate the
expression that I wrote a few days ago with the algorithm that we
both came up with (independantly, mind you, and with different bias
values).

I wrote:
> The number of rolls required for a uniform distribution can be
> expressed as a number dependant on a factor between 0 and 1.  Call
> this number u [was x], and the number of required rolls i.  The
> number of different output
> possibilities shall be called n.  Thus:
>
> i = n*1/u [was x]
>
> but n=1 is meaningless.  As x approaces 0, n becomes insignificant.
>  As x approaches 1, n becomes the dominant variable.

So, now to correlate that with what I think I may know (o; about the
way that this algorithm works.

The weigtings can be defined as:

w1,w2,w3,...wn

The sum is, of course:

w1+w2+w3+...+wn

And initial conditions dictate that

w1 = w2 = w3 = ... = wn

(accounting, of course, for fractional parts which are not allowable
in our circumstances)
So, the best answer that I can come up with is this:

That the number of rolls required for a uniform distribution is, in
fact, also the initial weighting of one number, so that:

wn = n*1/u

sum = n*wn
sum = n^2/u

And the algortihm should be revised to read that if a number does not
have a weighting of n-1 or more, it cannot be selected, and the
random number must be regenerated.

And, I think that about wraps it up.

Once again, thanks, Mike, and saying that my weightings produced a
result that was too uniform is a valid point.

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPVviFgVk8xtQuK+BEQJndgCfbomKNsN4uz0dTFl5o9deHD+f7/kAoLkN
iv89ZVN7OvHGDFjLVSPwC5kn
=8slE
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads