2008-08-15 23:03  rgb

	* .: This is 2.27.10-1, and adds stdin support and fixes a few bugs
	  in the
	  specfile. I'm posting it for distribution, although it is still
	  not
	  "finished" -- this is very much development snapshot time.

2008-08-15 18:14  rgb

	* .: This adds the capability to input a binary stream into stdin.
	  This
	  patch is due to Paul Serice. He also included a (standalone?) rng
	  to
	  test with, which I'll mess with in a moment.

2008-08-03 12:40  rgb

	* .: Added a version string to help. Probably should add one
	  elsewhere, e.g.
	  at the top of rng listing and test listing.

2008-08-01 13:11  rgb

	* .: Had to back off the svn2cl in the rpm build -- it now has to
	  be run BY
	  HAND before just MY rpmbuild (dummy me) so that it won't fail for
	  end
	  users without svn2cl and an svn repo to match. It still builds
	  perfectly, and I'll do a full rpm build cycle including this step
	  to get
	  this last comment into the changelog.

2008-07-29 16:01  rgb

	* .: ...And it is. So henceforth ALL of my svn checkins will be
	  duly noted
	  in the ChangeLog, which will therefore get to be very long
	  indeed, as I
	  check in a lot.
	  
	  Damn! I guess this means no more swearing, and I sure hope I
	  haven't
	  impugned anyone's character in the first 400 plus checkins. At
	  least
	  not too much. Hmmm, I wonder just what I HAVE said down there. I
	  tend
	  to treat SVN logs as sort of a free-association commentary about
	  the
	  project in addition to being a place to document changes. Some
	  changes
	  have "real" documentation in the form of the svn diffs, as well
	  -- I
	  haven't been too specific about just EXACTLY what I've changed
	  every
	  time.
	  
	  Well, better a ChangeLog up to date and verbose than one months
	  to years
	  old, and I'll be hogtied and hung by the nose before I write a
	  precisely
	  formatted description of changes day to day as I work on this --
	  twice.
	  So SVN it is (dating back to when it was really CVS, BTW,
	  imported to
	  SVN).
	  
	  Next, I suppose we should provide at least >>a<< fix for the
	  problem of
	  shifting generator numbers, and on my own I want to clean up some
	  issues with file read -- arrange it so we can read in very large
	  files
	  and eliminate/document file-based usage redundancies such as
	  needing -g
	  65 AND -f filename. This will be a bit tricky, as dieharder can
	  read in
	  raw (binary) as well as ascii in many formats, and using the -g
	  flag to
	  differentiate at least raw vs cooked has been an easy solution.
	  
	  Regarding numbers, it has been suggested that we do two things:
	  
	  a) Take action to ensure that the numbers don't change any more,
	  even if
	  the gsl or I or a user add new generators. This is actually a bit
	  of a
	  PITA (much as I see the motivation for doing so, as moving
	  numbers break
	  user scripts) because the way generators are added is to run
	  through all
	  the supported ones of each type and just add them in gsl or call
	  order.
	  However, there are several ways I can do it (some requiring more
	  programming than others) and I'll see which one looks to be
	  easiest and
	  most robust.
	  
	  b) Arrange it so we can call generators by name, not just by
	  number.
	  Names would presumably not change even if numbers were inserted,
	  and
	  many users will be interested in testing a single generator they
	  are
	  thinking of using by name.
	  
	  rgb

2008-07-29 15:40  rgb

	* .: OK, this seems to work, autobuilding ChangeLog from the svn
	  log of my
	  timestamp file, that basically picks up a message like this one
	  every
	  time I do an svn checkin. We'll see in a moment if this is
	  reflected in
	  ChangeLog on the next build.

2008-07-29 15:26  rgb

	* .: Just testing...

2008-07-22 13:06  rgb

	* .: This is, in fact, a major checkin. A serious
	  won't-build-on-lib64 bug
	  was identified and resolved, the resolution being the addition of
	  --libdir=... to the ./configure line in the toplevel specfile.
	  Truthfully, I should probably add this to autogen.sh.

2008-03-27 16:33  rgb

	* .: This is getting close to a release snapshot once again. We do
	  need to
	  set the number of tests correctly. I may have to give up on
	  operm5 or
	  rgb_operm for the time being (again) but at least I have
	  rgb_permutations and rgb_bitdist, both of which test similar
	  things
	  along with sts_serial ditto. I do need to try to fix sums. I'd
	  love to
	  add a couple of the contributed tests. I do need to go through
	  the
	  opso, dna, etc. tests and "fix" them wrt overlap and so on.

2008-03-27 01:20  rgb

	* .: This APPEARS to be a functional permutations test, as
	  expected/hoped.
	  It uses NON-overlapping samples, although at a guess it would
	  work
	  for overlapping ones, just not as well.

2008-03-26 21:09  rgb

	* .: This is one, last, poor attempt to get SOME sort of
	  functioning
	  permutations test. I actually had this working "inside"
	  rgb_operm()
	  so I imagine I will have it working again here shortly.

2008-03-26 17:39  rgb

	* .: This appears to be "fixed" so that bitstream runs without
	  complaint. I
	  will need to check for memory leaks in the long run (heh heh).
	  This
	  once again takes me to where "everything works" but sums operm5,
	  I
	  think. I'll do another standard S 1 run in a second to make a new
	  snapshot with a fixed/reference bitstring.

2008-03-24 19:39  rgb

	* .: This fixes up all the tests that seem to require chisq with
	  explicit
	  cutoffs (frequently one that will be ignored). Cutoff does matter
	  in the rgb_bitdist test, though! I think all of these tests are
	  at last
	  valid through -p 100 and possibly -p 1000, except for sums,
	  bitstream
	  (which I'll fix shortly) and the perennial operm5.

2008-03-24 04:18  rgb

	* .: I am HOPING that this is all good, finally. It runs and gives
	  very
	  reasonable answers (once) at -p 1000. Now to see if this is
	  semiconsistent. I've fixed a few zillion small bugs...

2008-03-22 22:33  rgb

	* .: This repairs one serious bug -- I was misinitializing itail --
	  and makes
	  it a bit more precise as far as counting dofs.

2008-03-22 19:54  rgb

	* .: This MAY at long last, actually fix rgb_bitdist by
	  simultaneously fixing
	  vtests in general. Our chisq now AUTOMATICALLY bundles the
	  tail(s) or
	  low spots in a chisq, independent of where they occur. It looks
	  like I
	  failed to set ndof correctly, so there will be another round of
	  tests
	  and a quick checkin in a moment.

2008-03-19 06:23  rgb

	* .: THIS IS A WORKING STS SERIAL as far as I can tell. It
	  correctly reveals
	  known weak generators. It seems to pass known "decent"
	  generators. It
	  is very sensitive to certain kinds of failure.
	  
	  I now should redo rgb_bitdist to be the NON-overlapping version
	  of this
	  test, at the very least comparing the freq output (generated with
	  the
	  same code, I think, ported the other way) to a multinomial chisq
	  on the
	  expected values. If I can actually check the distribution of each
	  number against an asymptotically normal curve, that would be
	  great too.
	  If I could IN THE SAME TEST check the asymptotic fraction --
	  something
	  like the monkey tests do -- that would be just fabulous!
	  Especially if
	  I use a normal and make the comparison very good and not
	  empirical.

2008-03-19 00:45  rgb

	* .: This is very, very close to working perfectly WITH LABELS for
	  all the histograms generated by sts_serial. We'll save it just
	  because
	  it looks really useful.

2008-03-18 21:13  rgb

	* .: As far as I can tell, sts_serial now works perfectly. Time to
	  clean up
	  its act. I will start by decrufting some of the superfluous
	  output from
	  the library call, then I'm going to FIX the test struct so that
	  each
	  test has its OWN descriptor line that can be set along with its
	  pvalue
	  and that will be used by the histogram and/or single line output
	  routine
	  to identify the associated statistic. I have to make it a bit
	  easier
	  to make a single test call and get back the MATRIX of p-values
	  for a set
	  of statistics all generated with the single call.

2008-03-17 04:58  rgb

	* .: This, finally, appears to work perfectly. The last thing I
	  need to do
	  is to put all of the pvalues somewhere to be passed back to the
	  caller,
	  in order.

2008-03-17 01:44  rgb

	* .: This fixes a build problem on x86_64 -- must not have an
	  explicit
	  -L/usr/lib on x86_64 systems, empirically.

2008-03-17 00:55  rgb

	* .: This is much closer. Fixed a few small bugs, and one fairly
	  large one
	  from the transition to a loop. This is "probably" right at this
	  point.
	  The interesting question is whether and how we can generate
	  statistics,
	  pvalues, and results for the whole vector of results. In
	  principle we
	  can, but I don't know that I've done 14 in a row. OR, maybe I'll
	  figure
	  out that all I need to do is m = 16 (as it includes all its
	  smaller
	  cousins, supposedly).

2008-03-16 19:40  rgb

	* .: This isn't really done, but we're going to check it in since
	  it sort of
	  mostly works.

2008-03-12 21:47  rgb

	* .: Let's see if this revision works...

2008-03-12 17:34  rgb

	* .: Sending it ALL in to Duke and upstairs. There is a bug
	  of sorts in our chisq -- we don't have a good way of
	  specifying the number of degrees of freedom for some
	  of the tests and we need to.

2008-03-12 11:09  rgb

	* .: This is about as fixed as I can make it without doing algebra.
	  Algebra
	  later, fix code up now.

2008-03-11 23:26  rgb

	* .: This APPEARS to check with John E. Davis's patches.
	  diehard_dna is no
	  problem -- the drop-in replacement there produces identical
	  numbers,
	  runs in half the time. rgb_bitdist gives DIFFERENT numbers but is
	  MUCH
	  faster. I still have several "small bugs" to check out including
	  bugs
	  in specific tests, and I probably will need to test the static
	  routines
	  as well.

2008-03-11 19:49  rgb

	* .: Preparing to do the next round(s) of patches. I suppose we'll
	  start
	  with the get_bit_whatever patches. First I need to generate a
	  "before"
	  for at least one test that uses them, e.g. birthdays. Then we'll
	  compare it to after with the fixed seed of 1.

2008-03-11 04:53  rgb

	* .: This is beefing up the tarball so it just works with the usual
	  preexisting configure.

2008-03-11 04:25  rgb

	* .: RIGHT THIS INSTANT we finally have a clean F8 build with the
	  new
	  Makefile.am's and a hacked specfile. Alas, to fix the rpath
	  problem
	  I had to resort to using chrpath, which sucks big time. Unless
	  there
	  is a libtool directive for fixing it, though, I'm SOL.

2008-03-10 13:41  rgb

	* .: I don't know -- I think that we're getting closer and closer.
	  We will
	  have the code completely and cleanly GBT based by the end of the
	  morning, I think. Well, maybe not since I'm going in to see if
	  there
	  is anything entrepreneurial going on with Thom LaBean.

2008-03-10 12:08  rgb

	* .: OK, this is pretty much all the patches, I think. We should be
	  very
	  close to BSD-ready. I wonder if I can add the word "beta" to the
	  "release" or the "8" in VERSION?
	  
	  Oh, one other thing -- I very definitely need to fix the rpm
	  build
	  (specfile). Let's install into /tmp and see what we've got.

2008-03-10 11:54  rgb

	* .: Decrufted the makefiles, added a /dev/arandom rng for BSD,
	  fixed tiny
	  modulus bug in rng list display, added sensible error message
	  extensions
	  for people running across distros for the /dev/?random devices (I
	  "could", of course, use fstat to determine if the devices are
	  there and
	  refuse to add them if they aren't, but that's for the future).

2008-03-10 02:07  rgb

	* .: Checking in a mildly broken set. FWIW, a full build actually
	  works.
	  OTOH, make rpm does not. Perhaps not too unsurprising. I need to
	  do
	  a full install into /tmp and see what comes up.

2008-03-09 19:35  rgb

	* .: This actually is getting close to being done "the right way".
	  It still
	  builds, and I think builds an RPM, but I need to work on the
	  library
	  side to clean it up as well.

2008-03-09 18:57  rgb

	* .: OK, this is really close to being what freebsd wants.

2008-03-09 17:55  rgb

	* .: OK, looks like the BSD patch for rngs_gnu_r.c works, and I'm
	  guessing
	  that it will work in general UNLESS it has to be the gnu error()
	  program to interface with R, in which case the patch will have to
	  be
	  ifdef'd.

2008-03-09 17:38  rgb

	* .: OK, we are in the middle of a Major Patch Job. We're fixing
	  various
	  small things that are wrong with our GBT port, trying to get it
	  so that
	  it will automagically build on a wider set of systems. The stuff
	  I've
	  done so far still builds (I need to test the rpm build though)
	  and
	  "should" build on gentoo as well as Debian and Fedora/RH.

2008-02-13 00:01  rgb

	* .: This fixes the Crispin bug, -- a bad number in one column of
	  s[i][j]
	  relative to the original diehard. Sure hope it is the correct
	  one; the
	  later (c version) diehard matched what I had.
	  
	  I really need to compute the r and s directly. But then, I think
	  I
	  understand the operm5 test well enough to do it "directly"
	  without
	  overlap as a non-overlapping permutations test. It might even be
	  fun to
	  make overlap just an option.

2008-01-30 12:47  rgb

	* .: This fixes the abstract AGAIN...

2008-01-02 16:23  rgb

	* .: This should be the absolute minimum needed to build clean from
	  tarball
	  using "just" ./configure followed by make. Need to fix the
	  configure
	  script to check for the gsl and anything else that might be
	  needed.

2007-12-07 17:40  rgb

	* .: This checkin just updates the release number.

2007-12-06 19:39  rgb

	* .: This patches two small things -- adds fflush(stdout); so tees
	  of the
	  results don't make you wait. Removes a development line from
	  diehard_operm5 that shouldn't be there in any KIND of real
	  release.
	  
	  Need to bump the snap revision and reinstall.

2007-11-19 12:38  rgb

	* .: This is pretty much a fully functional version. I fixed the
	  last bug,
	  which turned out to be that I had the right idea but missed the:
	  
	  I + P + P* + P^2 + P*^2 + ...
	  
	  and was accidentally doing (when I empirically noted that
	  including k=0
	  in the sum was necessary) either:
	  
	  I + P + P^2...
	  
	  or
	  
	  2I + P + P* + ...
	  
	  Added a conditional to eliminate the second k = 0 instance in the
	  core
	  loop summing the fi*fj and got perfect correspondance through -n
	  3. The
	  -n 3 matrix is different, but pretty obviously a permutation of
	  the
	  AKM matrix as to be expected since the permutation order is
	  arbitrary
	  and they probably didn't use lexical ordering. The eigenvalues,
	  however, are dead on the same!
	  
	  So I'm back up to the point where I should be able to form a test
	  statistic somehow. I have to covariance matrix precisely in hand
	  --
	  something at this point about weak inverses (weak because it is
	  singular
	  and has no inverse?). A bit curious, actually. We'll see.
	  
	  rgb

2007-11-19 06:02  rgb

	* .: OK, this SEEMS to repair everything, except for some spurious
	  normalization stuff that is at least consistent between the exact
	  and experimental matrices. They now come out the same, and I
	  suspect
	  they are proportional to the nilpotent markov processes paper
	  result.
	  For k=2 they clearly are -- a factor of 2. For k=3 it is harder
	  to see
	  for sure. Time to go back to the paper with a calculator.
	  
	  At least now the matrices are properly symmetric, as well. That
	  means
	  that their eigenvalues can be computed with my existing code with
	  its
	  symmetric matrix eigenvalue calls. It does leave me with the
	  substantial problem of computing a test statistic automagically,
	  but one
	  small step at a time...

2007-11-14 12:01  rgb

	* .: This works, but my assumptions concerning the inverse of C are
	  incorrect
	  because (gasp) C isn't invertible. It has eigenvalues and
	  eigenvectors.
	  I can compute them, apparently -- that's what this snapshot does
	  (I'm
	  going to compare the results now to what's in my nilpotent
	  processes
	  paper). I still don't quite see how to make my results into a
	  p-value,
	  though, and may need help with this...

2007-11-13 16:53  rgb

	* .: It is SO key to preserve this in precisely this state. At this
	  instant
	  in time, cexact and cexpt are identically formed, one running
	  over all
	  permutations and the other from sampling, and they work perfectly
	  EXECPT
	  for the #!)#%@ sign error. I had the sign right, and don't quite
	  see
	  how I changed the code, so I'm about to look. In the meantime,
	  though,
	  we mustn't lose this working form...

2007-11-01 02:11  rgb

	* .: This is a broken checkin, but I'm on track for getting operm
	  finished at
	  last, if only I stick to it.

2007-10-24 19:19  rgb

	* .: Need to send to duke, dummy.s

2007-10-24 19:18  rgb

	* .: This is needed for development, I think.

2007-10-24 19:17  rgb

	* .: Trying again. Dunno how this got screwed up but it is.

2007-10-03 20:16  rgb

	* .: This is actually a pretty solid implementation of
	  rgb_minimum_distance...

2007-09-29 21:43  rgb

	* .: works perfectly. fixed memory leak. about to improve 2dsphere
	  with
	  sort, then run -a.

2007-09-29 15:24  rgb

	* .: This is IT and works... rgb_minimum_distance is there.

2007-09-20 09:37  rgb

	* .: I need to fix this, but probably not today. In doc there is a
	  "fix me"
	  recipe for 2d spheres. I'm currently adding the Linux Magazine
	  invoice.

2007-09-19 18:44  rgb

	* .: Checking in a fix for the BROKEN 2d spheres test. I should be
	  able to
	  fix 3dspheres as well from it.

2007-08-28 16:54  rgb

	* .: Bug reported by a user, sort of. The README still said you
	  could just
	  type "make" and you can't. Fixed.

2007-08-13 22:30  rgb

	* .: Will this go in? Time will tell...

2007-07-16 15:20  rgb

	* .: We are working HARD or confirming or denying dieharder_operm5
	  AND
	  working out a more general rgb_operm. The convertoperm.pl script
	  once AGAIN confirms that I'm unpacking and repacking (for C) the
	  r and s matrices of diehard_operm correctly.
	  
	  However, AFAICT, the diehard_operm5 JUST tallies up t[120], the
	  count of
	  the different permutation indices. However, all the permutations
	  should
	  occur with a SYMMETRIC probability -- I verified this directly by
	  doing
	  the actual integrals, but in retrospect it is pretty obvious from
	  symmetry alone. The t-vector therefore has NOTHING TO DO with the
	  covariance matrix no matter what you do with it, which may be why
	  diehard_operm5() is a bad test. FWIW, I've added output
	  statements to
	  diehard_operm5() that dump the t-vector and verified empirically
	  that
	  yes, it produces a more or less uniform distribution of
	  bin-probability
	  1/120 -- one could in fact do a chisq test on this directly and
	  very
	  likely obtain an actual meaningful test, but that is not at all
	  what is
	  done.
	  
	  Note well that the sampled distribution of t[] will not
	  SIGNIFICANTLY
	  vary if computed from overlapping samples! This is simple to see
	  -- it
	  would be just like computing five distinct samplings of
	  non-overlapping
	  samples, each of which would be expected to have exactly the same
	  mean
	  and variance. Because of the overlap there could be a tiny bit of
	  correlation between the FLUCTUATIONS in the MEASURED mean values
	  for any
	  given bin, but the bin mean would have to be unchanged for each
	  overlapping sampling, and for that matter the bin variance for
	  each
	  sampling would ALSO have to be the same.
	  
	  The only effect of combining the overlapping five samplings (each
	  with
	  identical mean and variance!) would therefore be to AT MOST alter
	  the
	  sampled VARIANCE of the bin distribution, per bin, a tiny bit
	  from what
	  one might expect analytically from truly iid samples. One
	  certainly
	  isn't going to see this variation in the variance from two runs
	  -- the
	  expected statistical noise would overwhelm the signal as this is
	  a
	  second moment/cumulant effect, a susceptibility if you like, and
	  hence
	  VERY difficult to resolve.
	  
	  What we in fact must do is (I'm pretty sure) compute c[][]
	  analytically,
	  (which I have done) and then simulate the SAME c[][] directly
	  from the
	  data. Then difference them, which should make the components of
	  c_exp[][] - c_exact[][] presented as vector a zero mean chisq
	  distributed object with N! - (N-1)! DoF or something like that --
	  120-24
	  = 96 for N = 5? Here I'll defer to experts, eventually.

2007-06-16 05:11  rgb

	* .: Hopefully this has all the files needed for rgb_operm()
	  checked in.

2007-06-16 05:09  rgb

	* .: This actually builds. Let's see if the new test shows up...

2007-06-16 00:12  rgb

	* .: Checking in several things. rgb_operm.c is a template for my
	  eventual
	  replacement for operm5. I have about concluded that operm5 is
	  basically
	  a joke -- it is conceptually incorrect. The correct statistic
	  should be
	  the overlapping permutations covariance matrix itself. This test
	  just
	  counts the occurrence of permutations -- the "overlap" part is
	  completely irrelevant in this context. It returns an aggregate
	  count
	  vector whose mean is 1/120 (obviously, permutations of 5 objects
	  = 5! =
	  120). It makes NO DIFFERENCE AT ALL if this vector is evaluated
	  from
	  overlapping samples or from independent samples -- the mean will
	  be the
	  same. All that MIGHT change is the variance -- since the samples
	  are
	  drawn from an overlapping population, one would expect that their
	  variance would be strictly less than one would expect from truly
	  independent samples.
	  
	  In a minute I'll verify this with the overlap flag and a couple
	  of runs
	  with mt, but I now understand why the test fails. It remains to
	  figure
	  out how to build a CORRECT overlapping permutations test that
	  uses the
	  COVARIANCE of overlapping samples as a statistic. I actually
	  think that
	  this will be pretty easy, but I do have to also understand why
	  the
	  definition in the nilpotent markov chains paper doesn't (I think)
	  lead
	  to the numbers that they publish there. Or rather, why my MUCH
	  SIMPLER
	  algorithm doesn't lead to the same numbers they get.

2007-06-14 18:54  rgb

	* .: This should have no operm in it.

2007-06-14 18:36  rgb

	* .: Probably a good time to update to lucifer, since it is
	  actually up...

2007-06-08 14:14  rgb

	* .: OK, NOW let's actually try to get rng_uvag in, THEN we'll try
	  to
	  increase its speed...

2007-05-24 17:35  rgb

	* .: I'm gradually refining the bitstream variance -- 290 is from
	  over
	  260000 samples. I'm shooting for a s.d. of a couple of tenths,
	  although
	  honestly it is overkill.

2007-05-23 05:02  rgb

	* .: OK, this is a major enough checkin. I have at long last fixed
	  bitstream.c. Marsaglia's published value of sigma is off by close
	  to a
	  factor of two. sigma is in fact 288.6. I have verified this by
	  simulation with very excellent RNGs, e.g. MT or gfsr4 AND with
	  HARDWARE
	  generators (which were failing bitstream before).
	  
	  Marsaglia couldn't resolve the error (which could just have been
	  due to
	  a typo at some point that was perpetuated) because his test
	  didn't run
	  enough times or plot the pvalues in a histogram, but if you plot
	  the
	  obtained means in a histogram and fit a normal to them, there is
	  absolutely no doubt.

2007-05-23 04:35  rgb

	* .: Forgot to check this one in...

2007-05-23 04:31  rgb

	* .: OK, this is one of two ways to get things to metatron to run
	  faster.

2007-05-23 01:12  rgb

	* .: This fixes several problems, and is working its way towards a
	  new
	  release.

2007-05-22 14:04  rgb

	* .: Silly checkin, as I dropped a file here that goes below.

2007-05-21 23:46  rgb

	* .: Well, we're making LOTS of little changes here. We're
	  splitting off
	  Exit() into its own file so it can be shred, we're moving
	  db_gnu_r_rngs.c to gnu_r_rngs.c, we're adding prototypes and
	  changing
	  the namespace for RDH. All at once.

2007-05-21 22:14  rgb

	* .: Fixed small problem in makefile. Otherwise I'm not sure why
	  these files
	  are changing -- they really shouldn't.

2007-05-21 19:04  rgb

	* .: I do believe that this now is ready to rock and roll. AFAICT,
	  it "just
	  works".

2007-05-21 18:39  rgb

	* .: This is checking in dieharder WITH RDieHarder included and
	  under version
	  control. RDieHarder now depends on dieharder sources. I still
	  haven't
	  got the Makefile, with dependencies, built into the existing
	  Makefile
	  but I will. Basically, I plan three new targets: rdhprep, rdhlib
	  (as
	  root only) and rdhtgz (to make a "package" out of it).

2007-05-21 13:34  rgb

	* .: Well, we've been working hard here. Let me try to summarize.
	  I've
	  instrumented the code to make it "easy" to move it to RDieHarder.
	  Dirk
	  doesn't understand, quite, how I plan to make RDH a "part of" the
	  dieharder source tree, but he will when I'm done as it will then
	  be
	  really easy to prep his cran/debian package. I think, I hope.
	  
	  I think that I'm going to need to pursue dieharder this summer
	  pretty
	  aggressively in addition to working on axioms and other books. I
	  should
	  probably look hard at getting money to support it, as well.

2007-05-19 12:14  rgb

	* .: We've got to get this to lucifer and then try to unpack it on
	  metatron...

2007-04-29 18:06  rgb

	* .: This too has to go to lucifer...

2007-03-12 13:50  rgb

	* .: This is the last set of changes associated with 2.24.3 --
	  which is
	  hopefully getting really, really close to a release I can live
	  with.
	  I suppose I should fix the man pages, at least to some extent.

2007-03-05 15:35  rgb

	* .: This looks like it successfully splits off the manual so it is
	  no longer
	  autobuilt and is not in the rpms.
	  
	  From here out the manual will be a SEPARATE project aimed square
	  at lulu
	  publication as a book I might even make money from.

2007-03-05 15:32  rgb

	* .: We'll work our way there by hook or by crook.

2007-03-05 15:32  rgb

	* .: Grrr. I just lost a whole bunch of work...

2007-03-02 01:00  rgb

	* .: This has now been fixed, a la Charles Karney's suggestion and
	  Janusz's
	  paper demonstrates, to use overlapping samples by default. Some
	  tests
	  it really DOES matter, if those tests are valid at all (operm5
	  being a
	  classic example). I still doubt the bitstream-dna test series --
	  I
	  think that there is NO difference between overlapping and
	  non-overlapping samples there, or at most a tiny shrinking of the
	  distribution variance in the end, as they don't measure
	  "overlap", only
	  a CLT-limited mean. Overlapping 20 bit samples should make a tiny
	  shift
	  in the sample standard deviation and have no other effect in
	  these
	  tests.

2007-03-02 00:38  rgb

	* .: This fixes the Bug reported by Brian J. Wong, making bl and bu
	  of a
	  function in bits.c static uint (preserved between calls) instead
	  of
	  dynamic. Probably my bad...

2007-02-28 15:39  rgb

	* .: Sending this into SVN on general principles.

2007-02-28 03:38  rgb

	* .: This actually seems to work. So we now have 66 random number
	  generators
	  to test. Tony Pasqualoni's Cellular Automaton rng isn't anywhere
	  NEARLY
	  as fast as he alleges compared to the GSL routines inside
	  identical
	  packaging -- in fact it is about par for the course -- but so far
	  it
	  seems to be 1 bit and 2 bit random, and we're working on a -a run
	  that
	  will expose it to the latest/greatest operm5. It remains to be
	  seen
	  whether or not K. Janusz's paper contains algorithms that will
	  let me
	  check and/or correct Marsaglia's operm5, or perhaps extend the
	  operm5
	  into a RANGE of tests like rgb_bitdist.

2007-02-28 03:19  rgb

	* .: This is a very first cut of Tony Pasqualoni's Cellular
	  Automaton
	  random number generator, ported into a gsl standard wrapper. This
	  will
	  let me test Tony's assertion that this is a good, very fast rng
	  in
	  exactly the same wrapper that one can study the other "good" (but
	  slower) rng's.

2007-02-27 07:10  rgb

	* .: This is a really modest checkin, but we'll see if it can
	  manage...

2007-02-27 07:04  rgb

	* .: TAG 2.24.2
	  
	  I fixed the -q(uiet) flag so that it works, and decided to bundle
	  all of
	  the above bugfixes and feature shifts into a new minor minor
	  bump. This
	  is the "official" GBT build, if Dirk concurs when he tries it.
	  
	  As far as I know, we're at least back where we were when we
	  started
	  implementing GBT and then some.
	  
	  Now, if only I could figure out the trunk thing. Maybe I'll try
	  doing a
	  checkout and build without the trunk movement...

2007-02-27 06:31  rgb

	* .: TAG 2.24.1-2
	  
	  Fixed documentation and added a hard record of Janusz's bug in
	  operm5.

2007-02-27 06:06  rgb

	* .: Sending this to Duke, at least...

2007-02-27 06:06  rgb

	* .: This contains a change suggested by the following:
	  
	  %<snip snip -----
	  From: Janusz Kawczak <jkawczak@gmail.com>
	  To: Robert G. Brown <rgb@phy.duke.edu>
	  Cc: Dirk Eddelbuettel <edd@debian.org>
	  Subject: Re: Random R-Package
	  
	  Hello, without going to much into peculiarities (for now, at
	  least) of
	  the rngs and numbers coming from Marsaglia and you (Robert), I
	  would
	  like to give the result from our paper that is directly
	  applicable to
	  the operm5 header you cited below:
	  
	  "...(with # rank 99)..." - this is the point I questioned in our
	  paper.
	  I asked Marsaglia how he got this rank, but I never received the
	  reply
	  from him. I can only presume that he either guessed this number
	  or
	  estimated it (somehow). It remains a mystery to me; like a
	  Marsaglia's
	  voodoo step. The answer should be 96=5!-4!. It is not a big deal
	  of a difference in this case, however, the theorem we proved
	  allows one
	  to consider cased of perm6, perm7 ... and higher with the exact
	  number
	  of degree of freedom calculations. Thus, exact and not guessed
	  results.
	  
	  It is my opinion that the operm-type test is very powerful for
	  detecting
	  local correlations (dependencies) and it should be used for such
	  purpose. So, any algorithmic PRNG will suffer and most likely do
	  not
	  dwell well when exposed to this test. I have not had a chance to
	  do
	  serious experiments on the "natural-random" generators, e.g.
	  alpha-particle counting, radio noise signals and many others.
	  But, I
	  suspect that the operm-type test should do well in this
	  situation.
	  
	  I cannot promise at this time much, but I am going to look at the
	  issues
	  you addressed in your e-mail. However, the questions you've
	  raised are a
	  bit different animals to deal with.
	  
	  In summary, it would be useful, once and for all, to correct 99
	  degrees
	  to 96 in the operm5 Marsaglia's header file. Maybe, one day, this
	  will
	  happen :-)
	  %<snip snip -----
	  
	  I've implemented this change -- 99 to 96 -- although I welcome
	  any
	  comments. The test still fails the big four -- gsfr4, taus2,
	  ranlxd2,
	  and mt19937 -- nearly all the time, overlapping or not. I still
	  suspect
	  either errors in r and s or (quite possibly) programming errors,
	  but it
	  ALMOST works and lacking a gold standard rng it is difficult to
	  resolve
	  the question numerically.

2007-02-27 05:16  rgb

	* .: This is an important change -- I fixed an annoyance (if not
	  worse) with
	  the libdieharder setting of the major revision number. I may need
	  to
	  propagate the expr back to the toplevel Make.

2007-02-27 04:39  rgb

	* .: Dirk found that I was still screwing up the PREFIX thing by
	  stubbornly
	  refusing to use (lower case) prefix, libdir, and includedir in my
	  make
	  install target. I think I've stripped out my own versions of
	  these
	  completely so that they can a) be set by configure and run with
	  "just"
	  make install or b) overridden on the make line, e.g make
	  prefix=/tmp/usr
	  install (as apparently he likes to do to make debian packages).

2007-02-25 19:42  rgb

	* .: This is definitely experimental, trying to write a web
	  installer
	  modification that I cannot test until I get back the net.

2007-02-25 19:32  rgb

	* .: Ok, this is TAG=2.24.1, the first Gnu Build Tools release that
	  builds
	  rpms clean from (we hope) SVN. I do need to validate this with
	  one
	  last SVN checkout, but I'm pretty sure it is the case...

2007-02-25 18:35  rgb

	* .: Well, a time to check in. We're about to see if an rpm build
	  works...

2007-02-25 18:15  rgb

	* .: This may be a really nice advance. The dieharder build now
	  uses
	  ../include and ../libdieharder as -I and -L respectively, and
	  plain old
	  "make" in both cases should work, from a clean checkout. I'm
	  guessing
	  that I can add a simple Makefile.am to include to do the actual
	  install
	  of the include files.

2007-02-25 17:47  rgb

	* .: This should be REALLY REALLY close. We'll checkin, do a full
	  checkout,
	  and try building. If/when we get there, we'll work strictly from
	  build
	  to build once again.

2007-02-25 17:27  rgb

	* .: OK, this is one whole cut closer, and ALMOST works, but we're
	  definitely
	  going to have to try this one more time... We also need at some
	  point
	  to stop svn control of Makefiles and maintain only Makefile.ams

2007-02-25 17:17  rgb

	* .: Adding what MAY be all the things needed to enable full
	  automated Gnu
	  style builds from the autogen.sh script.

2007-02-25 17:16  rgb

	* .: Finished a first cut at adding GBT support. Need to check in
	  the .in
	  files and configure.ac files one level down, and do a full
	  checkout to
	  see if it autobuilds from an svn checkout.

2007-02-19 14:23  rgb

	* .: This dumps buildroot. We don't need or want this in the
	  tarball or rpm
	  sources.

2007-02-19 08:47  rgb

	* .: We are working quite hard on getting the ChangeLog to be
	  automagically
	  registered. I'm guessing it should just go into %doc and we
	  should
	  pretty much forget the tag otherwise.

2007-02-19 08:05  rgb

	* .: This fixes a variety of problems with using shared libraries
	  correctly,
	  and moves the project much closer to where it could e.g. be
	  included in
	  FC extras. The library builds nicely now, for example. However, I
	  do
	  need to switch to using autoconf, however much I generally
	  dislike it.

2007-02-19 06:32  rgb

	* .: OK, this fixes some serious uglyness. Let's see if the rpm
	  builds...

2007-02-18 21:49  rgb

	* .: Updating the svn tree and sync'ing, perhaps for the last time.
	  Will
	  this now reside on code.google.com? We'll see.

2007-02-18 13:37  rgb

	* .: Let's call this TAG=2.5.24 -- bumping the first minor to
	  announce that
	  we've cleaned up several bugs and repackaged.

2007-02-15 18:55  rgb

	* .: This fixes a bug reported by Matthias Braeunig
	  <mb.atelier@web.de>, who
	  was running the test on a file of data just one time per test
	  using more
	  or less this line:
	  
	  for t in $(echo "-d"{1..19} "-r"{1..4} "-s"{1..2}); do
	  ./dieharder -q -t9375 -p1 $t;done > results
	  
	  He noted that kstest_kuiper returned 2.0 for input single pvalues
	  of
	  0.0, and that the test overall returned a pass even if p=1.0
	  exactly
	  (which it also should not do for single pvalues).
	  
	  I made the following changes. kstest_kuiper now returns a single
	  input
	  pvalue as its output pvalue -- clearly that's all one can do and
	  the
	  right thing to do. The test.c assessment that prints out the
	  results
	  also no longer calls the return a KStest result, and reports
	  failure
	  a bit differently, flagging the high-p failures as well as the
	  low p
	  failures, and adjusting the reported failure range accordingly.
	  
	  To do this I had to use -static in the Makefile to work in the
	  development tree. I'm guessing that I need to add LDFLAG =
	  -dynamic to
	  the build make line in the specfile and should LEAVE it -static
	  in the
	  actual tree so people don't get stymied if they download and
	  build in
	  the tarball directory ("people" including me) while rpm's will
	  still
	  autobuild dynamic correctly.
	  
	  Finally, Matthias reported that the -q flag doesn't work. He's
	  right,
	  but I'm not sure I'm going to fix that. Rather I should probably
	  just
	  kill it and let people filter the output results by hand...

2007-02-06 04:42  rgb

	* .: I've just fired this up to the web. I deem it finished enough.
	  Now to backport the library fix to wulfware, and call it a night,
	  very
	  much a night.

2007-02-06 03:06  rgb

	* .: OK, it installs and builds PERFECTLY, and THIS time it almost
	  certainly
	  is dynamically linking to libdieharder.so, as it linked without
	  the .a
	  library present at all. I'll now have to go retrofit this to
	  wulfware,
	  as it is not building correctly.

2007-02-06 02:39  rgb

	* .: This actually rand and built! Now to try to rebuild it WITHOUT
	  the .a
	  library installed...

2007-02-06 02:30  rgb

	* .: Just in case I drop something, I finally seem to have "fixed"
	  the
	  libdieharder makefile. On to fame and glory.

2007-02-05 20:06  rgb

	* .: OK, this is crawling on closer to ready to go...

2007-02-05 19:51  rgb

	* .: Make this go away, please.

2007-01-28 15:58  rgb

	* .: This has a brand new ultra-cool target, "installrepo" that
	  makes the
	  rpms and installs them in the repo, from when yum can install
	  them.
	  
	  BTW, I think I forgot the "requires" tag in the dieharder
	  sources,
	  partly because it seems that it isn't, in fact, required. Hmmm.

2007-01-28 00:11  rgb

	* .: This works!

2007-01-27 22:39  rgb

	* .: This is getting really close, worth checking in...

2007-01-27 18:27  rgb

	* .: This now builds a perfectly rebuildable tarball. We can think
	  about
	  just what else we'd like to add to that tarball in a moment, but
	  first
	  we need to FINALLY get the rpm to build, maybe.

2007-01-27 17:59  rgb

	* .: This updates the abstract.

2007-01-27 17:50  rgb

	* .: OK, this just maybe is working now with a target that rebuilds
	  both specfiles and Makefiles when the toplevel Makefile is
	  altered.

2007-01-27 16:57  rgb

	* .: This is just peachy. make and make install targets work for
	  BOTH
	  dieharder_src and libdieharder directories, which is pretty cool,
	  really. The remaining problem will be how to force a rebuild
	  of the library in such a way that it works when we're developing
	  but
	  doesn't barf when we're rpm-ifying.
	  
	  At this point in time it is high time to try the rpm build.

2007-01-27 16:41  rgb

	* .: OK, this is making progress. Time to go back to libdieharder
	  and get
	  a build to work there...

2007-01-27 16:13  rgb

	* .: Just making sure this is all ready to run when I start to edit
	  the Makefile in libdieharder.

2007-01-27 16:08  rgb

	* .: OK, this is a very painful move. We will, of course, mothball
	  and
	  preserve libdieharder's original svn tree, but now that we're
	  figuring
	  out how to do one specfile, many packages from a single toplevel
	  source tree we no longer wish to maintain libdieharder in a
	  separate
	  subversion project. So we're checking it into this one. All the
	  change history is preserved, but in pieces -- CVSROOT first,
	  subversion's libdieharder second, and from now on, here in the
	  one
	  true dieharder tree and its subversion controlled project.
	  
	  Next we have to get this so that a make install does the right
	  thing.

2007-01-27 15:53  rgb

	* .: This is a first cut at making dieharder actually build, after
	  libdieharder is built and installed. From now on BOTH will use
	  ONLY
	  the include files that are stored in ./include, which will
	  actually
	  simplify life tremendously. I may symlink them through to the
	  source directory(s) and may even svn control the symlinks, if svn
	  can
	  manage them. CVS couldn't...

2007-01-27 15:31  rgb

	* .: OK, we are within a single step (removing or moving some
	  include files)
	  of being cleaned up and ready to proceed. I'll probably copy at
	  least
	  part of the sm Makefile to get the hang of looping a make through
	  source
	  directories in order to achieve the make install in the right
	  sequence.

2005-03-14 13:57  rgb

	* : This sends in parse.c. Y'know, I'll bet that this is what
	  breaks
	  Dan's access. Shit, looks like I'll have to kiss "make sync"
	  goodbye...
	  or give him an "account" locally with the same uid/gid -- nope
	  that
	  won't work either. Sigh.

2005-03-11 03:42  rgb

	* : This goes home and into laptop...

2005-03-11 03:05  rgb

	* : Sending this all home, so I can make it on metatron?

2004-11-30 14:14  rgb

	* : I think we'll add this to the repository as the "reference run"
	  against
	  the default generator, dieharder -a > dieharder.all. If we update
	  this
	  at the end of every new addition, we'll be able to advance to
	  toolset
	  in a fairly systematic (but generally reliable) way.

2004-11-29 21:36  rgb

	* : This looks like it ran nicely.

2004-11-29 19:30  rgb

	* : This MIGHT just be a reference run followed by tag bump and
	  checkin.
	  Looks pretty nifty, right up to a first draft of histogram.

2004-11-29 19:03  rgb

	* : Adding the published diehard F90 source code to the tree for
	  porting convenience, although we will not use any of it verbatim,
	  obviously, in a c port.

2004-11-29 17:18  rgb

	* : I'm hoping that this is the needed binary rank program that
	  analyzes
	  binary (bitlevel) matrices for the diehard binary rank tests.

2004-11-24 06:14  rgb

	* : This seems to "work", although it is consistently producing an
	  overall
	  p-value that is in the .9 range and hence "too high". I'm going
	  to
	  start up a full run of 100 x 40000 in a second to see if I get a
	  "normal" pvalue.

2004-11-24 06:00  rgb

	* : Well, not JUST that. I suppose that next we'll have to actually
	  debug.

2004-11-24 05:58  rgb

	* : This is ALMOST working. I'd say the binary rank part is
	  working, hence
	  the checkin. It is the rank_32x32 part that isn't, but I'll work
	  on it.
	  
	  I suspect something really simple, like needing to normalize y by
	  tsamples...

2004-11-22 20:08  rgb

	* : This is simply lovely, simply lovely, with a good start on
	  adding
	  Diehard's Binary Rank test. All I need is a suitably scaled
	  matrix
	  and a few zillion rands...

2004-11-22 19:23  rgb

	* : Why didn't these make it to Duke?

2004-11-22 08:35  rgb

	* : This is 0.5.8 stable, I hope. Time to go beddy-bye, hoping that
	  this is
	  now ready for real development and grantseeking work. I should be
	  able to add a couple more diehard tests "easily" at this point, I
	  think.
	  
	  rgb

2004-11-22 06:47  rgb

	* : This is VERY VERY close to being a fairly serious tagged
	  checkin.
	  We've resolved the problem of multiline strings in gcc, snagged a
	  C tutorial for gcc, completely fixed the documentation -- this is
	  all pretty awesomely ready for a brave new release.

2004-11-22 04:24  rgb

	* : This is really close to working with all the changes in the
	  command
	  line options and associated global variables. In fact, it might
	  BE
	  working.
	  
	  Two things that I really really need are a routine that can take
	  a
	  data object that is one big string and display it to the screen
	  (something gcc refuses to do any more, which sucks big time) and
	  a 20x
	  histogram of p-values. Let's see if I can find them on the web
	  before
	  tackling them -- in particular the former seems like it must have
	  been
	  written by somebody...

2004-11-20 18:17  rgb

	* : This is now really truly ready to go, EXCEPT that NOW I have to
	  alter
	  all sorts of command options according to the latest
	  prescriptions in
	  the checkin logs and abstract/web page. And get it "working
	  perfectly"
	  once again. I might even finish this this weekend, if I really
	  hammer
	  at it.

2004-11-20 15:55  rgb

	* : This is the REALLY final checkin of rand_rate, I think, before
	  we clone
	  it into dieharder.

2004-11-20 15:50  rgb

	* : This is the last checkin of rand_rate AS rand_rate. I'm going
	  to change
	  the name of this suite to dieharder. I'm also going to change the
	  test numbering schema and option naming so that e.g.
	  
	  -d diehard test number
	  -r rgb test number
	  -s sts test number
	  
	  where -1 runs all tests of a given kind, 0 lists a description of
	  all
	  tests in the suite, -2 runs all tests of a given kind EXACTLY as
	  they
	  are run in the original code, if possible -- I'm not sure I'm
	  going to
	  test overlapping bit strings drawn from a single int just to bump
	  the
	  count of "random numbers" unless the test explicitly calls for it
	  and it
	  makes sense, as there is this thing about each sample being
	  "independent" that worries me with overlapping draws.
	  
	  -p number of p-values in final KS (and possibly other) test(s).
	  This
	  is the number of times each "test" is run with independent random
	  number
	  seeds (as the DEFAULT from now on). This defaults to 100, which
	  is
	  actually a lot and very reasonable but which can be increased if
	  one is
	  in doubt about whether the distribution of p returned by "the
	  test" is
	  in fact uniform.
	  
	  -t number of test samples that go into making up a single test.
	  This
	  is NOT always a free parameter -- in many of the diehard tests
	  especially, the number of e.g. points drawn from a 2d or 3d
	  volume in
	  the minimum distance tests is fixed, and varying it would vary
	  the
	  target distribution and test statistic. Although this is a bit
	  unfortunate, since varying the number of test samples is an
	  excellent
	  way to make marginal failures in the distribution of p resolve
	  into
	  clear failures, we either live with it or derive general forms
	  for the
	  asymptotic target distributions as a function of the number of
	  samples
	  or do simulations and empirically deduce forms ditto (as
	  Marsaglia and
	  others appear to have done). For the moment we'll live with it.
	  
	  -b bitstring width. Some tests are applied only to samples that
	  are
	  "bitstrings" (as opposed to e.g. lists of unsigned integers) of
	  user-specifiable length. One reason to limit the tests in this
	  way is
	  to avoid numerical difficulties in e.g. evaluating
	  P_binomial(k,p,n),
	  where one can easily under or overflow and end up with garbage or
	  a gsl
	  fault. Another is to "free" some of the existing tests that have
	  a very
	  specific size of bitstring that they look at so that this can be
	  varied
	  when the target distribution can still be computed as a function
	  of
	  bitstring size. This will be overridden as necessary, like -t,
	  for
	  tests that really do require a fixed bitstring size to approach
	  the
	  known target distribution.
	  
	  -n ntuple or window width. A number of tests look at bit ntuples.
	  An
	  ntuple is a set of n consecutive bits drawn from a bitstring
	  (possibly
	  of -b specified width) or vector of random uints (possibly of -t
	  specified length). ntuples are always drawn relative to a bit
	  offset
	  specified from the right (least significant) with 0 being the
	  rightmost
	  bit, with cyclic boundary conditions on the entire bitstring
	  >>or<<
	  sample uint vector, so drawing an ntuple cannot fail for any
	  offset
	  within the number of significant bits returned by the generator
	  (which
	  MAY NOT BE 32, or even 31 -- some generators return as few as 16
	  significant bits!).
	  
	  For example, an 8-bit bitstring might be:
	  
	  01100111
	  
	  and all the 3-tuples drawn from it are given by
	  
	  offset 3-tuple
	  =====================
	  0 111
	  1 011
	  2 001
	  3 100
	  4 110
	  5 011
	  6 101 <- Note wrap around!
	  7 110 <- Ditto!
	  
	  A general purpose
	  
	  get_bit_ntuple(*bitstring,bitstring size,ntuple size,offset)
	  
	  routine is provided that is used by many tests to get ntuples
	  from a
	  uint *bitstring of given >>uint vector length<< (not bitstring
	  length).
	  
	  Other test controls may be added as well, but these are what I'm
	  going
	  to document right now. Mostly I'm checking in all the
	  placeholders
	  required for the rest of the diehard tests so I can start to
	  knock them
	  off systematically. Sure hope I'm past major rewrites!

2004-11-20 08:07  rgb

	* : Fixed silly spelling error (sigh).

2004-11-20 07:50  rgb

	* : Well, that was quick. A nasty (but easy) little bug in
	  diehard_runs
	  squashed (size -> tsamples).

2004-11-20 07:47  rgb

	* : This should/maybe be a serious v 0.5.3 checkin. We are about to
	  try
	  -v -1. If it works, it will cycle through all of the working
	  tests
	  (and all the tests are working). All the tests are now written in
	  a way that they can use sample and kstest_kuiper() to do the
	  validation
	  of the p-values obtained from running a possibly size-variable
	  test
	  on bits or frequencies or runs or whatever.
	  
	  If this test works, it is off to the website, I'm off to bed, and
	  next
	  we go back to moving in new diehard tests. With the magical
	  sliding
	  bitwindow (which really does seem to work pretty well:-)
	  implementing
	  at least the n-tuple diehard tests should now be pretty easy, and
	  I
	  can probably do a more rigorous job than GM did because I don't
	  have
	  to scrimp on rands.

2004-11-20 07:34  rgb

	* : Try again (network down).

2004-11-20 07:34  rgb

	* : This clears diehard_birthdays AND diehard_2dsphere. Only one
	  diehard
	  to go and we'll have EVERYTHING running with sample and the new
	  test
	  format (but of course rgb_persist, which doesn't count).

2004-11-20 03:11  rgb

	* : Fixed up diehard_runs so it uses the new test format. Works
	  charmlike.

2004-11-19 23:38  rgb

	* : This is v 0.5.1, which is nicely fixed for BOTH sts_monobit AND
	  sts_runs, both in the new format, with a consistent Xtest_eval()
	  routine. This fixes lots of things -- both tests are very likely
	  to be "good".

2004-11-19 23:34  rgb

	* : OK, this looks like sts_runs is now "good" in the new format.
	  However,
	  it may have broken sts_monobit. The problem is, is there or is
	  there
	  not a sqrt(2.0) in the erfc relative to sigma, and if there is is
	  there an EXTRA one in sts_runs vs sts_monobit. Need to clear this
	  up
	  and either always put it into Xtest or always put it into
	  xtest.sigma,
	  but not both.

2004-11-19 21:06  rgb

	* : Sending this home, I hope.

2004-11-19 20:09  rgb

	* : This is now squeaky clean for rgb_bitdist and sts_monobit, and
	  we're
	  working on sts_runs. Then a quick dash through the diehards and
	  we'll
	  be back to where we were but a bit cleaner.
	  
	  I still MIGHT try to get cleaner still. I'm not at all convinced
	  that I need the test structs, for example, although perhaps they
	  allow some encapsulation that is useful.

2004-11-19 18:55  rgb

	* : This is a checkin to Duke of the nifty neato cool new improved
	  version. It may be time to change the name and everything.

2004-11-19 17:35  rgb

	* : OK so there was one more teeny bug in rgb_bitdist() -- wrong
	  order in
	  the final output statement. Fixed. I also added a feature,
	  reseeding
	  the rng in sample on an -i flag.

2004-11-19 17:28  rgb

	* : This is just ensuring that the tag for version 0.5.0 is noted.
	  This
	  version works through rgb_bitdist, which I'll bet a nickel is a
	  very
	  powerful test indeed.

2004-11-19 17:26  rgb

	* : This is a "permanent" checkin. I think that this fixes
	  rgb_bitdist
	  nicely to use sample() and provides a prototype for doing other
	  tests.

2004-11-19 02:09  rgb

	* : This is a fairly major fix -- I was truncating blen in bits.c
	  at
	  the sizeof(uint), not 8*sizeof(uint). One lesson is that this
	  truncation isn't right anyway. We rather need to just punt/die.
	  
	  I'm wondering now if the apparent failure that is still present
	  (although not nearly as bad) for the larger ntuples is because
	  fewer
	  bins pass the cutoff in the formation of the primary sample
	  pvalue(s).
	  
	  We might just try lowering this cutoff a bit. I don't know
	  exactly what
	  a "degree of freedom" is, but we do need to be pretty careful
	  with it.

2004-11-18 23:43  rgb

	* : Now it REALLY looks like it works, and even the best rng's look
	  like
	  they FAIL the test in fairly short order. Now we're cookin' with
	  gas,
	  although I've got to see the details of the failure soon enough.
	  
	  Hmmm, maybe I need to have a lot more bins...

2004-11-18 23:25  rgb

	* : Just to verify that it APPEARS to work to quite high precision
	  through
	  triplets. We could just keep adding things, I suppose...

2004-11-18 23:17  rgb

	* : This is now working. Working amazingly well, actually. Well
	  enough
	  to double the size of the bits in rgb_bitdist_test().
	  
	  The one MAJOR remaining problem is that I cannot use samples for
	  tests
	  that return a vector of pvalues. Oh, and it is fairly difficult
	  to
	  pass arguments to the testing function in when it is an argument
	  TO
	  samples().
	  
	  This means that I have two itty bitty problems to solve -- one is
	  to
	  pass in parameters (possibly by making them global variables).
	  This
	  makes sense IF I want to be able to control them from the command
	  line
	  anyway. The other is to return a vector of pvalues. The only way
	  I
	  can think of doing this is to make pvalues[] a global vector as
	  well
	  of length (say) 1K. This puts an upper bound on the number of
	  pvalues
	  that can be returned by a test, but that SHOULDN'T be much of a
	  problem,
	  as it is really a question of what granularity one wishes to
	  evaluate p
	  at.
	  
	  Anyway, just a BIT more work and rgb_bitdist should be production
	  ready,
	  AND I should be perfectly ready to clean up p-sampling and
	  testing as
	  separate entities in the other tests.

2004-11-18 22:28  rgb

	* : This MIGHT be working.

2004-11-18 20:42  rgb

	* : I sent this home, I did, I did.

2004-11-18 20:08  rgb

	* : This is still fairly screwed up, at least in the sense that
	  it doesn't look like rgb_bitdist works. Curiously, it LOOKS like
	  it WORKS -- walking through the code, it looks VERY much like it
	  is collecting two bits at a time and correctly incrementing the
	  correct bit count in the correct vector.
	  
	  The final histogram, however, comes out wrong, wrong, wrong.
	  
	  I may have to make this simpler. Or maybe I'm doing something
	  else
	  wrong -- come to think of it, the totals in the histograms
	  shouldn't
	  equal the number of samples for EACH value of the ntuple, only
	  the
	  total should sum to the number of samples. Maybe this is what is
	  wrong...

2004-11-18 16:27  rgb

	* : We have to go into Duke, but we are very much ready to finish
	  off bits.c
	  and rgb_bitdist.c to where we can eliminate BOTH rgb_binomial AND
	  rgb_bit2.c AND at least one, maybe 3-4 diehard tests AND a couple
	  or
	  three sts tests as being equivalent to this test, for particular
	  call
	  values. I have great hope that this rgb_bitdist will become "the"
	  bit
	  frequency test for all random bit sequences. There may still be a
	  point
	  to tests that look at intervals >>between<< bit sequences
	  thought.
	  
	  In fact, I suspect that the best way to proceed with the latter
	  is to
	  test lagged correlation for arbitrary lags in a long bitstring.
	  This
	  SAME TEST applied with arbitrary displacements between samples
	  might be
	  revealing...

2004-11-17 19:57  rgb

	* : This is HIGHLY BROKEN but is absolutely necessary. We have to
	  break
	  this code up to unify the replicated pieces and streamline the
	  testing processes now that we know how a test "works" in the
	  abstract.

2004-11-17 03:40  rgb

	* : A bugfix commit. The sanity check in get_bit() is broken and is
	  commented out -- if I'm going to allocate rand_int[] vectors
	  other than
	  size in length, I cannot test on a global size to see if
	  get_bit() is
	  out of bounds. This is STILL broken in that there is a risk with
	  no
	  warning, but there is also functionality for the moment (and I
	  have
	  to write a bunch of new bitlevel functions and can rewrite
	  get_bits
	  at the same time).
	  
	  More important, I found a real bug in Btest where I was
	  initializing
	  btest->chisq to zero before accumulation but was accumulating in
	  chisq.
	  Curiously, it worked a lot of the time the old way, but only for
	  certain
	  rng's. I may have memory management problem, which isn't
	  surprising
	  given the slovenliness of the code at this moment...;-)
	  
	  rgb

2004-11-16 23:46  rgb

	* : This is a tagged checkin, about to push.

2004-11-16 23:45  rgb

	* : This appears ready for a checkin.

2004-11-16 23:19  rgb

	* : This appears to FINALLY fix rgb_binomial so that it reliably
	  works.
	  It remains to be seen whether or not it is any more senstitive
	  than e.g.
	  sts_monobit.

2004-11-16 20:11  rgb

	* : This is STILL broken as far as the Ntests are concerned. I've
	  really
	  got to figure this out...

2004-11-16 15:51  rgb

	* : Send this to Duke to finish this morning.

2004-11-14 17:40  rgb

	* : This is a pretty serious bugfix -- probably need to update the
	  website.
	  Basically, my kstest was simply wrong last night; now it is
	  working,
	  I've also added the Kuiper form of the KS test, and will program
	  Anderson and Darling's version (the one used, apparently, in
	  Diehard)
	  when I get around to it. However, for tests involving more than a
	  very
	  few p-values in a vector, it shouldn't really matter -- Kuiper KS
	  and the
	  regular KS and Anderson-Davis KS should all GENERALLY generate
	  similar
	  p-distributions -- different perhaps where they don't matter, but
	  very
	  similar at the ends. The key question is just whether one has a
	  tendency to pass a vector of p-values where the other would
	  consistently
	  fail it. So far it looks like USUALLY if one fails the other
	  fails.
	  
	  I think I'm still going to want to do a histogram picture of
	  binned
	  pvalues and do a Pearson chisq p-test on the result. This should
	  really
	  be pretty easy... maybe today, maybe not.
	  
	  We're getting close to being ready to go BACK and mess with the
	  Ntest
	  and Xtest stuff. I think that now that I understand Pearson vs
	  the
	  alternatives, I can PROBABLY arrange things so that I can use a
	  single
	  set of common tools to do all the test assessment.
	  
	  One thing, for example, would be to make each test return a
	  p-value,
	  period, and put the samples loop in rand_rate_work, to ALWAYS
	  fill a
	  vector of p-values and ALWAYS do KS tests, confidence interval
	  tests,
	  and histogram tests. This would have a number of advantages --
	  being
	  able to produce a really pretty, really standardized picture of
	  results
	  for one.
	  
	  A second thing that would make this tool relatively interesting
	  to the
	  mass unwashed would be to put a nice little GUI onto it. There
	  are two
	  generic ways to do this. One is to leave it a command line tool
	  but
	  REALLY clean up the output result so that it is just a single
	  line
	  per test with ks test scores for the various forms of test with
	  three
	  lines of # delimited frame, period. Then I can make a perl-Gtk
	  app to
	  call the binary, parse the result, and (e.g.) plot histograms or
	  do
	  other nifty graphical things. The other is to use Gtk directly,
	  but
	  perhaps have the GUI only come up if there is an appropriate
	  command
	  line flag (or not).
	  
	  A third thing to work on is clearly going to be splitting the
	  source
	  into distinct components in distinct directories. We will need a
	  common
	  library containing the kstest, chisq, Ntest, Xtest etc code, the
	  input,
	  the output, etc. We will need a directory containing extensions
	  to the
	  GSL random number library, e.g. /dev/random, /dev/urandom, empty,
	  and
	  shuffled because the one thing that is absolutely true is that we
	  need
	  to add a shuffling/mixing random number generator, one that
	  permits us
	  to set up a shuffling list and refill it from a secondary LIST of
	  rng's!
	  
	  A fourth thing (noted already elsewhere) is to do the simplest of
	  tests
	  -- apply a KS test to the GSL distribution-specific generators
	  themselves. If a "test" is generically generating a known
	  distribution
	  presuming randomness and then seeing if the result is indeed the
	  targeted distribution, then EVERY distribution generator in the
	  GSL can
	  simultaneously be the target of a test for algorithmic purposes
	  AND a
	  test component for the GSL rng's.
	  
	  Beyond that, I need to implement spectral tests and tests for
	  hyperplanes in N dimensions and uniformity tests. Sigh. I think
	  that I
	  DO need to write a grant proposal for this -- I think there is
	  enough
	  work to justify it.

2004-11-14 09:38  rgb

	* : Tagged and on the repository as 0.4.3, with diehard 3d spheres
	  and a
	  MAYBE working KS test.

2004-11-14 09:37  rgb

	* : Sort of playing with KS -- I'm not done here yet...

2004-11-14 08:04  rgb

	* : OK, found my REALLY stupid bug. I was computing the absolute
	  length of r from the origin, not the distance between point
	  pairs.
	  No, I wasn't even doing that well -- I was computing the dot
	  product
	  of the random vectors. Now things look nearly correct.
	  
	  All I need is a KS test and life would be, if not complete, well,
	  worth
	  living.

2004-11-14 07:22  rgb

	* : This "works". Except that it doesn't. It's very odd, but
	  although
	  it works perfectly as far as I can tell by any measure, r is
	  simply not
	  as small as it should be in order to make the pvalue come out
	  between
	  0 and 1.

2004-11-14 01:19  rgb

	* : THis is on the way to being another test.

2004-11-13 22:19  rgb

	* : This is hopefully a tagged snapshot with a new test!

2004-11-13 21:50  rgb

	* : OK, time to bump the revision number, as birthdays is home and
	  even
	  works tolerably, as far as I can tell.
	  
	  SOON I'm going to do the KS test on vectors of p's. SOON I'm
	  going to
	  really clean up the code so that chisq -> p is consistently
	  computed,
	  and so that a set of p's is consistently evaluated for the
	  random/nonrandom decision.

2004-11-13 17:17  rgb

	* : This is it, ready to proceed.

2004-11-13 17:12  rgb

	* : This checks in a placeholder for a Kolmogorov-Smirnov test,
	  likely to
	  be applied to a vector of p-values.

2004-11-13 17:06  rgb

	* : We'll commit this for the moment. I think the sensible thing to
	  do is
	  to create as general as possible a tool for generating Pearson's
	  chisq
	  for discretely binned data, in particular and immediately for the
	  Poissonian birthday histogram but also for other purposes. Note
	  that
	  these routines should not only generate chisq, but when possible
	  go
	  ahead and compute goodness of fit p-values, ideally in a vector
	  associated with independent trials. This vector of p-values can
	  itself
	  then be subjected to a kolmogorov-smirnov analysis and
	  transformed into
	  a conclusion for the generator being tested.

2004-11-13 09:34  rgb

	* : Just added output of lambda, which is indeed 2 with the
	  parameters
	  given...

2004-11-13 09:32  rgb

	* : This is REALLY CLOSE to having diehard birthdays finished. We
	  just
	  need to add a chisq test for Poisson distributions sampled
	  samples times
	  with known (per sample) lambda, and a loop to convert a table of
	  chisq into
	  a table of p-values. I'm tempted to bump minor and tag, but I
	  shouldn't
	  need to -- I've been really careful and things really look like
	  they're
	  working so far.

2004-11-13 02:02  rgb

	* : This is a simple checkin prior to doing diehard birthdays test.

2004-11-13 01:32  rgb

	* : This splits off the confidence interval test from STS docs.

2004-11-13 01:28  rgb

	* : This is a small adjustment (still in 0.4.1 I guess). Let's try
	  another
	  diehard, I think.

2004-11-13 01:16  rgb

	* : This is actually a fairly functional diehard test!
	  
	  I think that we can actually implement a test for the uniformity
	  of
	  p-values as suggested by NIST to run on TOP of the existing
	  confidence
	  interval test. This would actually break the p-distribution down
	  by
	  interval and return a p-value of its own computed against the
	  assumption
	  of uniformity. Or I could get fancier and try kolmogorov-smirnov,
	  if
	  GSL doesn't have one and I work hard enough to program one. If
	  this is
	  really distinct -- it isn't clear that it is.

2004-11-12 22:32  rgb

	* : This is actually sort of semi-functional. What I >>really<<
	  need now
	  is canned Kolmogorov-Smirnov code. Could it be that this is in
	  the
	  GSL already? I'll be it is...

2004-11-11 15:59  rgb

	* : Continuing to hack this up.

2004-11-10 22:19  rgb

	* : This is a nearly functional diehard_runs -- I just need to
	  figure out
	  what the expected values and sigmas are...

2004-11-10 05:32  rgb

	* : This is simply lovely. A nice litte addition to the Makefile
	  that
	  automatically indicates the current version in the abstract. I
	  actually
	  have things fairly distributable!

2004-11-10 05:24  rgb

	* : OK, added a few minor changes to manage the bits issue yet
	  another way.
	  
	  Really, I'm going to have to figure out a consistent way of
	  indicating
	  whether a test can have size OR bits OR both OR neither
	  specified.
	  
	  Also, it would be really lovely to have another outer loop and to
	  present the lowest p in a set of (say) ten runs of a test combo.
	  Although in many cases running with -s 10x larger should do the
	  same
	  thing, really.

2004-11-10 04:53  rgb

	* : This is it and running, version 0.4.0 as published. Seems to
	  work.

2004-11-10 04:53  rgb

	* : One last checkin, then a tag, then a checkin as published.

2004-11-10 01:43  rgb

	* : This is a tagged release, mostly bugfixes. At the moment it all
	  looks
	  like it works.

2004-11-10 01:37  rgb

	* : This seems to work perfectly, for the very short moment. It is
	  by no
	  means perfect or mutually exclusive. We very definitely need to
	  generalize the bitdist test to handle bit ntuples of arbitrary
	  length,
	  where the length is a variable.
	  
	  I think I'll retag this. It is also probably time to think about
	  putting this up on the website, especially if I'm going to write
	  a
	  proposal on it.

2004-11-09 22:14  rgb

	* : Because it wasn't checked in!

2004-11-09 22:14  rgb

	* : Why didn't bit2.c go home?

2004-11-09 20:09  rgb

	* : This is going home with a split out routine and some nice
	  changes that
	  will make it easier to add new tests with arbitrary numbers.

2004-11-09 19:30  rgb

	* : Just checking repository Root.

2004-11-09 19:30  rgb

	* : Let's send this home...

2004-11-09 14:51  rgb

	* : OK, fixing Makefile to actually get this home, AND adding the
	  URL
	  of the web reference from the last checkin:
	  
	  http://world.std.com/~franl/crypto/random-numbers.html
	  
	  (we need to implement some of its hyperplane tests).

2004-11-09 14:48  rgb

	* : We're actually working on this once again. I need to get my own
	  "runs"
	  test working, as it will replace a whole RANGE of STS, and I need
	  to
	  implement a spectral distribution test with bins as is done in
	  the
	  nice web reference I found.

2004-11-08 14:52  rgb

	* : This adds yet another built-in device to GSL.

2003-06-10 15:21  rgb

	* : This adds an "empty" generator to help us determine gsl call
	  overhead
	  separately.

2003-01-30 22:16  rgb

	* : This is broken as shit. I see what I did -- I made the ntest
	  evaluation
	  and presentation routines use n+1 bits (because in rgb_binomial I
	  needed
	  to do the end of the binomial). However, I have to fix it
	  later...

2003-01-30 20:12  rgb

	* : Forgot to send this...

2003-01-29 19:19  rgb

	* : Not obviously broken, and time to add bitpair counters. Should
	  be
	  really easy -- left-shift in two bits at a time to creat the int
	  index
	  of the counter, then increment it.

2003-01-29 14:27  rgb

	* : Some NOTES on future work.

2003-01-29 14:14  rgb

	* : This checks in a whole new test, which should probably be
	  combined with
	  sts_monobit (it generates monobit stats as it goes)
	  rgb_persist (one can easily generate a bitmask as one goes)
	  rgb_binomial (one can generate binomial stats on top of monobit
	  as one
	  goes).
	  
	  and possibly with more tests.

2003-01-26 07:54  rgb

	* : This last little pair of changes causes measure_rate to use its
	  own,
	  fixed, number of samples ("more than enough"). It also installs a
	  "summary report" mode that isn't horribly useful because of
	  conflict
	  between e.g. -b, -n, -s definitions here and there. Also,
	  different
	  tests need to be run in different ways to demonstrate failure (or
	  a
	  lack thereof).

2003-01-26 07:23  rgb

	* : OK, we haven't done TOO much, but we have definitely learned
	  that
	  all the rng's that are weak in rgb_persist will definitely fail
	  the
	  monobit test (for obvious reasons). Furthermore, when a generator
	  is weak in certain bits and we evaluate the bits from the other
	  end
	  (whichever end that might be!) it can often PASS the monobit
	  test.
	  
	  Bits that repeat, random_max's that aren't powers of two-1 (and
	  probably
	  EVEN powers of two at that) are going to be trouble!

2003-01-26 05:00  rgb

	* : This is a VERY IMPORTANT new test, rgb_persist(), and a very
	  useful
	  new routine, dumpbits(). Read NOTES (and inline comments and
	  output)
	  to see a bit of what it does and why it is important.

2003-01-25 21:55  rgb

	* : This actually works. In fact, it works fabulously. I can
	  directly
	  and fairly powerfully look for bitlevel correlations in the
	  output.

2003-01-25 20:53  rgb

	* : OK, we've learned the hard way that some bits in e.g. boroshi
	  don't
	  change AT ALL, EVER. Which makes it pretty hard to be random, of
	  course.
	  
	  So we're going to invent a new tool -- rgb_persist(), which
	  doesn't
	  (yet) to a formal statistical test. It just is going to dump
	  successive
	  unsigned ints from the rng (bitwise) AND maybe run a string of
	  &'s on
	  the string of ints returned. If they share any 1 bits, the
	  successive
	  &'s will preserve them a LOT longer than permitted by binary
	  flips on
	  the slots.
	  
	  This could be made into a fairly powerful bitlevel sequential
	  correlation test in several ways. We'll investigate them as we
	  go, but
	  one reason to write this now is that I'm not quite convinced that
	  what
	  I'm seeing isn't some sort of bug in the get_bit() routine or the
	  like.

2003-01-25 15:54  rgb

	* : This is well on the way to being MUCH better, and ready to
	  systematically extend.

2003-01-25 00:50  rgb

	* : And now we send the tagged package to Duke.

2003-01-25 00:50  rgb

	* : Checking in the notes.

2003-01-24 22:52  rgb

	* : This is worth a minor bump. First, we fixed get_bit(). Second,
	  we
	  completed sts_runs (for what it is worth, which isn't a whole lot
	  as
	  nearly everything that fails it also fails monobit and binomial
	  as
	  expected). However, working through it suggests how to make
	  binomial
	  work better.
	  
	  Next (to make it easier to check results relative to the sts
	  documents)
	  I need to implement -b (get_bit(0 permits this pretty much
	  transparently, at least in the sts routines) and implement a -f
	  filename
	  filled with e.g. raw bitstrings or ascii floats or binary numbers
	  in xmlish wrappers that indicate the storage mechanism? Thus I
	  can test
	  explicit short bitstrings against the explicit sts numbers to be
	  sure
	  that my erfc and conversions (and sometimes slightly different
	  implementation) yield the same answers as theirs, except where I
	  don't
	  care because I think theirs are (basically) wrong.
	  
	  See also NOTES (about to be checked in) for a fairly detailed
	  beginning
	  critique of sts, which I don't think is particularly strong or
	  useful,
	  really.

2003-01-24 21:43  rgb

	* : This is my home-grown version of sts_runs. It is no better than
	  the
	  actual sts version, really, but the sts version is not terribly
	  good.
	  I'm going to add a (hopefully vastly improved) binomial version
	  of the
	  test to rgb_binomial, where I can do all the tests at once with a
	  single set of code and multiple trials (random number seeds).

2003-01-23 05:51  rgb

	* : Just adding some notes, and preparing to add the next sts test,
	  TOMORROW.

2003-01-23 04:52  rgb

	* : I have no idea why the tag went down into fitany...

2003-01-23 04:52  rgb

	* : This ups the minor revision number to 0.3.0. Worthwhile because
	  now I
	  have BOTH an erfc AND a Q evaluation of p-value. I could
	  certainly
	  prettify sts_monobit, but since I generally think that it isn't
	  that
	  great a test (although it does indicate how starkly many rng's
	  FAIL to
	  be even this random) I won't do so right away.
	  
	  Next (after tagging and resync'ing) is going to be adding more
	  tests.
	  At this point adding a test should be pretty easy, given the
	  hopefully
	  reusable routines I have written to do the pre- and post-
	  processing.
	  All I really have to do is input the expected values, write a
	  loop to
	  generate the "experimental" statistic, and pass everything on to
	  a
	  standard set of tools for outputting the results and deciding on
	  the
	  quality of the results.

2003-01-23 04:46  rgb

	* : All right, this LOOKS like it correctly implements the STS
	  monobit
	  frequency test. I would still claim that anything that fails this
	  test
	  will also fail the binomial test, and that in addition things
	  that pass it
	  (e.g. the vax rng) FAIL the binomial test, so the monobit test is
	  a waste of time and more prone to error. However, mine is not to
	  reason
	  why...

2003-01-22 18:04  rgb

	* : This is working incredibly well, and I've split off nearly
	  everything
	  required to make further n-point chisq tests trivial to implement
	  and
	  assess. All that remains is to do a 1-point (normal) test such as
	  the
	  sts_monobit test (which should really be done internal to the
	  rgb_binomial test and may one day be, but for the moment we'll
	  just do
	  it directly).

2003-01-22 13:33  rgb

	* : Just making SURE this is at Duke...

2003-01-21 23:56  rgb

	* : This works just lovely!
	  
	  HOWEVER, it is also clear that running it once, twice, three
	  times,
	  for EACH generator looking for good ones is a PITA. We'll have to
	  eventually rearrange this so that there is a "search mode" that
	  runs
	  a loop through all known generators, identifying the ones that
	  pass at
	  least at the 1% or higher level.
	  
	  BTW, I'm now prepared to bet a nickel that the rgb binomial test
	  has a
	  great deal of sensitivity, since it fails all but literally three
	  or
	  four of the available RNG's for absurdly short data strings. As
	  in they
	  aren't even APPROXIMATELY random...NONE of them. If one used them
	  to
	  generate a humble binomial distribution numerically it would be
	  in
	  significant error.
	  
	  I do need to alter this test so that I can run it for arbitrary
	  bit
	  string lengths, but for the moment I'm not going to worry about
	  it.

2003-01-21 21:40  rgb

	* : This is now VERY CLOSE. I should be able to determine chisq in
	  a matter
	  of minutes when I return...

2003-01-21 19:05  rgb

	* : This is considerably cleaner and more decrufted...

2003-01-21 18:35  rgb

	* : This finishes the split off of list_rand and list_rngs from the
	  code.
	  I do need to "fix" the Usage() routine to reflect the change.

2003-01-21 18:08  rgb

	* : Breaking things up into subroutines a bit better to clarify the
	  program
	  structure.

2003-01-17 20:37  rgb

	* : This is coming along, although I'm silly for not just finishing
	  the
	  monobit test before introducing a binomial test. Still, all very
	  instructive.
	  
	  I need to get all this on my laptop and take it with me, along
	  with the
	  notebook.

2003-01-17 19:28  rgb

	* : Fixes a nasty bug in sts_monobit, which I think I'm gonna
	  rename
	  rgb_binomial (and screw sts's monobit test, which is immensely
	  sloppy
	  compared to actually systematically exploring the binomial
	  distribution
	  of 1's and 0's in the overall bit strings generated by different
	  seeds.
	  
	  Actually, a better thing still is to leave sts_monobit, but add
	  rgb_binomial and document that it is more sensitive (in
	  particular, that
	  e.g. alternating series that easily pass monobit fail binomial,
	  and that
	  NOTHING that fails monobit will PASS binomial).

2003-01-17 06:06  rgb

	* : Sending off the tag

2003-01-17 06:06  rgb

	* : OK, this is good for a full minor number bump to 0.2.0. We have
	  basically installed the guts of the STS monobit test. All that we
	  lack is the computation of the statistics and p-value, which
	  should be
	  fairly straightforward, especially with the gsl handy. I SHOULD
	  be
	  able to just cumulate the one-count (e.g.) in a vector and hand
	  it to
	  the gsl stats routines and have mean, stddev, skew, kurtosis, and
	  anything else I might like just handed back to me...

2003-01-17 05:16  rgb

	* : Just a bit of cleanup, and some moderately important additions.
	  
	  Now we REALLY need to think about tests.

2003-01-17 04:23  rgb

	* : Tagged.

2003-01-17 04:23  rgb

	* : This is about ready for a semipermanent snapshot, so I bumped
	  the
	  minor version number. I'd say that we are now "good" with the
	  ability
	  to add sw rng's, including interfaces to hw rng's square within
	  the gsl
	  format.
	  
	  Now to give de old tests a try...

2003-01-17 03:54  rgb

	* : Hot diggity dawg! It works! However, I don't need types.c. All
	  I
	  need is to follow the dev_random.c template and call a routine
	  add_my_rngs() (to be defined) before working with gsl's rng's,
	  and
	  keep track (crudely) of which ones are which. So this can be
	  decrufted
	  a bit and then reorganized now that I know how it works.

2003-01-17 02:54  rgb

	* : We'll try these as the basic wrappers required. With luck we'll
	  override the types subroutine in gsl itself, although I do have
	  my
	  doubts...

2003-01-17 02:38  rgb

	* : This significantly improves the Usage and cl parsing, and
	  pre-structures
	  it for addition of sts/diehard tests.
	  
	  We still need to see if we can gsl-wrap our own tests without a
	  full
	  gsl recompile.

2003-01-16 20:40  rgb

	* : Sending the tagged copy home...

2003-01-16 20:40  rgb

	* : This is now going to be v_0_1_0.

2003-01-16 20:39  rgb

	* : This is now functional UP TO all the gsl rngs, not any of the
	  add-ons.
	  
	  Which is fine, as we'll probably completely change how the
	  add-ons work.
	  
	  Next, we need to do all of the following, in some order:
	  
	  a) figure out how to wrap up new gsl_rngs, preferrably without
	  recompiling the whole damn library.
	  b) decruft all the command line options and no-longer-used
	  variables.
	  c) add back command line options for doing quality tests. Start
	  with
	  the very simplest test -- something from diehard or the bits test
	  from
	  sts.
	  d) In the meantime, increment revision, tag, and consider
	  "publishing"
	  as we go.

2003-01-16 20:14  rgb

	* : This SHOULD split rand_rate off so it has its own CVS tree
	  outside of
	  the "random" project overall, which I think is for the best.

2003-01-16 20:13  rgb

	* : This actually works, and needs to be saved in snapshot form.
	  I'm not
	  at ALL certain that I'm getting accurate measurements in terms of
	  the
	  number of rands per second I can generate, but this too, we shall
	  see...

2003-01-13 22:12  rgb

	* : This is a fair amount of progress to having something
	  working...

2003-01-12 00:07  rgb

	* : This is basically the original checkin for my lookin-major
	  random number
	  project. By the time this is done, I'd doggone better have a
	  paper or
	  two out of it, if not more.

