1------------------------------------------------------------------------ 2r529 | rgbatduke | 2011-04-01 13:49:31 -0400 (Fri, 01 Apr 2011) | 117 lines 3 4OK, this is a fairly enormously major brutal checkin. Both dieharder 5and libdieharder are ALMOST -Wall -pedantic clean. To get it there I 6had to learn several things, such as how to get gcc to ignore "unused 7variables" that are conveniently in a shared include file but aren't 8really used in all the modules that share it, the fact that the various 9flavors of C have varying "maximum string size guaranteed to be 10supported" limits (none of which are really relevant to gcc, but it 11complains about them anyway), and more. And of course I had to delete 12all the cruftish lines of e.g. unused loop variables. I'm not quite 13done with cleanup -- I may have gone overboard in a place or two and may 14need to put some things back or address things that might affect 15function -- but I want to get this all checked in. 16 17There are two build errors left -- one is in dieharder/rdieharder.c (and 18hence is yours, Dirk) and the other is in the skein code (and hence is 19yours, David). David, I also need you to check a fix I made to the 20rng_threefish code -- I finally took the time to figure out the dread 21"dereferencing type-punned pointer breaks strict aliasing rules" 22warning. I replaced the offending line: 23 24 *((unsigned long int *) state->block) = s; 25 26with 27 28 unsigned long int *blockptr; 29... 30 blockptr = (unsigned long int*) &state->block; 31 *blockptr = s; 32 33That is, I read what you were trying to do as "Set the contents of 34state->block, cast to an unsigned long int pointer, equal to unsigned 35long int pointer s" which might work but gcc -Wall hated it even before 36-pedantic and (from what I've read) can have undesired side effects. So 37I introduced an actual unsigned long int pointer, put the address of 38state->block in it, and the set its contents equal to s. It didn't seem 39to break threefish -- I tested the first few returns before and after 40the fix with -S 1 and they were the same -- and I'm using threefish 41right now in a validate.sh run to make sure that I didn't egregiously 42break dieharder with all of the changes. 43 44Changes you should be aware of: 45 46 * To avoid most of the "too long string" errors I went to -std=c95, 47which permits strings a page in size (4095 bytes). That accommodates 48the auto-documentation strings in the test headers. There may be 49another way of doing this -- in fact there are probably two or three -- 50but to alter the dh headers at this point would (marginally) break the 51API so it will need to wait for v4, I think. Apparently gcc is about to 52be dressed up with an __attribute__ that will probably enable extra 53large or unlimited data strings without complaints which is sensible 54enough since it works on them anyway AFAICT. 55 56 * c95 turned off uint translation . I went through a huge block of 57code turning uint into the two words unsigned int before getting 58irritated enough to look at the headers where I discovered that yeah, 59you can turn on the uint -> unsigned int macro with a suitable define. 60So I did. 61 62 * c95 turned of BSD math macros in math.h, including M_PI. That 63seemed really silly, so I turned them back on with a suitable define. I 64didn't turn on the long forms (they only really make sense for long 65doubles) but we can do that if we ever need PI to 24 places or whatever 66it was. 67 68 * -Wall -pedantic really hates any sort of data that is included in a 69source file where it isn't used. If we were all perfect programmers, I 70suppose that we would create enough include files and control where they 71were included precisely enough that no source file even included an 72include file with a variable it didn't actually use. Alas, I'm not a 73perfect programmer and lots of the data structures used only inside 74certain tests or by certain generators are shared via libdieharder.h 75with program modules that don't use them. Adding 76__attribute__((unused)) after the definition but before the = sign 77basically tells the compiler "Yes, I know, I planned it that way, now 78shut the fuck up" and passes them through -pedantic without complaint. 79 80I suppose that the virtue of the check is that it helps prevent 81namespace collision, but of course the compiler checks for that anyway 82and general local vs global rules seem like they would handle any 83accidents that crop up the right way. If I feel really, really 84energetic someday I may go and segregate out the data and either add it 85to the sources directly (in a lot of cases that's a good place for it 86anyway) or put it in a separate include file per module. OTOH things 87like the dh headers are shared because I DO access content from them in 88lots of places and want to be able to get to it from anyplace, so there 89will always be some ((unused)) attribute variables in the program. 90Printing out the test description string for any given test, or looking 91up the default tsamples or psamples, for example, is something any sort 92of application that uses the libdieharder library might want to do. 93 94 * As per current GBT recommendations and Dirk's suggestions, all of 95the auto-whatever stuff in autogen.sh is now basically a single 96autoreconf call. In fact, it looks like they made autoreconf just 97because getting all of the things just right after a major GBT update 98is, in fact, the pain in the ass that it has been to me from the 99beginning, so this is rather a relief. I did leave the configure call 100in the bottom, so running autogen.sh should still take one from a clean 101checkout to make-ready, or of course you can enter autoreconf by hand 102and run configure by hand as per usual. Hopefully this will all make 103Debianheads happy...;-) 104 105Things that I have NOT done yet -- this checkin is basically six hours 106of work from 9 to 3 am plus another couple of hours today, so I'm 107working as fast as I can as it is -- include debugging the endian 108problem in the threefish (or was it AES?) code on e.g. a sparc or 109powerpc set to the other endianness and dealing with a few real bug 110reports that have come in from users already. I wanted to get the code 111clean first as who knows, maybe doing so will help solve the problem? 112 113SO, if you guys could each fix the two remaining problems (or tell me to 114play through in spite of the fact that I'm not sure what is being 115accomplished and what would break what) then I'll try to move on to the 116next step. 117 118 rgb 119 120 121------------------------------------------------------------------------ 122r523 | rgbatduke | 2011-03-10 11:09:12 -0500 (Thu, 10 Mar 2011) | 4 lines 123 124A last minute oops. I wanted to mark operm5 as good, and mark all of 125the monkeys suspect (as they can pretty easily be run to failure for 126good generators still). 127 128------------------------------------------------------------------------ 129r510 | rgbatduke | 2011-01-07 16:19:40 -0500 (Fri, 07 Jan 2011) | 31 lines 130 131This is a WORKING snap and bump to 3.29.6beta. I actually fixed several 132things that I broke before in the rng selection process. New features: 133 134 rng_kiss -- a damn fine rng. Faster than mt, better than mt except for 135period. 136 137 rng_XOR -- Select this rng, and a list of others, e.g. 138 139 ./dieharder -g 207 -g 208 -g 14 -g 6 -g 205 -a 140 141dieharder will then return the output of 208 (kiss), 14 (mt19937_1999), 1426 (gfsr4) and 205 (aes) all xor'd together. Period infinite, no LESS 143random than the MOST random of the generators alone. The price you pay 144is sure, 2, 3, 4 times slower. But this is now the official gold 145standard dieharder testing generator, as finding something randomer will 146be difficult and of longer period impossible (what is the least common 147multiple of 19937, 121, and all the rest? 2 to that power, like that). 148 149I'm working on superkiss, a vectorized version of kiss with an insanely 150long period, but the double precision part is broken and I don't see 151why. The integer part works. I'll figure it out maybe tonight, and 152have a few other Marsaglia generators to add. 153 154Then I'll return (finally) to tests, with the gold standard generator 155well and truly in place. At least three dieharder (diehard) tests are 156broken, and I'd like to fix at least ONE of them before I get bogged 157down teaching again. 158 159 rgb 160 161 162------------------------------------------------------------------------ 163r508 | rgbatduke | 2010-02-19 13:13:56 -0500 (Fri, 19 Feb 2010) | 9 lines 164 165Oops, forgot to update FIRST. This should get me back in sync. You 166guys should ignore this; I'm rearranging my whole source tree on my 167laptop(s), dieharder included, and am just trying to make sure that the 168rebuilt one is clean. 169 170I also haven't completely forgotten the last post/request for interface 171room -- I've just been insanely busy and haven't had time to even think 172about it for the last few weeks. But I will get back there, I promise. 173 174------------------------------------------------------------------------ 175r498 | rgbatduke | 2009-10-28 01:48:25 -0400 (Wed, 28 Oct 2009) | 28 lines 176 177Wow, a lot of stuff. This checkin contains a working -Y 2 option for 178"test to destruction" where ttd is by default a return pvalue of 1790.000001 or less OR getting to 10000 samples alive (both parameters 180can be set on the command line with -X tolerance and -Z cutoff). I 181actually did it two ways, and will keep the second (better) one and 182shortly remove the cruft in std_test.c. In addition I had to update the 183help, I updated the output routines in output_rnds so I could dump a 184list of formatted floats (to test another rng tester that alas was so 185broken it couldn't read any format I tried anyway), I fixed and updated 186the man page, I got rid of the old overlap variable (no longer 187desireable or necessary, although I have a bit of cruft left behind to 188clean up still). 189 190As a result of the initial ttd test, I am certain that there is a 191problem with diehard_dna, one that causes it to fail aes at 0.000001 in 1921500-4000 samples. This is odd, since this test has an "exactly" 193computed mean and sigma target. I may try threefish in a second to see 194if it fails too, in the same general order. Haven't done the auto-xor 195generator thing yet. 196 197I still have to implement -Y 1 (resolve ambiguity mode) where it will 198force a test to fail or come back up with more samples, but it should be 199straightforward. However, it is almost 2 am and I teach way too early, 200so it is off to bed. 201 202 rgb 203 204 205------------------------------------------------------------------------ 206r497 | rgbatduke | 2009-10-22 09:45:52 -0400 (Thu, 22 Oct 2009) | 20 lines 207 208This is a not-quite-yet-broken checkin of -Xtreme mode changes. Three new 209control variables are in place. They are parsed (untested). They are 210used in std_test to allocate much larger pvalue vectors (Xcutoff in 211size) at test initialization time. I'm JUST READY to hack into the main 212std_test execution loop with case switches or other conditionals and 213implement at least resolve ambiguity and ttd modes. But as usual, I 214have to go in and teach. At the moment, though, DH still builds and 215runs -a correctly, so it seems like a good idea to check in a still 216working snap in case I break everything and want to start over from 217here. 218 219Oh, I also am cleaning up a bit and made the multiply_p variable (-m 220option) a double, so you CAN enter -m 0.1 and run only 10 psamples for a 221fast version of -a(ll). At this point a lot of debugging is just 222ensuring that all the tests run, and it is a PITA to wait 30+ minutes 223for a -a(ll) run to get through. So you now CAN test fewer than the 224default number of psamples in an -all run, even though most people won't 225use the option in actual testing. The usual usage, -m 10 or -m 100, 226works fine still. 227 228------------------------------------------------------------------------ 229r495 | rgbatduke | 2009-10-20 14:25:32 -0400 (Tue, 20 Oct 2009) | 34 lines 230 231I'm checking in a lot of changes down below. -m is implemented and 232documented. -k is implemented and documented. The man page is fixed 233(post good-kstest and aes/threefish). The endian bug went away when I 234refreshed the include files, making me wonder if it wasn't some sort of 235strange GBT stuff and not a real problem -- I left in the endian code in 236configure.ac but don't use it. I re-fixed diehard_runs.c -- it was 237broken post patching but now seems good. I filed some documentation and 238bug reports. I fixed a number of pernicious warnings about needing 239casts (one still remains in threefish, but it is David's and I don't 240know how to fix it). I worked on dieharder.html.in pretty substantially 241to get it to match all of the above. 242 243Next, -x (and maybe -X). 244 245(p.s. -- Welcome David.) 246 247(p.p.s. -- I'm still testing -- sigh, forever -- but it looks like all 248non-deprecated tests are working OK in this snap, and that the -m 249feature works nicely. I documented timings for the k options, and 250basically it comes down the kstest being too slow to do large numbers of 251samples without switching over to the asymptotic form of the test at 252some point. I mean, going from three minute runs to over three hours 253and still counting when I quit for a factor of 10 difference in the 254number of samples, really serious nonlinear gains in the amount of 255work/time required, and this was still -k 1 with Marsaglia's more modest 256speedup, not even the "exact" mode with no speedup at all. 257 258This will quite possibly require some further hacking of the boundaries 259for a crossover that is "practical" and not too inaccurate as we gain 260experience with our own patience, especially as we implement a -x like 261option that just keeps crankin' on the number of samples to hit a 262prespecified tolerance for failure.) 263 264 265------------------------------------------------------------------------ 266r494 | rgbatduke | 2009-10-19 09:46:39 -0400 (Mon, 19 Oct 2009) | 3 lines 267 268This is all of the Bauer patches. Some are tested, but the testing 269continues. 270 271------------------------------------------------------------------------ 272r493 | rgbatduke | 2009-10-18 10:43:52 -0400 (Sun, 18 Oct 2009) | 108 lines 273 274This is checking in what will be 3.29.4beta. 275 276Primary fixes so far: 277 278 Several changes to configure.ac to eliminate all reference to libaes 279and to set macros ENDIAN_BIG or ENDIAN_LITTLE to 1 in the configure 280stage of the build. I plan to insert a very simple prequel in Brian 281Goodman's brg_endian.h header file that handles endian issues cleanly 282and skips most of the stuff below for little endian. I do need to 283ensure that it builds on i386 as well (when I'm done) as I have a report 284that 3beta doesn't build clean on that architecture due to problems in 285this header file. 286 287 A fix due to Glenn Emelko, GEmelko@aclara.com, where I correctly 288bumped filecount to type off_t in libdieharder.h but failed to redefine 289rtot and rptr accordingly in the rng_file_input.c struct and code. He 290was running 18 GB raw files and obviously this overflowed uint variables 291with bad results. Oops, and thanks Glenn. 292 293 I am trying to get sts_serial.h to run at 24 bits by default, not 16 294(I think that this will still take a not unreasonable amount of time). 295The problem is that sts_serial doesn't use bits.c calls to parse out the 296next 24 bits, it just grabs 16 bit, then the next 16 bits, out of 32 bit 297uints. This is fast but not scalable. I have to go in and edit the 298code to use bits calls to get the next 24 bits, no foolin, or better yet 299use -n ntuple to set the maximum number of bits teste (that's my real 300goal, with 24 being the default). 301 302Plans: David Bauer sent me a fairly extensive patch against 3.29.3beta 303that fixes some memory leaks and/or speed issues in bits (?) as well as 304fixing some parts of the diehard OP code -- probably fixing Marsaglia's 305bugs and not mine, but hard to say. There are bugs in there and I've 306already squashed several so it wouldn't surprise me if there are more 307(even more of my own:-). I'm going to TRY to implement most of his 308fixes if they work well and seem to fix something that makes sense to 309me, although I'd feel better (per fix) if I could find a test case that 310illustrates the failure. I may have to ask him how he found the bugs so 311I can document them in svn somewhere, later. Memory leaks of course are 312relatively easy and again, I could easily have created some -- getting 313rid of them is definitely called for. David is also looking at the 314rgb_bitdist tests (which SHOULD be as sensitive as the OP tests if 315cranked up to the correct degree) -- there may be some fixes there 316coming. 317 318Finally, I have a few operational changes in mind -- primarily adding or 319altering the new interface in a couple of small ways. Kuiper will go 320away as an option (but not the code -- I'll leave a macro in place that 321can switch it back on in case there is ever any point in reconsidering 322the test, if for example I or David or somebody else figures out an 323exact CDF for it so it becomes as accurate and perhaps faster than KS, 324or it is needed for a specific rng test in the future. -k flags will be 325used to control how hard ks works (and hence how fast vs accurate 326dieharder is) with a default of pretty fast, pretty accurate and 327alternatives of slow but to-convergence-exact and really fast but only 328accurate enough for the short version of the -a(ll) run. 329 330I'd also like to introduce two new run modes controlled by flags. One 331of them, -m(ultiplier), will allow the user to enter a scale factor to 332be applied to the default 100 -psamples used in -a(ll) runs (otherwise 333ignored). So if one want to run all the tests but with 1000 psamples 334per test (or 10x whatever the per-test default is) one runs -a -m 10. 335This should make it MUCH easier to test to destruction, increase test 336resolution, etc. 337 338Second, I want to introduce a flag that runs a test "to failure" -- 339something I've planned to do for a long time. David has already hacked 340in his own version of doing this, and I used to do something very 341similar in my numerical simulations. The idea of running in -x(treme) 342mode (or whatever I name the flag) would be to start with e.g. 100 343pvalues and then add 100 pvalues at a time to the test run until the 344final pvalue fails a fairly stringent (user selectable) cutoff. 345 346 -d 1 -x 0.000001 347 348would add psamples to the birthdays test until the final pvalue is under 3490.000001. 350 351 -d 1 -X 0.000001 352 353would do the same thing, but it would run the test to this degree of 354failure psamples = 100 times with different rng seeds (if appropriate) 355and return something like max, min, mean number of psamples required to 356cause a test failure. SOMETHING like this is going to be needed, 357because I think it is entirely plausible that some tests have 358"poisonous" seeds that have just the right prime modulus to introduce 359correlations in their stream, but that NEARLY ALWAYS are started with 360seeds that yield good streams. 361 362I'd like to have these last two options work for -a -m runs as well, so 363 364 -a -m 10 -X 0.000001 365 366runs all tests until they fail low or high at one part in a million, 3671000 times for different seeds per run, returning the average number of 368psamples required to reach failure. I'd even like to be able to plot 369the distribution of this number so one can pick out e.g. bimodal 370distributions (bad seeds!) etc. 371 372At some point being able to do everything that dieharder will want/need 373to do is going to require a GUI -- something that can generate scatter 374plots, candlesticks, real non-ascii histograms, line graphs, 2d/3d 375surfaces. But that's still a ways in the future. -X is going to be 376pretty tricky as well, as dieharder isn't equipped to return anything 377but a final cumulative "pvalue" in [0,1] for a test. But it is probably 378better to do it now in the beta phase where this doesn't really damage 379any other future dependent interfaces (e.g R). 380 381 382------------------------------------------------------------------------ 383r492 | rgbatduke | 2009-10-12 18:53:13 -0400 (Mon, 12 Oct 2009) | 8 lines 384 385THis is mostly to check in the dieharder NSF proposal from last year as 386it has a roadmap for future dieharder development, and I'm thinking hard 387about adding a few of the many missing generators now that kstest is 388reliable. I'm still working on kstest, mind you, but it is mostly on 389the details, not on the basic code. 390 391 rgb 392 393------------------------------------------------------------------------ 394r491 | rgbatduke | 2009-10-12 14:55:55 -0400 (Mon, 12 Oct 2009) | 6 lines 395 396This actually works PRECISELY for all count ranges. It is still in 397testing -- I've got a bit of work to do to be ready to release this 398globally (including letting David test it and see if he agrees) but it 399should COMPLETELY FIX dieharders final kstest (and I'll give it one 400last opportunity to fix diehard_sums():-). 401 402------------------------------------------------------------------------ 403r490 | rgbatduke | 2009-10-12 12:39:51 -0400 (Mon, 12 Oct 2009) | 10 lines 404 405Checking in some key papers (and some stuff getting rid of broken 406diehard_sums altogether for now -- leaving in the test but strongly 407deprecating it in dieharder). The papers SHOULD permit us to compute 408the exact CDF for the one-sided KS test against a uniform distribution 409for small N and thereby make the KS test reliable for all sample sizes. 410 411In particular ks_CDF_N.pdf looks like it will do the trick. 412 413 rgb 414 415------------------------------------------------------------------------ 416r489 | rgbatduke | 2009-10-11 11:05:24 -0400 (Sun, 11 Oct 2009) | 32 lines 417 418FINALLY I got threefish to work. brg_endian.h was broken as shit; it 419starts off by pulling something from crypt.h that is obviously broken on 420modern linux boxes (at least my Fedora 11 x86_64 box). The remaining 421code looks quite general and seems to work, although I have to admit I 422absolutely hate crap code like this -- it smacks of aimk, imake, and 423other crap tools that detect platform type using some sort of transient 424trace from one tool or another that breaks three years later (or rather, 425requires yet another conditional). I'll leave this in for now in case 426somebody wants to port to sparc or some bigendian platform, but since we 427are using threefish only to make random numbers and don't care to ever 428decrypt the stream of 0's or whatever it is applied to, I honestly doubt 429that it matters. Getting endianness wrong sounds like it is at worst an 430extra byte shuffle. 431 432Either way, this will be 3.29.2beta and I'll put it up on the dieharder 433website in a few minutes (after a full -a run of threefish passes). I 434may add a comment to brg_endian.h indicating my hack, lest people be 435tempted to use it as if it weren't modified. 436 437Grrr. I'm REALLY tempted to just strip it to the two line definition 438that is all that matters in skein_port.h and screw the whole "automagic" 439thing. Robust code is robust code, and there are bound to be 440intrinsically portable ways to handle endianness IF it is really 441necessary in the first place. 442 443At least this finally liberates me to move on and work on kstest and 444kuiper again. That's been on hold for a few days, but I'm feeling like 445we're getting close to having one or the other work "perfectly" (if I 446can find and add the missing O(1/N) correction terms from the 447literature). 448 449 450------------------------------------------------------------------------ 451r488 | rgbatduke | 2009-10-08 12:50:29 -0400 (Thu, 08 Oct 2009) | 25 lines 452 453This is most of the threefish stuff required, but I'm still having 454trouble with the big/smallendian conversions apparently needed by skein 455in threefish. One function that is supposed to be defined automagically 456is coming out UNdefined in the linker, which is "bad". I may have to 457ask David Bauer how he got this to compile. Note that I've added both 458bauer and emelko's current round of bug reports and remarks to the Bugs 459directory below. David in particular has been really looking hard at 460kstests, and with good justification. The kstest is apparently very 461poorly defined even in stats texts and the literature. It is apparently 462more broken in R than it is in dieharder, and it is still a bit broken 463in dieharder. 464 465As is so often the case in dieharder problems, pushing the test suite to 466new limits exposes weaknesses in code that has long been taken for 467granted because it has never been used for a rigorous analysis of this 468sort. But it NEEDS a precise ks or kuiper test, not just a sorta-useful 469approximate one, or one cannot rely on its statements of weakness or 470failure. 471 472Anyway, this checkin is still broken but is within one #define or so of 473working, I think, once I figure out how to do it without violating the 474code in the brg_endian.h include that is supposed to automagically 475select the right Skein function that is currently undefined. 476 477 478------------------------------------------------------------------------ 479r487 | rgbatduke | 2009-10-07 12:19:44 -0400 (Wed, 07 Oct 2009) | 16 lines 480 481David Bauer contribued two cryptographic grade GSL wrapped rngs (one of 482which I had been working on myself, but his has no dependencies and it 483works already). rng_aes appears to work, very respectably. It has 484minimal controls (compared to aespipe) but aespipe is still there if 485people want to play with it directly. It isn't too shabby speedwise, 486actually, for what should be a world-class rng. I'm going to see if he 487(David) cares if I contribute it back to the GSL -- it needs a few 488generators like this in its collection. Although as it is GPL the 489answer is obviously not, I think. 490 491In a second I'm going to insert rng_3fish as a second one. These are 492enormously useful for testing dieharder itself, and as GPL sources will 493be useful just being part of the dieharder unless/until they make the 494GSL. 495 496 497------------------------------------------------------------------------ 498r486 | rgbatduke | 2009-10-06 14:26:39 -0400 (Tue, 06 Oct 2009) | 3 lines 499 500Little fixes, ignore. Added -d 204 to -all properly, fixed its 501autodocumentation a bit. 502 503------------------------------------------------------------------------ 504r485 | rgbatduke | 2009-10-06 14:17:43 -0400 (Tue, 06 Oct 2009) | 35 lines 505 506This records a validation script to use with aespipe to produce a 507"standard run" of dieharder in -v3. aespipe with the fixed, trivial 508256-bit key in aeskey below, is used to encrypt /dev/zero into a stdin 509stream and fed to dieharder -a. The encrypted stream should be as close 510to "truly random" as we can currently manage with simple, reasonably 511fast tools. The interesting thing is that this stream actually PASSES 512ALL OF THE TESTS in dieharder, even the "known bad" tests such as 513diehard_operm5. This makes it very, very useful for comparison 514purposes. For example, for the first time ever, I feel like I can now 515say that mt19937 actually FAILS dieharder (or has weaknesses that are 516explicitly exposed by dieharder) when it consistently has tests (even 517very specific tests for very specific length ntuples) on which it is 518weak or fails or exhibits high bias in its output pvalues. 519 520To be fair, passing all of the tests isn't necessarily a good thing, 521since there are over 100 of them including ntuples. One expects 1/100 522or 1/200 or thereabouts to be weak for a PERFECT RNG on most runs. 523Eyeballing the distribution of final P in the aespipe run reveals that 524dieharder still produces a weak high bias in the final distribution of 525pvalues, but this is very much in line for the bias revealed by 526rgb_kstest_test and is therefore very likely an artifact of using -p 100 527as the default for most of the tests in -a(ll). 528 529I'm going to run the validation line: 530 531 cat /dev/zero | aespipe -P aeskey | ./dieharder -g 200 -a 532 533with -p 1000 just for grins (which will take the rest of the day, I 534expect) and see if it doesn't push the final distribution right back 535where it belongs, with less visible bias towards the 0.9-1.0 range and 536away from 0.0-0.1 on the bottom. 537 538Still, a perfect PASS for a nearly perfect generator. How cool is that? 539 540 541------------------------------------------------------------------------ 542r484 | rgbatduke | 2009-10-06 12:45:36 -0400 (Tue, 06 Oct 2009) | 40 lines 543 544This is a set of changes that: 545 546 a) Fix (for the time being) a problem with ltmain.sh, badly. I 547suspect that I'll need to add a libtoolize command to the autogen.sh 548script in order to prevent drift from local libtools in the long run, or 549give in and make it a link to /usr/share/libtool/config/ltmain.sh and 550pray that this is portable. 551 552 b) Changes the default ks test in dieharder from broken Kuiper or 553broken KS to fixed KS. This is an CRITICAL fix and needs to backport to 5542.28 as with it dieharder will FINALLY give much more nearly correct 555pvalues for the relatively small number of pvalue samples in the kstest 556at the end of each test. With the old code one needed two or three 557orders of magnitude more samples -- at LEAST -p 10000 -- in order for 558the final pvalue to be not VISIBLY high biased when applied to perfect 559uniform deviates. With the fix -p 100 works "OK" although -p 1000 would 560be better and will probably be the default -a(ll) option in 3.x. 561 562The actual fixes are a single line in dieharder/set_globals.c (change 563the comment name but not the default number of the ks_test global), a 564single line in libdieharder/kstest.c, and switching the order in 565libdieharder/std_test.c so that ks_test == 0 runs kstest, not 566kuiper_kstest. Fixing the documentation is probably not worth it in 5672.28. 568 569I would suggest still holding out on actually making the fixes for a 570bit, as I'm actively playing with things and testing out the new code 571(in a moment with aespipe as I still haven't finished rng_aes). The 572changes are preserved and saved as 3.29.1beta, though, with the addition 573of a very useful and useable rgb_kstest_test routine that can be used to 574further debug and/or improve the kstest used to generate final test 575pronouncements of pass/fail/weak etc. And we still need to decide if it 576is time to move on to v3, as a lot of people are using it and it seems 577to be stable and usable and has lots of bug fixes and feature 578enhancements (including much better future scalability as I add tests 579and generators). 580 581 rgb 582 583 584------------------------------------------------------------------------ 585r483 | rgbatduke | 2009-10-06 09:08:59 -0400 (Tue, 06 Oct 2009) | 7 lines 586 587The new rgb_kstest_test in this version actually works, but it looks 588like we have some sort of libtool derived bug in the build. I'm 589checking in clean so I can rerun libtoolize, which will hopefully get me 590a new ltmain.sh, which will hopefully build a libtools script that 591contains the correct ECHO/echo lines and perhaps deals with MODE 592correctly. 593 594------------------------------------------------------------------------ 595r482 | rgbatduke | 2009-10-04 09:44:12 -0400 (Sun, 04 Oct 2009) | 15 lines 596 597Ignore today's checkins, Dirk. I'm adding a new test (rgb_kstest_test) 598to test the kstest routines (as well as to MAYBE function as a new test 599in the suite, but I doubt that it will be sensitive enough to be any 600use). Basically, I plan to fill a vector with tsamples uniform 601deviates, run a kstest on them (which tests for uniformity and generates 602a pvalue that should itself be a uniform deviate) to fill in the usual 603vector of pvalues and run the final kstest on that. A kstest SHOULD 604recursively take uniform deviates to a uniform deviate, for a large 605enough set of uniform deviates, and I want to find out a) if this is 606true; and b) if it is true just what a "large enough set" is. This test 607should help me find out both, and if a) is incorrect, to perhaps "fix" 608the kstest as this is their THEORETICAL behavior and failure to 609accomplish this indicates a bug in the code or a real problem in the 610theory... 611 612------------------------------------------------------------------------ 613r481 | rgbatduke | 2009-10-02 16:32:30 -0400 (Fri, 02 Oct 2009) | 3 lines 614 615This checks in what might be a VERY IMPORTANT fix to kstest, due to 616David Bauer. Needs more testing, though, with a world class crypt. 617 618------------------------------------------------------------------------ 619r480 | rgbatduke | 2009-03-17 08:27:23 -0400 (Tue, 17 Mar 2009) | 2 lines 620 621Checking in so I can leave. 622 623------------------------------------------------------------------------ 624r479 | rgbatduke | 2009-03-17 00:28:25 -0400 (Tue, 17 Mar 2009) | 3 lines 625 626This is broken as far as the aes generator is concerned, AND I'll 627probably need to put libaes into the dieharder packaging. 628 629------------------------------------------------------------------------ 630r478 | rgbatduke | 2009-01-29 10:57:43 -0500 (Thu, 29 Jan 2009) | 8 lines 631 632Checking in a LOT of changes and additions associated with v3 -- I've 633been holding them so as not to screw up the RDH side of things before 634everything stabilizes. A lot of the stuff below is documentation 635intended to guide future development and additions. Some of it is fixes 636(data and otherwise) in diehard tests. Some of it fixes the way 637dieharder (the binary, not library) initializes (and adds local tests) 638and runs all tests. 639 640------------------------------------------------------------------------ 641r477 | rgbatduke | 2008-10-08 15:11:30 -0400 (Wed, 08 Oct 2008) | 3 lines 642 643Sending in a minor change to START fixing up parsecl.c to be more 644robust. 645 646------------------------------------------------------------------------ 647r476 | rgbatduke | 2008-09-29 22:22:38 -0400 (Mon, 29 Sep 2008) | 26 lines 648 649This checkin should make Mattias "perfectly happy". It enables: 650 651rgb@lilith|B:1140>./dieharder -a -D default -D -1 -D prefix -D 652no_whitespace -D show_num -s 1 6530|rng_name|num|rands/second| 6541|mt19937|13|1.17e+08| 6550|test_name|num|ntup|tsamples|psamples|p-value|Assessment|Seed 6562|diehard_birthdays|0|0|100|100|0.16302070|PASSED|3542794731 6572|diehard_operm5|1|5|1000000|100|0.04115096|PASSED|2304163927 6582|diehard_rank_32x32|2|0|40000|100|0.92631752|PASSED|2245496723 6592|diehard_rank_6x8|3|0|100000|100|0.86585575|PASSED|3223183182 6602|diehard_bitstream|4|0|2097152|100|0.60520232|PASSED|2615297461 6612|diehard_opso|5|0|2097152|100|0.05852624|PASSED|1542897414 662 663which is, AFAICT, exactly what he wants. Oh, he wants the full test 664name as an output field option instead of the short name, but he might 665have to wait on that... 666 667This also checks in a couple of minor bugfixes reported by Mattias and 668Marc Abel. Marc has another feature request I haven't looked at yet. 669Both of them are using dieharder quite heavily in the beta version, so 670I'm hoping that it is shaking out. I'm also hoping this round of 671changes didn't break anything. 672 673Not quite ready for a release, but perhaps getting closer. 674 675------------------------------------------------------------------------ 676r475 | rgbatduke | 2008-09-22 19:10:01 -0400 (Mon, 22 Sep 2008) | 2 lines 677 678Added small section to man page on output control. 679 680------------------------------------------------------------------------ 681r474 | rgbatduke | 2008-09-22 07:24:15 -0400 (Mon, 22 Sep 2008) | 12 lines 682 683Small changes to add dieharder-config.in to the Makefile.am and to 684get the rpm to autobuild with a split between @VERSION@ and 685@DIEHARDER_LT_VERSION@ -- I basically twinned the latter into 686@DIEHARDER_LIB_VERSION@. A slight pain, but it means the library can 687have a different version (no beta) compared to the program (with beta). 688 689The successful RPM build means that everything is in place, although 690there is still cruft in include and probably libdieharder and there may 691be NON-cruft that isn't in the repo. But I gotta go and won't find it 692now. 693 694 695------------------------------------------------------------------------ 696r473 | rgbatduke | 2008-09-22 03:29:33 -0400 (Mon, 22 Sep 2008) | 24 lines 697 698OK, this is PARTIALLY decrufted -- I doubt that it is finished yet, and 699I haven't even started to tackly the proper decrufting of the library. 700I've cleaned up the dieharder man page, checked all the autodocumenting 701features of dieharder, and run a bunch of tests. I've preemptively 702fixed around three or four bugs, and finished implementing a couple of 703features that were missing on the previous checkin, e.g. the ability to 704use any of: 705 706 dieharder -d diehard_sums -g 6 707 dieharder -d 14 -g gfsr4 708 ... 709 710(all tests AND rngs selectable by name OR number. It is 3:20 am, and I 711have to get up by 6:40. It is therefore bedtime. 712 713If I haven't forgotten to checkin any files, it should build and run 714pretty well. Probably not perfectly, but pretty well. Matthias should 715be happy -- if he uses -c ',' and -D prefix, he'll get close to exactly 716what he wants. Everything seems to be working as far as I can tell with 717limited testing. 718 719Might be a day or three before I can really tackle this again. G'night. 720 721 722------------------------------------------------------------------------ 723r472 | rgbatduke | 2008-09-22 00:13:56 -0400 (Mon, 22 Sep 2008) | 92 lines 724 725OK, this is a checkin of dieharder 3.28.0beta. It is NOT fully 726decrufted, but seems to mostly nearly hopefully all work. That probably 727means that there are only a dozen or two bugs. There are also a few 728API features I haven't implemented in the UI yet -- specifically the 729reporting of errors (like a rewind of a file in mid-test). So this 730ISN'T really a beta -- more like an alpha. 731 732Dirk, please do not start converting this over into Rdh yet. I'm 733checking it in for two reasons -- one is that I have to remove a whole 734pile of files to decruft and svn won't let me until I check in. Another 735is that I NEED to checkin -- it makes me nervous to have this large a 736delta not checked in. There are probably a couple of critical sources 737I've forgotten to add entirely and I won't know until I check in and 738check out and build a fresh clean copy. 739 740MOST of what I've done, from Rdh's point of view, should be invisible 741after Rdh is (fairly minimally) hacked one last time. Basically Rdh 742should use its own version of set_globals.c (or patch mine, or ifdef 743mine). Note that there are a lot fewer variables, and this list may 744shrink a bit more. 745 746ntuple's meaning hasn't changed, and you already handle that. 747 748Seed and strategy work together -- the latter is a new variable and 749SHOULDN'T affect Rdh, but just in case, here's what it does. 750 751The default strategy for dieharder is to reseed once when a rng is 752chosen. In the default output view, the seed is written to the rng 753information part of the header. That way if one wishes to reproduce 754a test result, one can enter the seed with -S seed. 755 756However, this is actually a PROBLEM if one runs multiple tests from this 757one seed. If one runs tests out of order, the results will be 758different. This is true for me running all the tests in order via 759dieharder -a if I should ever change test order, and is true for Rdh if 760one runs first one test, then another in different orders, from the same 761single specification of rng and/or Seed. 762 763Also, there may be situations where one wants to run a single test 764multiple times, each time from a newly selected seed to (in essence) 765determine if some seeds are "bad" for a given rng. dieharder doesn't 766yet support that, but I think that in R it would be pretty easy. 767 768Setting strategy to anything nonzero (say, 1) causes dieharder to reseed 769the random number generator at the beginning of any test. If -S seed 770was NOT specified, it just generates a new random seed, so that one 771could run e.g. diehard_birthdays 100 times in a loop and each one would 772reseed anew with a new random seed. If -S seed IS specified, it uses 773the specified seed. If a file is being used for input (not stdin) it 774forces a rewind at the beginning of each test, which is actually not a 775bad thing to do as it conserves rands. (I hope, I haven't yet tested 776this latter feature much yet but it should work.:-). 777 778SO, Rdh will probably just leave strategy = 0 alone and either set the 779global value of Seed for one-time initialization with a fixed seed or 780not, accepting a one-time random seed. But you CAN support strategy if 781you ever think you need to. 782 783(From my point of view its primary purpose is to make the creation of a 784validation run trivial -- if I run 785 786 dieharder -a -S 1 -s 1 787 788I generate a validation table. If I run 789 790 dieharder -a -S 1 -s 1 -D test_name -D pvalues 791 792I generate a very sparse validation table (basically, just test name and 793pvalue). You can throw a -c ' ' in there if you want white space 794separation or -c ',' if you prefer comma separated values, etc. You 795have nearly complete control over dieharder's output at this point, see: 796 797 dieharder -F 798 799for a listing of output control flags. dieharder -l and dieharder -h 800and dieharder -g -1 all work as before, but I've completely flattened 801and rationalized test-space so it works just like rng-space (and I mean 802JUST like it -- very similar setup. 803 804I completely changed (seriously streamlined and cleaned up) the test 805call procedure, so a SINGLE run_test() routine does pretty much all the 806work, a SINGLE output() routine does all of THAT work, and so that all 807the dieharder CLI-specific stuff is done in parsecl(), and then only if 808you enter specific commands, or in dieharder.c (main()). I tried to 809label things that are CLI specific there as well. 810 811If you want to grab a copy of this and build it and play with it, feel 812free. As soon as this checkin is complete, though, I'm going to start 813decrufting and checking to be sure I have all the required modules 814actually in the repo. 815 816 817------------------------------------------------------------------------ 818r453 | rgb | 2008-09-10 07:16:17 -0400 (Wed, 10 Sep 2008) | 14 lines 819 820Dearie me. This checkin actually works, although I still haven't 821implemented the output.c patch needed by Dirk or fixed the missing .h 822file in include/dieharder. Still, I >>HAVE<< turned all the tests into 823type int's (still no returns) and stripped dieharder.h and split off a 824globals.h file that I don't think I'm going to need, actually, although 825it was useful while stripping dieharder.h as a reservoir of codelets 826that I needed to put back. 827 828Anyway, it is entirely possible that Dirk will read these words as I 829ALSO have dieharder.googlecode.com set up with him on it, and while this 830checkin is still local (about to be svnsync'd up, not directly checked 831in) VERY SOON NOW I may try checkout out from the google repo, which 832will of course check BACK into the google repo thereafter. 833 834------------------------------------------------------------------------ 835r452 | rgb | 2008-09-09 18:38:14 -0400 (Tue, 09 Sep 2008) | 4 lines 836 837This checks in a code fragment that reseeds the rng at the beginning of 838each run_whatever segment. This fragment "guarantees" that every test 839run uses a fixed Seed if it is set. 840 841------------------------------------------------------------------------ 842r451 | rgb | 2008-09-08 01:18:25 -0400 (Mon, 08 Sep 2008) | 2 lines 843 844This now works. 2.28.1 indeed I dub thee. 845 846------------------------------------------------------------------------ 847r450 | rgb | 2008-09-07 23:53:50 -0400 (Sun, 07 Sep 2008) | 3 lines 848 849This seems to fix the output of sts_serial so it is consistent. I do 850have a few small bugs to clean up to get a "perfect" display. 851 852------------------------------------------------------------------------ 853r449 | rgb | 2008-09-07 13:58:56 -0400 (Sun, 07 Sep 2008) | 2 lines 854 855So this is 2.28.1, for the moment and sake of argument. 856 857------------------------------------------------------------------------ 858r448 | rgb | 2008-09-07 13:58:00 -0400 (Sun, 07 Sep 2008) | 2 lines 859 860This is ready to get some sort of rev boost. 861 862------------------------------------------------------------------------ 863r447 | rgb | 2008-09-07 10:00:25 -0400 (Sun, 07 Sep 2008) | 6 lines 864 865This adds a "new" test -- the rgb_lagged_sums test, which is the 866user test but wrapped up to run on a whole sequence of values, the 867way I need to make sts_serial run very shortly. It is sufficient 868to CLEARLY SHOW that mt19937 is actually a weak generator -- it 869is "too uniform". 870 871------------------------------------------------------------------------ 872r444 | rgb | 2008-09-06 19:50:52 -0400 (Sat, 06 Sep 2008) | 2 lines 873 874This SHOULD be everything. Table output mode should now work for -a. 875 876------------------------------------------------------------------------ 877r443 | rgb | 2008-09-06 18:43:39 -0400 (Sat, 06 Sep 2008) | 3 lines 878 879This fixes four more tests. I can now run a LOT of the way through -a 880before reverting to the old style output. 881 882------------------------------------------------------------------------ 883r442 | rgb | 2008-09-06 14:37:53 -0400 (Sat, 06 Sep 2008) | 8 lines 884 885This is coming along nicely. I have pretty much everything set up for 886table vs report output and am streamlining the run_whatever routines to 887the point where only a tiny bit of test-specific initiation 888differentiates them. If I could move it into the test itself, I could 889pretty much completely simplify the dieharder CLI code to a single 890generic test shell call plus a SMALL set of specialized calls for e.g. 891benchmarks or non-standard tests that don't return pvalues per se. 892 893------------------------------------------------------------------------ 894r441 | rgb | 2008-09-05 15:08:47 -0400 (Fri, 05 Sep 2008) | 7 lines 895 896This actually now works to display tables. Time to hack hack hack 897and make ALL the tests work with a table. Right now most of them will 898ignore it. I really should combine report and table in "results" and 899put a SINGLE CALL to results in run_whatever.c. Results must then 900"do it all". Also, I think I'm going to run the benchmarker on ALL 901non-filesystem tests to get a timing, IF the table/timing flag is set. 902 903------------------------------------------------------------------------ 904r440 | rgb | 2008-09-05 08:39:13 -0400 (Fri, 05 Sep 2008) | 3 lines 905 906This applies a small patch from Dirk that just cleans up a few issues in 907dieharder.h. 908 909------------------------------------------------------------------------ 910r439 | rgb | 2008-09-05 07:20:58 -0400 (Fri, 05 Sep 2008) | 3 lines 911 912OK, we'll try ONE LAST change -- commenting out the fclose -- before 913sending this to Dirk. 914 915------------------------------------------------------------------------ 916r438 | rgb | 2008-09-05 07:16:01 -0400 (Fri, 05 Sep 2008) | 15 lines 917 918This is a 2.27.14 checkin. I'll shoot it off to Dirk who is waiting on 919it. I noted, however, that my NEW permutations test FAILS (or should 920fail) mt19937! It produces too GOOD a spread of permutations, 921consistently! This is fascinating information. It means that perhaps 922operm5 is NOT broken; maybe getting permutations to work out 923multinomially is the most difficult test one can put an rng to. 924 925Something to look at later. 926 927This checkin should fix dieharder and libdieharder so that one can run 928multiple tests (including invocation of the same test or different rngs) 929from a single dieharder call. This cannot happen in dieharder -- don't 930worry. But it can and will happen in Rdh and in gdieharder, so it is an 931important fix nonetheless. 932 933------------------------------------------------------------------------ 934r437 | rgb | 2008-09-04 17:07:26 -0400 (Thu, 04 Sep 2008) | 20 lines 935 936This actually checks in so that we can pop the snapshot number in just a 937minute -- a major bugfix relative to Rdh. The two problems addressed 938herein are: 939 940 a) In order to be able to run many tests, one after another, on many 941rngs, one after another, I have to be more careful than I have been 942about allocating and freeing test resources on the one hand, rngs (which 943must be freed) on the other hand, and resetting the static bit buffers 944used in bits.c on the third hand. 945 946 b) I also needed to set up startup with a split into two sections, one 947that runs only one time period and one that runs every time a new test 948is created, executed, and destroyed (with everything reset at the end to 949run a new test). 950 951The good thing beyond Rdh in these changes is that several of them are 952equally necessary in a GUI version e.g. gdieharder. So nothing being 953done here is wasted... 954 955 956------------------------------------------------------------------------ 957r436 | rgb | 2008-08-19 12:44:28 -0400 (Tue, 19 Aug 2008) | 4 lines 958 959This really, really should be IT! I dub thee 2.27.12 as I've got to get 960on with things. This version works for BOTH x86_64 and i386. It should 961build into debian packages. It should rpmbuild --rebuild. 962 963------------------------------------------------------------------------ 964r435 | rgb | 2008-08-19 12:34:56 -0400 (Tue, 19 Aug 2008) | 5 lines 965 966This is a nearly final (for now) checkin for 2.27.12. It builds 967decently. I probably need to put back config.sub as it is one of the 968many things that should get automagically rebuilt -- if I have a 969placeholder for it already present. 970 971------------------------------------------------------------------------ 972r434 | rgb | 2008-08-19 12:16:18 -0400 (Tue, 19 Aug 2008) | 4 lines 973 974We'll give this a try -- this defines __auto_build_post at the top of 975the specfile and SEEMS to prevent the check-buildroot crash in rpm 976building without my particular .rpmmacros. 977 978------------------------------------------------------------------------ 979r433 | rgb | 2008-08-19 11:50:28 -0400 (Tue, 19 Aug 2008) | 2 lines 980 981With any luck at all, this will be ready to fly. 982 983------------------------------------------------------------------------ 984r432 | rgb | 2008-08-19 11:42:31 -0400 (Tue, 19 Aug 2008) | 2 lines 985 986We're working our way back to not losing everything we just did, dammit. 987 988------------------------------------------------------------------------ 989r431 | rgb | 2008-08-19 11:34:04 -0400 (Tue, 19 Aug 2008) | 2 lines 990 991Try try again... 992 993------------------------------------------------------------------------ 994r430 | rgb | 2008-08-19 11:31:38 -0400 (Tue, 19 Aug 2008) | 3 lines 995 996Sending this towards lucifer. We really need to make sure everything is 997in subversion! 998 999------------------------------------------------------------------------ 1000r429 | rgb | 2008-08-19 07:40:00 -0400 (Tue, 19 Aug 2008) | 4 lines 1001 1002This MAY fix things up so that they rebuild more cleanly. I'll try 1003sending them on to Dirk directly in tarball form to see if they make him 1004all happy. 1005 1006------------------------------------------------------------------------ 1007r428 | rgb | 2008-08-19 06:43:42 -0400 (Tue, 19 Aug 2008) | 4 lines 1008 1009Well, perhaps we should send this in since we could be suffering from 1010early hard disk crash syndrome. In fact, I should drag out my 8 GB USB 1011flash (at least) and back up Src if nothing else. 1012 1013------------------------------------------------------------------------ 1014r427 | rgb | 2008-08-19 06:22:07 -0400 (Tue, 19 Aug 2008) | 2 lines 1015 1016Moving math down to bugs, as it is really a set of patches. 1017 1018------------------------------------------------------------------------ 1019r426 | rgb | 2008-08-19 06:21:33 -0400 (Tue, 19 Aug 2008) | 14 lines 1020 1021We're rearranging this so I can track bugs a bit better. I've really 1022got only two outstanding ones -- getting aclocal to find libtool on a 1023system I don't control or understand (problem possible solved by 1024rerunning ./autogen.sh on that system) and getting the hard path of 1025missing out of the toplevel Makefile and replacing it with a relative 1026one so that it can be built without rerunning autogen.sh, maybe. Oh, 1027and some sort of rpm build wierdness. 1028 1029Also, Dirk wants me to decruft to where -Wall produces no unused 1030variable complaints. We'll see about that -- MAYBE I'll do it, 1031eventually, but unused variables are really pretty harmless and are 1032sometimes useful and I usually ignore them until I have too much time on 1033my hands. 1034 1035------------------------------------------------------------------------ 1036r425 | rgb | 2008-08-19 06:01:36 -0400 (Tue, 19 Aug 2008) | 4 lines 1037 1038This removes RDieHarder (which Dirk is maintaining separately at this 1039point). It fixes the newly improved man page (which was broken). It 1040removes a redundant R directory. 1041 1042------------------------------------------------------------------------ 1043r424 | rgb | 2008-08-18 18:10:44 -0400 (Mon, 18 Aug 2008) | 3 lines 1044 1045This fixes a few small errors in the 2.27.11 abstract; no changes to the 1046actual program, though. 1047 1048------------------------------------------------------------------------ 1049r423 | rgb | 2008-08-18 16:15:49 -0400 (Mon, 18 Aug 2008) | 19 lines 1050 1051This checks in the ChangeLog itself, as well as the last few 1052minor changes in the tests run with the -a command and the 1053test listing function in the CLI. I think I declare this to be: 1054 1055 2.27.11 1056 1057and we'll start working on 12. I think this actually fixes 1058all the outstanding bugs except for the problem in sums and 1059the problem in operm5 in diehard (and of course there are tests 1060half implemented as well). 1061 1062I THOUGHT I'd fixed diehard_sums, actually, but it still most definitely 1063fails on large -p. I'll have to check sums out explicitly to see why it 1064doesn't seem to work at the moment. It's possible I dropped the fixes 1065when recently changing systems. 1066 1067Anyway, here it is. Bring on the bugs. 1068 1069 1070------------------------------------------------------------------------ 1071r422 | rgb | 2008-08-18 15:50:15 -0400 (Mon, 18 Aug 2008) | 21 lines 1072 1073This might be ready for a production snapshot, or a testing snapshot, 1074or something like that. At any rate, I have BOTH fixed the generator 1075problem (where rngs have numbers that can change as new generators 1076are added. I fixed this by significantly increasing the size of the 1077types[] vector and working moderately hard to pack it with generators 1078sparsely and sanely -- sparse so there is plenty of room, sane because 1079the space is now blocked out by general category with room to grown. 1080 1081This will NOT GUARANTEE that the GSL will not change its internal order, 1082and dieharder will continue to follow the GSL order where they overlap 1083as nothing else makes sense. 1084 1085I >>also<< think I've fixed -r 5, rgb_permutations. This is a 1086non-overlapping permutations test and runs to more or less arbitrary 1087order (and seems to work quite nicely where it runs, although it gets 1088quite slow when we get to very large permutations as one might expect). 1089 1090I think it is time to bump the minor-minor number to 11 and post it, for 1091the time being with -r 5 still marked out as experimental in the 1092help listing. 1093 1094------------------------------------------------------------------------ 1095r421 | rgb | 2008-08-18 14:33:06 -0400 (Mon, 18 Aug 2008) | 5 lines 1096 1097This fixes the only real bug, I think -- dieharder now dies with a 1098complaint if it is invoked with an invalid -g entry, sort of. Hmmm, 1099actually I might need to tweak this fix just a bit more to check 1100on the complete range. 1101 1102------------------------------------------------------------------------ 1103r420 | rgb | 2008-08-18 14:29:17 -0400 (Mon, 18 Aug 2008) | 3 lines 1104 1105This actually works and has the number spaces previously discussed 1106all implemented and everything. 1107 1108------------------------------------------------------------------------ 1109r419 | rgb | 2008-08-17 20:15:08 -0400 (Sun, 17 Aug 2008) | 6 lines 1110 1111This is a step in the process of figuring out how to "fix" the numbers 1112for rngs to test. I think I'm going to have to move my own setup 1113routine to libdieharder. But I'm still trying to figure out whether or 1114not I can or should replace the gsl code itself, or run something in 1115parallel. 1116 1117------------------------------------------------------------------------ 1118r417 | rgb | 2008-08-17 13:30:41 -0400 (Sun, 17 Aug 2008) | 3 lines 1119 1120This rearranges the Bugs stuff. I need to create a "cleared" directory 1121in Bugs so I can see what is done, as well. 1122 1123------------------------------------------------------------------------ 1124r416 | rgb | 2008-08-17 12:31:18 -0400 (Sun, 17 Aug 2008) | 5 lines 1125 1126This updates the abstract, which is also important documentation and has 1127been added to the %doc lines in the specfile. I should really create a 1128make installdoc target in Makefile.am that can install a bunch of 1129documents, but that is for another day. 1130 1131------------------------------------------------------------------------ 1132r415 | rgb | 2008-08-15 19:03:26 -0400 (Fri, 15 Aug 2008) | 4 lines 1133 1134This is 2.27.10-1, and adds stdin support and fixes a few bugs in the 1135specfile. I'm posting it for distribution, although it is still not 1136"finished" -- this is very much development snapshot time. 1137 1138------------------------------------------------------------------------ 1139r414 | rgb | 2008-08-15 14:14:45 -0400 (Fri, 15 Aug 2008) | 4 lines 1140 1141This adds the capability to input a binary stream into stdin. This 1142patch is due to Paul Serice. He also included a (standalone?) rng to 1143test with, which I'll mess with in a moment. 1144 1145------------------------------------------------------------------------ 1146r413 | rgb | 2008-08-03 08:40:35 -0400 (Sun, 03 Aug 2008) | 3 lines 1147 1148Added a version string to help. Probably should add one elsewhere, e.g. 1149at the top of rng listing and test listing. 1150 1151------------------------------------------------------------------------ 1152r412 | rgb | 2008-08-01 09:11:10 -0400 (Fri, 01 Aug 2008) | 7 lines 1153 1154Had to back off the svn2cl in the rpm build -- it now has to be run BY 1155HAND before just MY rpmbuild (dummy me) so that it won't fail for end 1156users without svn2cl and an svn repo to match. It still builds 1157perfectly, and I'll do a full rpm build cycle including this step to get 1158this last comment into the changelog. 1159 1160 1161------------------------------------------------------------------------ 1162r411 | rgb | 2008-07-29 12:01:51 -0400 (Tue, 29 Jul 2008) | 46 lines 1163 1164...And it is. So henceforth ALL of my svn checkins will be duly noted 1165in the ChangeLog, which will therefore get to be very long indeed, as I 1166check in a lot. 1167 1168Damn! I guess this means no more swearing, and I sure hope I haven't 1169impugned anyone's character in the first 400 plus checkins. At least 1170not too much. Hmmm, I wonder just what I HAVE said down there. I tend 1171to treat SVN logs as sort of a free-association commentary about the 1172project in addition to being a place to document changes. Some changes 1173have "real" documentation in the form of the svn diffs, as well -- I 1174haven't been too specific about just EXACTLY what I've changed every 1175time. 1176 1177Well, better a ChangeLog up to date and verbose than one months to years 1178old, and I'll be hogtied and hung by the nose before I write a precisely 1179formatted description of changes day to day as I work on this -- twice. 1180So SVN it is (dating back to when it was really CVS, BTW, imported to 1181SVN). 1182 1183Next, I suppose we should provide at least >>a<< fix for the problem of 1184shifting generator numbers, and on my own I want to clean up some 1185issues with file read -- arrange it so we can read in very large files 1186and eliminate/document file-based usage redundancies such as needing -g 118765 AND -f filename. This will be a bit tricky, as dieharder can read in 1188raw (binary) as well as ascii in many formats, and using the -g flag to 1189differentiate at least raw vs cooked has been an easy solution. 1190 1191Regarding numbers, it has been suggested that we do two things: 1192 1193a) Take action to ensure that the numbers don't change any more, even if 1194the gsl or I or a user add new generators. This is actually a bit of a 1195PITA (much as I see the motivation for doing so, as moving numbers break 1196user scripts) because the way generators are added is to run through all 1197the supported ones of each type and just add them in gsl or call order. 1198However, there are several ways I can do it (some requiring more 1199programming than others) and I'll see which one looks to be easiest and 1200most robust. 1201 1202b) Arrange it so we can call generators by name, not just by number. 1203Names would presumably not change even if numbers were inserted, and 1204many users will be interested in testing a single generator they are 1205thinking of using by name. 1206 1207rgb 1208 1209 1210------------------------------------------------------------------------ 1211r410 | rgb | 2008-07-29 11:40:30 -0400 (Tue, 29 Jul 2008) | 5 lines 1212 1213OK, this seems to work, autobuilding ChangeLog from the svn log of my 1214timestamp file, that basically picks up a message like this one every 1215time I do an svn checkin. We'll see in a moment if this is reflected in 1216ChangeLog on the next build. 1217 1218------------------------------------------------------------------------ 1219r409 | rgb | 2008-07-29 11:26:48 -0400 (Tue, 29 Jul 2008) | 2 lines 1220 1221Just testing... 1222 1223------------------------------------------------------------------------ 1224r407 | rgb | 2008-07-22 09:06:14 -0400 (Tue, 22 Jul 2008) | 5 lines 1225 1226This is, in fact, a major checkin. A serious won't-build-on-lib64 bug 1227was identified and resolved, the resolution being the addition of 1228--libdir=... to the ./configure line in the toplevel specfile. 1229Truthfully, I should probably add this to autogen.sh. 1230 1231------------------------------------------------------------------------ 1232r406 | rgb | 2008-03-27 12:33:04 -0400 (Thu, 27 Mar 2008) | 8 lines 1233 1234This is getting close to a release snapshot once again. We do need to 1235set the number of tests correctly. I may have to give up on operm5 or 1236rgb_operm for the time being (again) but at least I have 1237rgb_permutations and rgb_bitdist, both of which test similar things 1238along with sts_serial ditto. I do need to try to fix sums. I'd love to 1239add a couple of the contributed tests. I do need to go through the 1240opso, dna, etc. tests and "fix" them wrt overlap and so on. 1241 1242------------------------------------------------------------------------ 1243r405 | rgb | 2008-03-26 21:20:57 -0400 (Wed, 26 Mar 2008) | 4 lines 1244 1245This APPEARS to be a functional permutations test, as expected/hoped. 1246It uses NON-overlapping samples, although at a guess it would work 1247for overlapping ones, just not as well. 1248 1249------------------------------------------------------------------------ 1250r404 | rgb | 2008-03-26 17:09:43 -0400 (Wed, 26 Mar 2008) | 4 lines 1251 1252This is one, last, poor attempt to get SOME sort of functioning 1253permutations test. I actually had this working "inside" rgb_operm() 1254so I imagine I will have it working again here shortly. 1255 1256------------------------------------------------------------------------ 1257r403 | rgb | 2008-03-26 13:39:14 -0400 (Wed, 26 Mar 2008) | 6 lines 1258 1259This appears to be "fixed" so that bitstream runs without complaint. I 1260will need to check for memory leaks in the long run (heh heh). This 1261once again takes me to where "everything works" but sums operm5, I 1262think. I'll do another standard S 1 run in a second to make a new 1263snapshot with a fixed/reference bitstring. 1264 1265------------------------------------------------------------------------ 1266r402 | rgb | 2008-03-24 15:39:49 -0400 (Mon, 24 Mar 2008) | 6 lines 1267 1268This fixes up all the tests that seem to require chisq with explicit 1269cutoffs (frequently one that will be ignored). Cutoff does matter 1270in the rgb_bitdist test, though! I think all of these tests are at last 1271valid through -p 100 and possibly -p 1000, except for sums, bitstream 1272(which I'll fix shortly) and the perennial operm5. 1273 1274------------------------------------------------------------------------ 1275r401 | rgb | 2008-03-24 00:18:51 -0400 (Mon, 24 Mar 2008) | 4 lines 1276 1277I am HOPING that this is all good, finally. It runs and gives very 1278reasonable answers (once) at -p 1000. Now to see if this is 1279semiconsistent. I've fixed a few zillion small bugs... 1280 1281------------------------------------------------------------------------ 1282r400 | rgb | 2008-03-22 18:33:47 -0400 (Sat, 22 Mar 2008) | 6 lines 1283 1284This repairs one serious bug -- I was misinitializing itail -- and makes 1285it a bit more precise as far as counting dofs. 1286 1287 1288 1289 1290------------------------------------------------------------------------ 1291r399 | rgb | 2008-03-22 15:54:02 -0400 (Sat, 22 Mar 2008) | 6 lines 1292 1293This MAY at long last, actually fix rgb_bitdist by simultaneously fixing 1294vtests in general. Our chisq now AUTOMATICALLY bundles the tail(s) or 1295low spots in a chisq, independent of where they occur. It looks like I 1296failed to set ndof correctly, so there will be another round of tests 1297and a quick checkin in a moment. 1298 1299------------------------------------------------------------------------ 1300r398 | rgb | 2008-03-19 02:23:40 -0400 (Wed, 19 Mar 2008) | 13 lines 1301 1302THIS IS A WORKING STS SERIAL as far as I can tell. It correctly reveals 1303known weak generators. It seems to pass known "decent" generators. It 1304is very sensitive to certain kinds of failure. 1305 1306I now should redo rgb_bitdist to be the NON-overlapping version of this 1307test, at the very least comparing the freq output (generated with the 1308same code, I think, ported the other way) to a multinomial chisq on the 1309expected values. If I can actually check the distribution of each 1310number against an asymptotically normal curve, that would be great too. 1311If I could IN THE SAME TEST check the asymptotic fraction -- something 1312like the monkey tests do -- that would be just fabulous! Especially if 1313I use a normal and make the comparison very good and not empirical. 1314 1315------------------------------------------------------------------------ 1316r397 | rgb | 2008-03-18 20:45:03 -0400 (Tue, 18 Mar 2008) | 4 lines 1317 1318This is very, very close to working perfectly WITH LABELS for 1319all the histograms generated by sts_serial. We'll save it just because 1320it looks really useful. 1321 1322------------------------------------------------------------------------ 1323r396 | rgb | 2008-03-18 17:13:51 -0400 (Tue, 18 Mar 2008) | 9 lines 1324 1325As far as I can tell, sts_serial now works perfectly. Time to clean up 1326its act. I will start by decrufting some of the superfluous output from 1327the library call, then I'm going to FIX the test struct so that each 1328test has its OWN descriptor line that can be set along with its pvalue 1329and that will be used by the histogram and/or single line output routine 1330to identify the associated statistic. I have to make it a bit easier 1331to make a single test call and get back the MATRIX of p-values for a set 1332of statistics all generated with the single call. 1333 1334------------------------------------------------------------------------ 1335r395 | rgb | 2008-03-17 00:58:13 -0400 (Mon, 17 Mar 2008) | 4 lines 1336 1337This, finally, appears to work perfectly. The last thing I need to do 1338is to put all of the pvalues somewhere to be passed back to the caller, 1339in order. 1340 1341------------------------------------------------------------------------ 1342r394 | rgb | 2008-03-16 21:44:35 -0400 (Sun, 16 Mar 2008) | 3 lines 1343 1344This fixes a build problem on x86_64 -- must not have an explicit 1345-L/usr/lib on x86_64 systems, empirically. 1346 1347------------------------------------------------------------------------ 1348r393 | rgb | 2008-03-16 20:55:43 -0400 (Sun, 16 Mar 2008) | 8 lines 1349 1350This is much closer. Fixed a few small bugs, and one fairly large one 1351from the transition to a loop. This is "probably" right at this point. 1352The interesting question is whether and how we can generate statistics, 1353pvalues, and results for the whole vector of results. In principle we 1354can, but I don't know that I've done 14 in a row. OR, maybe I'll figure 1355out that all I need to do is m = 16 (as it includes all its smaller 1356cousins, supposedly). 1357 1358------------------------------------------------------------------------ 1359r392 | rgb | 2008-03-16 15:40:29 -0400 (Sun, 16 Mar 2008) | 3 lines 1360 1361This isn't really done, but we're going to check it in since it sort of 1362mostly works. 1363 1364------------------------------------------------------------------------ 1365r391 | rgb | 2008-03-12 17:47:53 -0400 (Wed, 12 Mar 2008) | 2 lines 1366 1367Let's see if this revision works... 1368 1369------------------------------------------------------------------------ 1370r388 | rgb | 2008-03-12 13:34:59 -0400 (Wed, 12 Mar 2008) | 5 lines 1371 1372Sending it ALL in to Duke and upstairs. There is a bug 1373of sorts in our chisq -- we don't have a good way of 1374specifying the number of degrees of freedom for some 1375of the tests and we need to. 1376 1377------------------------------------------------------------------------ 1378r385 | rgb | 2008-03-12 07:09:20 -0400 (Wed, 12 Mar 2008) | 3 lines 1379 1380This is about as fixed as I can make it without doing algebra. Algebra 1381later, fix code up now. 1382 1383------------------------------------------------------------------------ 1384r384 | rgb | 2008-03-11 19:26:01 -0400 (Tue, 11 Mar 2008) | 7 lines 1385 1386This APPEARS to check with John E. Davis's patches. diehard_dna is no 1387problem -- the drop-in replacement there produces identical numbers, 1388runs in half the time. rgb_bitdist gives DIFFERENT numbers but is MUCH 1389faster. I still have several "small bugs" to check out including bugs 1390in specific tests, and I probably will need to test the static routines 1391as well. 1392 1393------------------------------------------------------------------------ 1394r383 | rgb | 2008-03-11 15:49:34 -0400 (Tue, 11 Mar 2008) | 5 lines 1395 1396Preparing to do the next round(s) of patches. I suppose we'll start 1397with the get_bit_whatever patches. First I need to generate a "before" 1398for at least one test that uses them, e.g. birthdays. Then we'll 1399compare it to after with the fixed seed of 1. 1400 1401------------------------------------------------------------------------ 1402r382 | rgb | 2008-03-11 00:53:27 -0400 (Tue, 11 Mar 2008) | 3 lines 1403 1404This is beefing up the tarball so it just works with the usual 1405preexisting configure. 1406 1407------------------------------------------------------------------------ 1408r381 | rgb | 2008-03-11 00:25:48 -0400 (Tue, 11 Mar 2008) | 5 lines 1409 1410RIGHT THIS INSTANT we finally have a clean F8 build with the new 1411Makefile.am's and a hacked specfile. Alas, to fix the rpath problem 1412I had to resort to using chrpath, which sucks big time. Unless there 1413is a libtool directive for fixing it, though, I'm SOL. 1414 1415------------------------------------------------------------------------ 1416r380 | rgb | 2008-03-10 09:41:26 -0400 (Mon, 10 Mar 2008) | 5 lines 1417 1418I don't know -- I think that we're getting closer and closer. We will 1419have the code completely and cleanly GBT based by the end of the 1420morning, I think. Well, maybe not since I'm going in to see if there 1421is anything entrepreneurial going on with Thom LaBean. 1422 1423------------------------------------------------------------------------ 1424r379 | rgb | 2008-03-10 08:08:18 -0400 (Mon, 10 Mar 2008) | 7 lines 1425 1426OK, this is pretty much all the patches, I think. We should be very 1427close to BSD-ready. I wonder if I can add the word "beta" to the 1428"release" or the "8" in VERSION? 1429 1430Oh, one other thing -- I very definitely need to fix the rpm build 1431(specfile). Let's install into /tmp and see what we've got. 1432 1433------------------------------------------------------------------------ 1434r378 | rgb | 2008-03-10 07:54:46 -0400 (Mon, 10 Mar 2008) | 6 lines 1435 1436Decrufted the makefiles, added a /dev/arandom rng for BSD, fixed tiny 1437modulus bug in rng list display, added sensible error message extensions 1438for people running across distros for the /dev/?random devices (I 1439"could", of course, use fstat to determine if the devices are there and 1440refuse to add them if they aren't, but that's for the future). 1441 1442------------------------------------------------------------------------ 1443r377 | rgb | 2008-03-09 22:07:15 -0400 (Sun, 09 Mar 2008) | 4 lines 1444 1445Checking in a mildly broken set. FWIW, a full build actually works. 1446OTOH, make rpm does not. Perhaps not too unsurprising. I need to do 1447a full install into /tmp and see what comes up. 1448 1449------------------------------------------------------------------------ 1450r376 | rgb | 2008-03-09 15:35:38 -0400 (Sun, 09 Mar 2008) | 4 lines 1451 1452This actually is getting close to being done "the right way". It still 1453builds, and I think builds an RPM, but I need to work on the library 1454side to clean it up as well. 1455 1456------------------------------------------------------------------------ 1457r375 | rgb | 2008-03-09 14:57:03 -0400 (Sun, 09 Mar 2008) | 2 lines 1458 1459OK, this is really close to being what freebsd wants. 1460 1461------------------------------------------------------------------------ 1462r374 | rgb | 2008-03-09 13:55:12 -0400 (Sun, 09 Mar 2008) | 5 lines 1463 1464OK, looks like the BSD patch for rngs_gnu_r.c works, and I'm guessing 1465that it will work in general UNLESS it has to be the gnu error() 1466program to interface with R, in which case the patch will have to be 1467ifdef'd. 1468 1469------------------------------------------------------------------------ 1470r373 | rgb | 2008-03-09 13:38:06 -0400 (Sun, 09 Mar 2008) | 6 lines 1471 1472OK, we are in the middle of a Major Patch Job. We're fixing various 1473small things that are wrong with our GBT port, trying to get it so that 1474it will automagically build on a wider set of systems. The stuff I've 1475done so far still builds (I need to test the rpm build though) and 1476"should" build on gentoo as well as Debian and Fedora/RH. 1477 1478------------------------------------------------------------------------ 1479r372 | rgb | 2008-02-12 19:01:04 -0500 (Tue, 12 Feb 2008) | 9 lines 1480 1481This fixes the Crispin bug, -- a bad number in one column of s[i][j] 1482relative to the original diehard. Sure hope it is the correct one; the 1483later (c version) diehard matched what I had. 1484 1485I really need to compute the r and s directly. But then, I think I 1486understand the operm5 test well enough to do it "directly" without 1487overlap as a non-overlapping permutations test. It might even be fun to 1488make overlap just an option. 1489 1490------------------------------------------------------------------------ 1491r366 | rgb | 2008-01-30 07:47:48 -0500 (Wed, 30 Jan 2008) | 2 lines 1492 1493This fixes the abstract AGAIN... 1494 1495------------------------------------------------------------------------ 1496r365 | rgb | 2008-01-02 11:23:16 -0500 (Wed, 02 Jan 2008) | 4 lines 1497 1498This should be the absolute minimum needed to build clean from tarball 1499using "just" ./configure followed by make. Need to fix the configure 1500script to check for the gsl and anything else that might be needed. 1501 1502------------------------------------------------------------------------ 1503r362 | rgb | 2007-12-07 12:40:35 -0500 (Fri, 07 Dec 2007) | 2 lines 1504 1505This checkin just updates the release number. 1506 1507------------------------------------------------------------------------ 1508r361 | rgb | 2007-12-06 14:39:53 -0500 (Thu, 06 Dec 2007) | 7 lines 1509 1510This patches two small things -- adds fflush(stdout); so tees of the 1511results don't make you wait. Removes a development line from 1512diehard_operm5 that shouldn't be there in any KIND of real release. 1513 1514Need to bump the snap revision and reinstall. 1515 1516 1517------------------------------------------------------------------------ 1518r360 | rgb | 2007-11-19 07:38:36 -0500 (Mon, 19 Nov 2007) | 29 lines 1519 1520This is pretty much a fully functional version. I fixed the last bug, 1521which turned out to be that I had the right idea but missed the: 1522 1523 I + P + P* + P^2 + P*^2 + ... 1524 1525and was accidentally doing (when I empirically noted that including k=0 1526in the sum was necessary) either: 1527 1528 I + P + P^2... 1529 1530or 1531 1532 2I + P + P* + ... 1533 1534Added a conditional to eliminate the second k = 0 instance in the core 1535loop summing the fi*fj and got perfect correspondance through -n 3. The 1536-n 3 matrix is different, but pretty obviously a permutation of the 1537AKM matrix as to be expected since the permutation order is arbitrary 1538and they probably didn't use lexical ordering. The eigenvalues, 1539however, are dead on the same! 1540 1541So I'm back up to the point where I should be able to form a test 1542statistic somehow. I have to covariance matrix precisely in hand -- 1543something at this point about weak inverses (weak because it is singular 1544and has no inverse?). A bit curious, actually. We'll see. 1545 1546 rgb 1547 1548 1549------------------------------------------------------------------------ 1550r359 | rgb | 2007-11-19 01:02:46 -0500 (Mon, 19 Nov 2007) | 13 lines 1551 1552OK, this SEEMS to repair everything, except for some spurious 1553normalization stuff that is at least consistent between the exact 1554and experimental matrices. They now come out the same, and I suspect 1555they are proportional to the nilpotent markov processes paper result. 1556For k=2 they clearly are -- a factor of 2. For k=3 it is harder to see 1557for sure. Time to go back to the paper with a calculator. 1558 1559At least now the matrices are properly symmetric, as well. That means 1560that their eigenvalues can be computed with my existing code with its 1561symmetric matrix eigenvalue calls. It does leave me with the 1562substantial problem of computing a test statistic automagically, but one 1563small step at a time... 1564 1565------------------------------------------------------------------------ 1566r358 | rgb | 2007-11-14 07:01:57 -0500 (Wed, 14 Nov 2007) | 7 lines 1567 1568This works, but my assumptions concerning the inverse of C are incorrect 1569because (gasp) C isn't invertible. It has eigenvalues and eigenvectors. 1570I can compute them, apparently -- that's what this snapshot does (I'm 1571going to compare the results now to what's in my nilpotent processes 1572paper). I still don't quite see how to make my results into a p-value, 1573though, and may need help with this... 1574 1575------------------------------------------------------------------------ 1576r357 | rgb | 2007-11-13 11:53:48 -0500 (Tue, 13 Nov 2007) | 7 lines 1577 1578It is SO key to preserve this in precisely this state. At this instant 1579in time, cexact and cexpt are identically formed, one running over all 1580permutations and the other from sampling, and they work perfectly EXECPT 1581for the #!)#%@ sign error. I had the sign right, and don't quite see 1582how I changed the code, so I'm about to look. In the meantime, though, 1583we mustn't lose this working form... 1584 1585------------------------------------------------------------------------ 1586r356 | rgb | 2007-10-31 22:11:57 -0400 (Wed, 31 Oct 2007) | 3 lines 1587 1588This is a broken checkin, but I'm on track for getting operm finished at 1589last, if only I stick to it. 1590 1591------------------------------------------------------------------------ 1592r354 | rgb | 2007-10-24 15:19:05 -0400 (Wed, 24 Oct 2007) | 2 lines 1593 1594Need to send to duke, dummy.s 1595 1596------------------------------------------------------------------------ 1597r353 | rgb | 2007-10-24 15:18:41 -0400 (Wed, 24 Oct 2007) | 2 lines 1598 1599This is needed for development, I think. 1600 1601------------------------------------------------------------------------ 1602r352 | rgb | 2007-10-24 15:17:37 -0400 (Wed, 24 Oct 2007) | 2 lines 1603 1604Trying again. Dunno how this got screwed up but it is. 1605 1606------------------------------------------------------------------------ 1607r351 | rgb | 2007-10-03 16:16:38 -0400 (Wed, 03 Oct 2007) | 3 lines 1608 1609This is actually a pretty solid implementation of 1610rgb_minimum_distance... 1611 1612------------------------------------------------------------------------ 1613r350 | rgb | 2007-09-29 17:43:55 -0400 (Sat, 29 Sep 2007) | 3 lines 1614 1615works perfectly. fixed memory leak. about to improve 2dsphere with 1616sort, then run -a. 1617 1618------------------------------------------------------------------------ 1619r349 | rgb | 2007-09-29 11:24:16 -0400 (Sat, 29 Sep 2007) | 2 lines 1620 1621This is IT and works... rgb_minimum_distance is there. 1622 1623------------------------------------------------------------------------ 1624r347 | rgb | 2007-09-20 05:37:04 -0400 (Thu, 20 Sep 2007) | 3 lines 1625 1626I need to fix this, but probably not today. In doc there is a "fix me" 1627recipe for 2d spheres. I'm currently adding the Linux Magazine invoice. 1628 1629------------------------------------------------------------------------ 1630r346 | rgb | 2007-09-19 14:44:10 -0400 (Wed, 19 Sep 2007) | 3 lines 1631 1632Checking in a fix for the BROKEN 2d spheres test. I should be able to 1633fix 3dspheres as well from it. 1634 1635------------------------------------------------------------------------ 1636r345 | rgb | 2007-08-28 12:54:51 -0400 (Tue, 28 Aug 2007) | 3 lines 1637 1638Bug reported by a user, sort of. The README still said you could just 1639type "make" and you can't. Fixed. 1640 1641------------------------------------------------------------------------ 1642r344 | rgb | 2007-08-13 18:30:55 -0400 (Mon, 13 Aug 2007) | 2 lines 1643 1644Will this go in? Time will tell... 1645 1646------------------------------------------------------------------------ 1647r343 | rgb | 2007-07-16 11:20:54 -0400 (Mon, 16 Jul 2007) | 45 lines 1648 1649We are working HARD or confirming or denying dieharder_operm5 AND 1650working out a more general rgb_operm. The convertoperm.pl script 1651once AGAIN confirms that I'm unpacking and repacking (for C) the 1652r and s matrices of diehard_operm correctly. 1653 1654However, AFAICT, the diehard_operm5 JUST tallies up t[120], the count of 1655the different permutation indices. However, all the permutations should 1656occur with a SYMMETRIC probability -- I verified this directly by doing 1657the actual integrals, but in retrospect it is pretty obvious from 1658symmetry alone. The t-vector therefore has NOTHING TO DO with the 1659covariance matrix no matter what you do with it, which may be why 1660diehard_operm5() is a bad test. FWIW, I've added output statements to 1661diehard_operm5() that dump the t-vector and verified empirically that 1662yes, it produces a more or less uniform distribution of bin-probability 16631/120 -- one could in fact do a chisq test on this directly and very 1664likely obtain an actual meaningful test, but that is not at all what is 1665done. 1666 1667Note well that the sampled distribution of t[] will not SIGNIFICANTLY 1668vary if computed from overlapping samples! This is simple to see -- it 1669would be just like computing five distinct samplings of non-overlapping 1670samples, each of which would be expected to have exactly the same mean 1671and variance. Because of the overlap there could be a tiny bit of 1672correlation between the FLUCTUATIONS in the MEASURED mean values for any 1673given bin, but the bin mean would have to be unchanged for each 1674overlapping sampling, and for that matter the bin variance for each 1675sampling would ALSO have to be the same. 1676 1677The only effect of combining the overlapping five samplings (each with 1678identical mean and variance!) would therefore be to AT MOST alter the 1679sampled VARIANCE of the bin distribution, per bin, a tiny bit from what 1680one might expect analytically from truly iid samples. One certainly 1681isn't going to see this variation in the variance from two runs -- the 1682expected statistical noise would overwhelm the signal as this is a 1683second moment/cumulant effect, a susceptibility if you like, and hence 1684VERY difficult to resolve. 1685 1686What we in fact must do is (I'm pretty sure) compute c[][] analytically, 1687(which I have done) and then simulate the SAME c[][] directly from the 1688data. Then difference them, which should make the components of 1689c_exp[][] - c_exact[][] presented as vector a zero mean chisq 1690distributed object with N! - (N-1)! DoF or something like that -- 120-24 1691= 96 for N = 5? Here I'll defer to experts, eventually. 1692 1693 1694------------------------------------------------------------------------ 1695r342 | rgb | 2007-06-16 01:11:57 -0400 (Sat, 16 Jun 2007) | 2 lines 1696 1697Hopefully this has all the files needed for rgb_operm() checked in. 1698 1699------------------------------------------------------------------------ 1700r341 | rgb | 2007-06-16 01:09:13 -0400 (Sat, 16 Jun 2007) | 2 lines 1701 1702This actually builds. Let's see if the new test shows up... 1703 1704------------------------------------------------------------------------ 1705r340 | rgb | 2007-06-15 20:12:58 -0400 (Fri, 15 Jun 2007) | 23 lines 1706 1707Checking in several things. rgb_operm.c is a template for my eventual 1708replacement for operm5. I have about concluded that operm5 is basically 1709a joke -- it is conceptually incorrect. The correct statistic should be 1710the overlapping permutations covariance matrix itself. This test just 1711counts the occurrence of permutations -- the "overlap" part is 1712completely irrelevant in this context. It returns an aggregate count 1713vector whose mean is 1/120 (obviously, permutations of 5 objects = 5! = 1714120). It makes NO DIFFERENCE AT ALL if this vector is evaluated from 1715overlapping samples or from independent samples -- the mean will be the 1716same. All that MIGHT change is the variance -- since the samples are 1717drawn from an overlapping population, one would expect that their 1718variance would be strictly less than one would expect from truly 1719independent samples. 1720 1721In a minute I'll verify this with the overlap flag and a couple of runs 1722with mt, but I now understand why the test fails. It remains to figure 1723out how to build a CORRECT overlapping permutations test that uses the 1724COVARIANCE of overlapping samples as a statistic. I actually think that 1725this will be pretty easy, but I do have to also understand why the 1726definition in the nilpotent markov chains paper doesn't (I think) lead 1727to the numbers that they publish there. Or rather, why my MUCH SIMPLER 1728algorithm doesn't lead to the same numbers they get. 1729 1730------------------------------------------------------------------------ 1731r333 | rgb | 2007-06-14 14:54:23 -0400 (Thu, 14 Jun 2007) | 2 lines 1732 1733This should have no operm in it. 1734 1735------------------------------------------------------------------------ 1736r332 | rgb | 2007-06-14 14:36:51 -0400 (Thu, 14 Jun 2007) | 2 lines 1737 1738Probably a good time to update to lucifer, since it is actually up... 1739 1740------------------------------------------------------------------------ 1741r331 | rgb | 2007-06-08 10:14:04 -0400 (Fri, 08 Jun 2007) | 3 lines 1742 1743OK, NOW let's actually try to get rng_uvag in, THEN we'll try to 1744increase its speed... 1745 1746------------------------------------------------------------------------ 1747r330 | rgb | 2007-05-24 13:35:50 -0400 (Thu, 24 May 2007) | 4 lines 1748 1749I'm gradually refining the bitstream variance -- 290 is from over 1750260000 samples. I'm shooting for a s.d. of a couple of tenths, although 1751honestly it is overkill. 1752 1753------------------------------------------------------------------------ 1754r329 | rgb | 2007-05-23 01:02:21 -0400 (Wed, 23 May 2007) | 12 lines 1755 1756OK, this is a major enough checkin. I have at long last fixed 1757bitstream.c. Marsaglia's published value of sigma is off by close to a 1758factor of two. sigma is in fact 288.6. I have verified this by 1759simulation with very excellent RNGs, e.g. MT or gfsr4 AND with HARDWARE 1760generators (which were failing bitstream before). 1761 1762Marsaglia couldn't resolve the error (which could just have been due to 1763a typo at some point that was perpetuated) because his test didn't run 1764enough times or plot the pvalues in a histogram, but if you plot the 1765obtained means in a histogram and fit a normal to them, there is 1766absolutely no doubt. 1767 1768------------------------------------------------------------------------ 1769r328 | rgb | 2007-05-23 00:35:33 -0400 (Wed, 23 May 2007) | 2 lines 1770 1771Forgot to check this one in... 1772 1773------------------------------------------------------------------------ 1774r327 | rgb | 2007-05-23 00:31:03 -0400 (Wed, 23 May 2007) | 2 lines 1775 1776OK, this is one of two ways to get things to metatron to run faster. 1777 1778------------------------------------------------------------------------ 1779r326 | rgb | 2007-05-22 21:12:07 -0400 (Tue, 22 May 2007) | 3 lines 1780 1781This fixes several problems, and is working its way towards a new 1782release. 1783 1784------------------------------------------------------------------------ 1785r325 | rgb | 2007-05-22 10:04:12 -0400 (Tue, 22 May 2007) | 2 lines 1786 1787Silly checkin, as I dropped a file here that goes below. 1788 1789------------------------------------------------------------------------ 1790r324 | rgb | 2007-05-21 19:46:44 -0400 (Mon, 21 May 2007) | 5 lines 1791 1792Well, we're making LOTS of little changes here. We're splitting off 1793Exit() into its own file so it can be shred, we're moving 1794db_gnu_r_rngs.c to gnu_r_rngs.c, we're adding prototypes and changing 1795the namespace for RDH. All at once. 1796 1797------------------------------------------------------------------------ 1798r323 | rgb | 2007-05-21 18:14:19 -0400 (Mon, 21 May 2007) | 3 lines 1799 1800Fixed small problem in makefile. Otherwise I'm not sure why these files 1801are changing -- they really shouldn't. 1802 1803------------------------------------------------------------------------ 1804r322 | rgb | 2007-05-21 15:04:01 -0400 (Mon, 21 May 2007) | 3 lines 1805 1806I do believe that this now is ready to rock and roll. AFAICT, it "just 1807works". 1808 1809------------------------------------------------------------------------ 1810r321 | rgb | 2007-05-21 14:39:08 -0400 (Mon, 21 May 2007) | 6 lines 1811 1812This is checking in dieharder WITH RDieHarder included and under version 1813control. RDieHarder now depends on dieharder sources. I still haven't 1814got the Makefile, with dependencies, built into the existing Makefile 1815but I will. Basically, I plan three new targets: rdhprep, rdhlib (as 1816root only) and rdhtgz (to make a "package" out of it). 1817 1818------------------------------------------------------------------------ 1819r320 | rgb | 2007-05-21 09:34:44 -0400 (Mon, 21 May 2007) | 10 lines 1820 1821Well, we've been working hard here. Let me try to summarize. I've 1822instrumented the code to make it "easy" to move it to RDieHarder. Dirk 1823doesn't understand, quite, how I plan to make RDH a "part of" the 1824dieharder source tree, but he will when I'm done as it will then be 1825really easy to prep his cran/debian package. I think, I hope. 1826 1827I think that I'm going to need to pursue dieharder this summer pretty 1828aggressively in addition to working on axioms and other books. I should 1829probably look hard at getting money to support it, as well. 1830 1831------------------------------------------------------------------------ 1832r319 | rgb | 2007-05-19 08:14:56 -0400 (Sat, 19 May 2007) | 3 lines 1833 1834We've got to get this to lucifer and then try to unpack it on 1835metatron... 1836 1837------------------------------------------------------------------------ 1838r318 | rgb | 2007-04-29 14:06:32 -0400 (Sun, 29 Apr 2007) | 2 lines 1839 1840This too has to go to lucifer... 1841 1842------------------------------------------------------------------------ 1843r317 | rgb | 2007-03-12 09:50:39 -0400 (Mon, 12 Mar 2007) | 4 lines 1844 1845This is the last set of changes associated with 2.24.3 -- which is 1846hopefully getting really, really close to a release I can live with. 1847I suppose I should fix the man pages, at least to some extent. 1848 1849------------------------------------------------------------------------ 1850r316 | rgb | 2007-03-05 10:35:05 -0500 (Mon, 05 Mar 2007) | 6 lines 1851 1852This looks like it successfully splits off the manual so it is no longer 1853autobuilt and is not in the rpms. 1854 1855From here out the manual will be a SEPARATE project aimed square at lulu 1856publication as a book I might even make money from. 1857 1858------------------------------------------------------------------------ 1859r315 | rgb | 2007-03-05 10:32:43 -0500 (Mon, 05 Mar 2007) | 2 lines 1860 1861We'll work our way there by hook or by crook. 1862 1863------------------------------------------------------------------------ 1864r314 | rgb | 2007-03-05 10:32:03 -0500 (Mon, 05 Mar 2007) | 2 lines 1865 1866Grrr. I just lost a whole bunch of work... 1867 1868------------------------------------------------------------------------ 1869r313 | rgb | 2007-03-01 20:00:11 -0500 (Thu, 01 Mar 2007) | 11 lines 1870 1871This has now been fixed, a la Charles Karney's suggestion and Janusz's 1872paper demonstrates, to use overlapping samples by default. Some tests 1873it really DOES matter, if those tests are valid at all (operm5 being a 1874classic example). I still doubt the bitstream-dna test series -- I 1875think that there is NO difference between overlapping and 1876non-overlapping samples there, or at most a tiny shrinking of the 1877distribution variance in the end, as they don't measure "overlap", only 1878a CLT-limited mean. Overlapping 20 bit samples should make a tiny shift 1879in the sample standard deviation and have no other effect in these 1880tests. 1881 1882------------------------------------------------------------------------ 1883r312 | rgb | 2007-03-01 19:38:44 -0500 (Thu, 01 Mar 2007) | 4 lines 1884 1885This fixes the Bug reported by Brian J. Wong, making bl and bu of a 1886function in bits.c static uint (preserved between calls) instead of 1887dynamic. Probably my bad... 1888 1889------------------------------------------------------------------------ 1890r309 | rgb | 2007-02-28 10:39:58 -0500 (Wed, 28 Feb 2007) | 2 lines 1891 1892Sending this into SVN on general principles. 1893 1894------------------------------------------------------------------------ 1895r308 | rgb | 2007-02-27 22:38:22 -0500 (Tue, 27 Feb 2007) | 10 lines 1896 1897This actually seems to work. So we now have 66 random number generators 1898to test. Tony Pasqualoni's Cellular Automaton rng isn't anywhere NEARLY 1899as fast as he alleges compared to the GSL routines inside identical 1900packaging -- in fact it is about par for the course -- but so far it 1901seems to be 1 bit and 2 bit random, and we're working on a -a run that 1902will expose it to the latest/greatest operm5. It remains to be seen 1903whether or not K. Janusz's paper contains algorithms that will let me 1904check and/or correct Marsaglia's operm5, or perhaps extend the operm5 1905into a RANGE of tests like rgb_bitdist. 1906 1907------------------------------------------------------------------------ 1908r307 | rgb | 2007-02-27 22:19:36 -0500 (Tue, 27 Feb 2007) | 6 lines 1909 1910This is a very first cut of Tony Pasqualoni's Cellular Automaton 1911random number generator, ported into a gsl standard wrapper. This will 1912let me test Tony's assertion that this is a good, very fast rng in 1913exactly the same wrapper that one can study the other "good" (but 1914slower) rng's. 1915 1916------------------------------------------------------------------------ 1917r306 | rgb | 2007-02-27 02:10:12 -0500 (Tue, 27 Feb 2007) | 2 lines 1918 1919This is a really modest checkin, but we'll see if it can manage... 1920 1921------------------------------------------------------------------------ 1922r305 | rgb | 2007-02-27 02:04:24 -0500 (Tue, 27 Feb 2007) | 13 lines 1923 1924TAG 2.24.2 1925 1926I fixed the -q(uiet) flag so that it works, and decided to bundle all of 1927the above bugfixes and feature shifts into a new minor minor bump. This 1928is the "official" GBT build, if Dirk concurs when he tries it. 1929 1930As far as I know, we're at least back where we were when we started 1931implementing GBT and then some. 1932 1933Now, if only I could figure out the trunk thing. Maybe I'll try doing a 1934checkout and build without the trunk movement... 1935 1936 1937------------------------------------------------------------------------ 1938r304 | rgb | 2007-02-27 01:31:45 -0500 (Tue, 27 Feb 2007) | 5 lines 1939 1940TAG 2.24.1-2 1941 1942Fixed documentation and added a hard record of Janusz's bug in operm5. 1943 1944 1945------------------------------------------------------------------------ 1946r303 | rgb | 2007-02-27 01:06:25 -0500 (Tue, 27 Feb 2007) | 2 lines 1947 1948Sending this to Duke, at least... 1949 1950------------------------------------------------------------------------ 1951r302 | rgb | 2007-02-27 01:06:09 -0500 (Tue, 27 Feb 2007) | 47 lines 1952 1953This contains a change suggested by the following: 1954 1955%<snip snip ----- 1956From: Janusz Kawczak <jkawczak@gmail.com> 1957To: Robert G. Brown <rgb@phy.duke.edu> 1958Cc: Dirk Eddelbuettel <edd@debian.org> 1959Subject: Re: Random R-Package 1960 1961Hello, without going to much into peculiarities (for now, at least) of 1962the rngs and numbers coming from Marsaglia and you (Robert), I would 1963like to give the result from our paper that is directly applicable to 1964the operm5 header you cited below: 1965 1966"...(with # rank 99)..." - this is the point I questioned in our paper. 1967I asked Marsaglia how he got this rank, but I never received the reply 1968from him. I can only presume that he either guessed this number or 1969estimated it (somehow). It remains a mystery to me; like a Marsaglia's 1970voodoo step. The answer should be 96=5!-4!. It is not a big deal 1971of a difference in this case, however, the theorem we proved allows one 1972to consider cased of perm6, perm7 ... and higher with the exact number 1973of degree of freedom calculations. Thus, exact and not guessed results. 1974 1975It is my opinion that the operm-type test is very powerful for detecting 1976local correlations (dependencies) and it should be used for such 1977purpose. So, any algorithmic PRNG will suffer and most likely do not 1978dwell well when exposed to this test. I have not had a chance to do 1979serious experiments on the "natural-random" generators, e.g. 1980alpha-particle counting, radio noise signals and many others. But, I 1981suspect that the operm-type test should do well in this situation. 1982 1983I cannot promise at this time much, but I am going to look at the issues 1984you addressed in your e-mail. However, the questions you've raised are a 1985bit different animals to deal with. 1986 1987In summary, it would be useful, once and for all, to correct 99 degrees 1988to 96 in the operm5 Marsaglia's header file. Maybe, one day, this will 1989happen :-) 1990%<snip snip ----- 1991 1992I've implemented this change -- 99 to 96 -- although I welcome any 1993comments. The test still fails the big four -- gsfr4, taus2, ranlxd2, 1994and mt19937 -- nearly all the time, overlapping or not. I still suspect 1995either errors in r and s or (quite possibly) programming errors, but it 1996ALMOST works and lacking a gold standard rng it is difficult to resolve 1997the question numerically. 1998 1999 2000------------------------------------------------------------------------ 2001r301 | rgb | 2007-02-27 00:16:46 -0500 (Tue, 27 Feb 2007) | 4 lines 2002 2003This is an important change -- I fixed an annoyance (if not worse) with 2004the libdieharder setting of the major revision number. I may need to 2005propagate the expr back to the toplevel Make. 2006 2007------------------------------------------------------------------------ 2008r300 | rgb | 2007-02-26 23:39:47 -0500 (Mon, 26 Feb 2007) | 7 lines 2009 2010Dirk found that I was still screwing up the PREFIX thing by stubbornly 2011refusing to use (lower case) prefix, libdir, and includedir in my make 2012install target. I think I've stripped out my own versions of these 2013completely so that they can a) be set by configure and run with "just" 2014make install or b) overridden on the make line, e.g make prefix=/tmp/usr 2015install (as apparently he likes to do to make debian packages). 2016 2017------------------------------------------------------------------------ 2018r299 | rgb | 2007-02-25 14:42:52 -0500 (Sun, 25 Feb 2007) | 3 lines 2019 2020This is definitely experimental, trying to write a web installer 2021modification that I cannot test until I get back the net. 2022 2023------------------------------------------------------------------------ 2024r298 | rgb | 2007-02-25 14:32:05 -0500 (Sun, 25 Feb 2007) | 4 lines 2025 2026Ok, this is TAG=2.24.1, the first Gnu Build Tools release that builds 2027rpms clean from (we hope) SVN. I do need to validate this with one 2028last SVN checkout, but I'm pretty sure it is the case... 2029 2030------------------------------------------------------------------------ 2031r297 | rgb | 2007-02-25 13:35:17 -0500 (Sun, 25 Feb 2007) | 2 lines 2032 2033Well, a time to check in. We're about to see if an rpm build works... 2034 2035------------------------------------------------------------------------ 2036r296 | rgb | 2007-02-25 13:15:29 -0500 (Sun, 25 Feb 2007) | 6 lines 2037 2038This may be a really nice advance. The dieharder build now uses 2039../include and ../libdieharder as -I and -L respectively, and plain old 2040"make" in both cases should work, from a clean checkout. I'm guessing 2041that I can add a simple Makefile.am to include to do the actual install 2042of the include files. 2043 2044------------------------------------------------------------------------ 2045r295 | rgb | 2007-02-25 12:47:10 -0500 (Sun, 25 Feb 2007) | 4 lines 2046 2047This should be REALLY REALLY close. We'll checkin, do a full checkout, 2048and try building. If/when we get there, we'll work strictly from build 2049to build once again. 2050 2051------------------------------------------------------------------------ 2052r294 | rgb | 2007-02-25 12:27:25 -0500 (Sun, 25 Feb 2007) | 4 lines 2053 2054OK, this is one whole cut closer, and ALMOST works, but we're definitely 2055going to have to try this one more time... We also need at some point 2056to stop svn control of Makefiles and maintain only Makefile.ams 2057 2058------------------------------------------------------------------------ 2059r293 | rgb | 2007-02-25 12:17:22 -0500 (Sun, 25 Feb 2007) | 3 lines 2060 2061Adding what MAY be all the things needed to enable full automated Gnu 2062style builds from the autogen.sh script. 2063 2064------------------------------------------------------------------------ 2065r292 | rgb | 2007-02-25 12:16:05 -0500 (Sun, 25 Feb 2007) | 4 lines 2066 2067Finished a first cut at adding GBT support. Need to check in the .in 2068files and configure.ac files one level down, and do a full checkout to 2069see if it autobuilds from an svn checkout. 2070 2071------------------------------------------------------------------------ 2072r291 | rgb | 2007-02-19 09:23:15 -0500 (Mon, 19 Feb 2007) | 3 lines 2073 2074This dumps buildroot. We don't need or want this in the tarball or rpm 2075sources. 2076 2077------------------------------------------------------------------------ 2078r290 | rgb | 2007-02-19 03:47:31 -0500 (Mon, 19 Feb 2007) | 4 lines 2079 2080We are working quite hard on getting the ChangeLog to be automagically 2081registered. I'm guessing it should just go into %doc and we should 2082pretty much forget the tag otherwise. 2083 2084------------------------------------------------------------------------ 2085r289 | rgb | 2007-02-19 03:05:19 -0500 (Mon, 19 Feb 2007) | 5 lines 2086 2087This fixes a variety of problems with using shared libraries correctly, 2088and moves the project much closer to where it could e.g. be included in 2089FC extras. The library builds nicely now, for example. However, I do 2090need to switch to using autoconf, however much I generally dislike it. 2091 2092------------------------------------------------------------------------ 2093r288 | rgb | 2007-02-19 01:32:29 -0500 (Mon, 19 Feb 2007) | 2 lines 2094 2095OK, this fixes some serious uglyness. Let's see if the rpm builds... 2096 2097------------------------------------------------------------------------ 2098r287 | rgb | 2007-02-18 16:49:23 -0500 (Sun, 18 Feb 2007) | 3 lines 2099 2100Updating the svn tree and sync'ing, perhaps for the last time. Will 2101this now reside on code.google.com? We'll see. 2102 2103------------------------------------------------------------------------ 2104r286 | rgb | 2007-02-18 08:37:35 -0500 (Sun, 18 Feb 2007) | 3 lines 2105 2106Let's call this TAG=2.5.24 -- bumping the first minor to announce that 2107we've cleaned up several bugs and repackaged. 2108 2109------------------------------------------------------------------------ 2110r285 | rgb | 2007-02-15 13:55:48 -0500 (Thu, 15 Feb 2007) | 28 lines 2111 2112This fixes a bug reported by Matthias Braeunig <mb.atelier@web.de>, who 2113was running the test on a file of data just one time per test using more 2114or less this line: 2115 2116for t in $(echo "-d"{1..19} "-r"{1..4} "-s"{1..2}); do ./dieharder -q -t9375 -p1 $t;done > results 2117 2118He noted that kstest_kuiper returned 2.0 for input single pvalues of 21190.0, and that the test overall returned a pass even if p=1.0 exactly 2120(which it also should not do for single pvalues). 2121 2122I made the following changes. kstest_kuiper now returns a single input 2123pvalue as its output pvalue -- clearly that's all one can do and the 2124right thing to do. The test.c assessment that prints out the results 2125also no longer calls the return a KStest result, and reports failure 2126a bit differently, flagging the high-p failures as well as the low p 2127failures, and adjusting the reported failure range accordingly. 2128 2129To do this I had to use -static in the Makefile to work in the 2130development tree. I'm guessing that I need to add LDFLAG = -dynamic to 2131the build make line in the specfile and should LEAVE it -static in the 2132actual tree so people don't get stymied if they download and build in 2133the tarball directory ("people" including me) while rpm's will still 2134autobuild dynamic correctly. 2135 2136Finally, Matthias reported that the -q flag doesn't work. He's right, 2137but I'm not sure I'm going to fix that. Rather I should probably just 2138kill it and let people filter the output results by hand... 2139 2140------------------------------------------------------------------------ 2141r284 | rgb | 2007-02-05 23:42:45 -0500 (Mon, 05 Feb 2007) | 4 lines 2142 2143I've just fired this up to the web. I deem it finished enough. 2144Now to backport the library fix to wulfware, and call it a night, very 2145much a night. 2146 2147------------------------------------------------------------------------ 2148r283 | rgb | 2007-02-05 22:06:02 -0500 (Mon, 05 Feb 2007) | 5 lines 2149 2150OK, it installs and builds PERFECTLY, and THIS time it almost certainly 2151is dynamically linking to libdieharder.so, as it linked without the .a 2152library present at all. I'll now have to go retrofit this to wulfware, 2153as it is not building correctly. 2154 2155------------------------------------------------------------------------ 2156r282 | rgb | 2007-02-05 21:39:00 -0500 (Mon, 05 Feb 2007) | 3 lines 2157 2158This actually rand and built! Now to try to rebuild it WITHOUT the .a 2159library installed... 2160 2161------------------------------------------------------------------------ 2162r281 | rgb | 2007-02-05 21:30:42 -0500 (Mon, 05 Feb 2007) | 3 lines 2163 2164Just in case I drop something, I finally seem to have "fixed" the 2165libdieharder makefile. On to fame and glory. 2166 2167------------------------------------------------------------------------ 2168r280 | rgb | 2007-02-05 15:06:05 -0500 (Mon, 05 Feb 2007) | 2 lines 2169 2170OK, this is crawling on closer to ready to go... 2171 2172------------------------------------------------------------------------ 2173r279 | rgb | 2007-02-05 14:51:33 -0500 (Mon, 05 Feb 2007) | 2 lines 2174 2175Make this go away, please. 2176 2177------------------------------------------------------------------------ 2178r277 | rgb | 2007-01-28 10:58:14 -0500 (Sun, 28 Jan 2007) | 6 lines 2179 2180This has a brand new ultra-cool target, "installrepo" that makes the 2181rpms and installs them in the repo, from when yum can install them. 2182 2183BTW, I think I forgot the "requires" tag in the dieharder sources, 2184partly because it seems that it isn't, in fact, required. Hmmm. 2185 2186------------------------------------------------------------------------ 2187r276 | rgb | 2007-01-27 19:11:19 -0500 (Sat, 27 Jan 2007) | 2 lines 2188 2189This works! 2190 2191------------------------------------------------------------------------ 2192r275 | rgb | 2007-01-27 17:39:42 -0500 (Sat, 27 Jan 2007) | 2 lines 2193 2194This is getting really close, worth checking in... 2195 2196------------------------------------------------------------------------ 2197r274 | rgb | 2007-01-27 13:27:14 -0500 (Sat, 27 Jan 2007) | 4 lines 2198 2199This now builds a perfectly rebuildable tarball. We can think about 2200just what else we'd like to add to that tarball in a moment, but first 2201we need to FINALLY get the rpm to build, maybe. 2202 2203------------------------------------------------------------------------ 2204r273 | rgb | 2007-01-27 12:59:42 -0500 (Sat, 27 Jan 2007) | 2 lines 2205 2206This updates the abstract. 2207 2208------------------------------------------------------------------------ 2209r272 | rgb | 2007-01-27 12:50:16 -0500 (Sat, 27 Jan 2007) | 3 lines 2210 2211OK, this just maybe is working now with a target that rebuilds 2212both specfiles and Makefiles when the toplevel Makefile is altered. 2213 2214------------------------------------------------------------------------ 2215r271 | rgb | 2007-01-27 11:57:23 -0500 (Sat, 27 Jan 2007) | 8 lines 2216 2217This is just peachy. make and make install targets work for BOTH 2218dieharder_src and libdieharder directories, which is pretty cool, 2219really. The remaining problem will be how to force a rebuild 2220of the library in such a way that it works when we're developing but 2221doesn't barf when we're rpm-ifying. 2222 2223At this point in time it is high time to try the rpm build. 2224 2225------------------------------------------------------------------------ 2226r270 | rgb | 2007-01-27 11:41:39 -0500 (Sat, 27 Jan 2007) | 3 lines 2227 2228OK, this is making progress. Time to go back to libdieharder and get 2229a build to work there... 2230 2231------------------------------------------------------------------------ 2232r269 | rgb | 2007-01-27 11:13:18 -0500 (Sat, 27 Jan 2007) | 3 lines 2233 2234Just making sure this is all ready to run when I start to edit 2235the Makefile in libdieharder. 2236 2237------------------------------------------------------------------------ 2238r268 | rgb | 2007-01-27 11:08:45 -0500 (Sat, 27 Jan 2007) | 11 lines 2239 2240OK, this is a very painful move. We will, of course, mothball and 2241preserve libdieharder's original svn tree, but now that we're figuring 2242out how to do one specfile, many packages from a single toplevel 2243source tree we no longer wish to maintain libdieharder in a separate 2244subversion project. So we're checking it into this one. All the 2245change history is preserved, but in pieces -- CVSROOT first, 2246subversion's libdieharder second, and from now on, here in the one 2247true dieharder tree and its subversion controlled project. 2248 2249Next we have to get this so that a make install does the right thing. 2250 2251------------------------------------------------------------------------ 2252r267 | rgb | 2007-01-27 10:53:36 -0500 (Sat, 27 Jan 2007) | 7 lines 2253 2254This is a first cut at making dieharder actually build, after 2255libdieharder is built and installed. From now on BOTH will use ONLY 2256the include files that are stored in ./include, which will actually 2257simplify life tremendously. I may symlink them through to the 2258source directory(s) and may even svn control the symlinks, if svn can 2259manage them. CVS couldn't... 2260 2261------------------------------------------------------------------------ 2262r266 | rgb | 2007-01-27 10:31:10 -0500 (Sat, 27 Jan 2007) | 5 lines 2263 2264OK, we are within a single step (removing or moving some include files) 2265of being cleaned up and ready to proceed. I'll probably copy at least 2266part of the sm Makefile to get the hang of looping a make through source 2267directories in order to achieve the make install in the right sequence. 2268 2269------------------------------------------------------------------------ 2270r145 | rgb | 2005-03-14 08:57:05 -0500 (Mon, 14 Mar 2005) | 5 lines 2271 2272This sends in parse.c. Y'know, I'll bet that this is what breaks 2273Dan's access. Shit, looks like I'll have to kiss "make sync" goodbye... 2274or give him an "account" locally with the same uid/gid -- nope that 2275won't work either. Sigh. 2276 2277------------------------------------------------------------------------ 2278r144 | rgb | 2005-03-10 22:42:00 -0500 (Thu, 10 Mar 2005) | 2 lines 2279 2280This goes home and into laptop... 2281 2282------------------------------------------------------------------------ 2283r143 | rgb | 2005-03-10 22:05:41 -0500 (Thu, 10 Mar 2005) | 2 lines 2284 2285Sending this all home, so I can make it on metatron? 2286 2287------------------------------------------------------------------------ 2288r141 | rgb | 2004-11-30 09:14:46 -0500 (Tue, 30 Nov 2004) | 5 lines 2289 2290I think we'll add this to the repository as the "reference run" against 2291the default generator, dieharder -a > dieharder.all. If we update this 2292at the end of every new addition, we'll be able to advance to toolset 2293in a fairly systematic (but generally reliable) way. 2294 2295------------------------------------------------------------------------ 2296r140 | rgb | 2004-11-29 16:36:23 -0500 (Mon, 29 Nov 2004) | 2 lines 2297 2298This looks like it ran nicely. 2299 2300------------------------------------------------------------------------ 2301r139 | rgb | 2004-11-29 14:30:09 -0500 (Mon, 29 Nov 2004) | 3 lines 2302 2303This MIGHT just be a reference run followed by tag bump and checkin. 2304Looks pretty nifty, right up to a first draft of histogram. 2305 2306------------------------------------------------------------------------ 2307r138 | rgb | 2004-11-29 14:03:49 -0500 (Mon, 29 Nov 2004) | 4 lines 2308 2309Adding the published diehard F90 source code to the tree for 2310porting convenience, although we will not use any of it verbatim, 2311obviously, in a c port. 2312 2313------------------------------------------------------------------------ 2314r137 | rgb | 2004-11-29 12:18:04 -0500 (Mon, 29 Nov 2004) | 3 lines 2315 2316I'm hoping that this is the needed binary rank program that analyzes 2317binary (bitlevel) matrices for the diehard binary rank tests. 2318 2319------------------------------------------------------------------------ 2320r136 | rgb | 2004-11-24 01:14:41 -0500 (Wed, 24 Nov 2004) | 5 lines 2321 2322This seems to "work", although it is consistently producing an overall 2323p-value that is in the .9 range and hence "too high". I'm going to 2324start up a full run of 100 x 40000 in a second to see if I get a 2325"normal" pvalue. 2326 2327------------------------------------------------------------------------ 2328r135 | rgb | 2004-11-24 01:00:50 -0500 (Wed, 24 Nov 2004) | 2 lines 2329 2330Well, not JUST that. I suppose that next we'll have to actually debug. 2331 2332------------------------------------------------------------------------ 2333r134 | rgb | 2004-11-24 00:58:30 -0500 (Wed, 24 Nov 2004) | 6 lines 2334 2335This is ALMOST working. I'd say the binary rank part is working, hence 2336the checkin. It is the rank_32x32 part that isn't, but I'll work on it. 2337 2338I suspect something really simple, like needing to normalize y by 2339tsamples... 2340 2341------------------------------------------------------------------------ 2342r133 | rgb | 2004-11-22 15:08:03 -0500 (Mon, 22 Nov 2004) | 4 lines 2343 2344This is simply lovely, simply lovely, with a good start on adding 2345Diehard's Binary Rank test. All I need is a suitably scaled matrix 2346and a few zillion rands... 2347 2348------------------------------------------------------------------------ 2349r132 | rgb | 2004-11-22 14:23:11 -0500 (Mon, 22 Nov 2004) | 2 lines 2350 2351Why didn't these make it to Duke? 2352 2353------------------------------------------------------------------------ 2354r131 | rgb | 2004-11-22 03:35:19 -0500 (Mon, 22 Nov 2004) | 6 lines 2355 2356This is 0.5.8 stable, I hope. Time to go beddy-bye, hoping that this is 2357now ready for real development and grantseeking work. I should be 2358able to add a couple more diehard tests "easily" at this point, I think. 2359 2360 rgb 2361 2362------------------------------------------------------------------------ 2363r129 | rgb | 2004-11-22 01:47:07 -0500 (Mon, 22 Nov 2004) | 5 lines 2364 2365This is VERY VERY close to being a fairly serious tagged checkin. 2366We've resolved the problem of multiline strings in gcc, snagged a 2367C tutorial for gcc, completely fixed the documentation -- this is 2368all pretty awesomely ready for a brave new release. 2369 2370------------------------------------------------------------------------ 2371r128 | rgb | 2004-11-21 23:24:18 -0500 (Sun, 21 Nov 2004) | 11 lines 2372 2373This is really close to working with all the changes in the command 2374line options and associated global variables. In fact, it might BE 2375working. 2376 2377Two things that I really really need are a routine that can take a 2378data object that is one big string and display it to the screen 2379(something gcc refuses to do any more, which sucks big time) and a 20x 2380histogram of p-values. Let's see if I can find them on the web before 2381tackling them -- in particular the former seems like it must have been 2382written by somebody... 2383 2384------------------------------------------------------------------------ 2385r127 | rgb | 2004-11-20 13:17:55 -0500 (Sat, 20 Nov 2004) | 6 lines 2386 2387This is now really truly ready to go, EXCEPT that NOW I have to alter 2388all sorts of command options according to the latest prescriptions in 2389the checkin logs and abstract/web page. And get it "working perfectly" 2390once again. I might even finish this this weekend, if I really hammer 2391at it. 2392 2393------------------------------------------------------------------------ 2394r126 | rgb | 2004-11-20 10:55:07 -0500 (Sat, 20 Nov 2004) | 3 lines 2395 2396This is the REALLY final checkin of rand_rate, I think, before we clone 2397it into dieharder. 2398 2399------------------------------------------------------------------------ 2400r125 | rgb | 2004-11-20 10:50:28 -0500 (Sat, 20 Nov 2004) | 87 lines 2401 2402This is the last checkin of rand_rate AS rand_rate. I'm going to change 2403the name of this suite to dieharder. I'm also going to change the 2404test numbering schema and option naming so that e.g. 2405 2406 -d diehard test number 2407 -r rgb test number 2408 -s sts test number 2409 2410where -1 runs all tests of a given kind, 0 lists a description of all 2411tests in the suite, -2 runs all tests of a given kind EXACTLY as they 2412are run in the original code, if possible -- I'm not sure I'm going to 2413test overlapping bit strings drawn from a single int just to bump the 2414count of "random numbers" unless the test explicitly calls for it and it 2415makes sense, as there is this thing about each sample being 2416"independent" that worries me with overlapping draws. 2417 2418 -p number of p-values in final KS (and possibly other) test(s). This 2419is the number of times each "test" is run with independent random number 2420seeds (as the DEFAULT from now on). This defaults to 100, which is 2421actually a lot and very reasonable but which can be increased if one is 2422in doubt about whether the distribution of p returned by "the test" is 2423in fact uniform. 2424 2425 -t number of test samples that go into making up a single test. This 2426is NOT always a free parameter -- in many of the diehard tests 2427especially, the number of e.g. points drawn from a 2d or 3d volume in 2428the minimum distance tests is fixed, and varying it would vary the 2429target distribution and test statistic. Although this is a bit 2430unfortunate, since varying the number of test samples is an excellent 2431way to make marginal failures in the distribution of p resolve into 2432clear failures, we either live with it or derive general forms for the 2433asymptotic target distributions as a function of the number of samples 2434or do simulations and empirically deduce forms ditto (as Marsaglia and 2435others appear to have done). For the moment we'll live with it. 2436 2437 -b bitstring width. Some tests are applied only to samples that are 2438"bitstrings" (as opposed to e.g. lists of unsigned integers) of 2439user-specifiable length. One reason to limit the tests in this way is 2440to avoid numerical difficulties in e.g. evaluating P_binomial(k,p,n), 2441where one can easily under or overflow and end up with garbage or a gsl 2442fault. Another is to "free" some of the existing tests that have a very 2443specific size of bitstring that they look at so that this can be varied 2444when the target distribution can still be computed as a function of 2445bitstring size. This will be overridden as necessary, like -t, for 2446tests that really do require a fixed bitstring size to approach the 2447known target distribution. 2448 2449 -n ntuple or window width. A number of tests look at bit ntuples. An 2450ntuple is a set of n consecutive bits drawn from a bitstring (possibly 2451of -b specified width) or vector of random uints (possibly of -t 2452specified length). ntuples are always drawn relative to a bit offset 2453specified from the right (least significant) with 0 being the rightmost 2454bit, with cyclic boundary conditions on the entire bitstring >>or<< 2455sample uint vector, so drawing an ntuple cannot fail for any offset 2456within the number of significant bits returned by the generator (which 2457MAY NOT BE 32, or even 31 -- some generators return as few as 16 2458significant bits!). 2459 2460For example, an 8-bit bitstring might be: 2461 2462 01100111 2463 2464and all the 3-tuples drawn from it are given by 2465 2466 offset 3-tuple 2467===================== 2468 0 111 2469 1 011 2470 2 001 2471 3 100 2472 4 110 2473 5 011 2474 6 101 <- Note wrap around! 2475 7 110 <- Ditto! 2476 2477A general purpose 2478 2479 get_bit_ntuple(*bitstring,bitstring size,ntuple size,offset) 2480 2481routine is provided that is used by many tests to get ntuples from a 2482uint *bitstring of given >>uint vector length<< (not bitstring length). 2483 2484Other test controls may be added as well, but these are what I'm going 2485to document right now. Mostly I'm checking in all the placeholders 2486required for the rest of the diehard tests so I can start to knock them 2487off systematically. Sure hope I'm past major rewrites! 2488 2489------------------------------------------------------------------------ 2490r124 | rgb | 2004-11-20 03:07:19 -0500 (Sat, 20 Nov 2004) | 2 lines 2491 2492Fixed silly spelling error (sigh). 2493 2494------------------------------------------------------------------------ 2495r123 | rgb | 2004-11-20 02:50:00 -0500 (Sat, 20 Nov 2004) | 3 lines 2496 2497Well, that was quick. A nasty (but easy) little bug in diehard_runs 2498squashed (size -> tsamples). 2499 2500------------------------------------------------------------------------ 2501r122 | rgb | 2004-11-20 02:47:34 -0500 (Sat, 20 Nov 2004) | 14 lines 2502 2503This should/maybe be a serious v 0.5.3 checkin. We are about to try 2504-v -1. If it works, it will cycle through all of the working tests 2505(and all the tests are working). All the tests are now written in 2506a way that they can use sample and kstest_kuiper() to do the validation 2507of the p-values obtained from running a possibly size-variable test 2508on bits or frequencies or runs or whatever. 2509 2510If this test works, it is off to the website, I'm off to bed, and next 2511we go back to moving in new diehard tests. With the magical sliding 2512bitwindow (which really does seem to work pretty well:-) implementing 2513at least the n-tuple diehard tests should now be pretty easy, and I 2514can probably do a more rigorous job than GM did because I don't have 2515to scrimp on rands. 2516 2517------------------------------------------------------------------------ 2518r120 | rgb | 2004-11-20 02:34:39 -0500 (Sat, 20 Nov 2004) | 2 lines 2519 2520Try again (network down). 2521 2522------------------------------------------------------------------------ 2523r119 | rgb | 2004-11-20 02:34:07 -0500 (Sat, 20 Nov 2004) | 4 lines 2524 2525This clears diehard_birthdays AND diehard_2dsphere. Only one diehard 2526to go and we'll have EVERYTHING running with sample and the new test 2527format (but of course rgb_persist, which doesn't count). 2528 2529------------------------------------------------------------------------ 2530r118 | rgb | 2004-11-19 22:11:12 -0500 (Fri, 19 Nov 2004) | 2 lines 2531 2532Fixed up diehard_runs so it uses the new test format. Works charmlike. 2533 2534------------------------------------------------------------------------ 2535r117 | rgb | 2004-11-19 18:38:19 -0500 (Fri, 19 Nov 2004) | 5 lines 2536 2537This is v 0.5.1, which is nicely fixed for BOTH sts_monobit AND 2538sts_runs, both in the new format, with a consistent Xtest_eval() 2539routine. This fixes lots of things -- both tests are very likely 2540to be "good". 2541 2542------------------------------------------------------------------------ 2543r115 | rgb | 2004-11-19 18:34:38 -0500 (Fri, 19 Nov 2004) | 7 lines 2544 2545OK, this looks like sts_runs is now "good" in the new format. However, 2546it may have broken sts_monobit. The problem is, is there or is there 2547not a sqrt(2.0) in the erfc relative to sigma, and if there is is 2548there an EXTRA one in sts_runs vs sts_monobit. Need to clear this up 2549and either always put it into Xtest or always put it into xtest.sigma, 2550but not both. 2551 2552------------------------------------------------------------------------ 2553r114 | rgb | 2004-11-19 16:06:34 -0500 (Fri, 19 Nov 2004) | 2 lines 2554 2555Sending this home, I hope. 2556 2557------------------------------------------------------------------------ 2558r113 | rgb | 2004-11-19 15:09:15 -0500 (Fri, 19 Nov 2004) | 8 lines 2559 2560This is now squeaky clean for rgb_bitdist and sts_monobit, and we're 2561working on sts_runs. Then a quick dash through the diehards and we'll 2562be back to where we were but a bit cleaner. 2563 2564I still MIGHT try to get cleaner still. I'm not at all convinced 2565that I need the test structs, for example, although perhaps they 2566allow some encapsulation that is useful. 2567 2568------------------------------------------------------------------------ 2569r112 | rgb | 2004-11-19 13:55:01 -0500 (Fri, 19 Nov 2004) | 3 lines 2570 2571This is a checkin to Duke of the nifty neato cool new improved 2572version. It may be time to change the name and everything. 2573 2574------------------------------------------------------------------------ 2575r111 | rgb | 2004-11-19 12:35:19 -0500 (Fri, 19 Nov 2004) | 4 lines 2576 2577OK so there was one more teeny bug in rgb_bitdist() -- wrong order in 2578the final output statement. Fixed. I also added a feature, reseeding 2579the rng in sample on an -i flag. 2580 2581------------------------------------------------------------------------ 2582r110 | rgb | 2004-11-19 12:28:09 -0500 (Fri, 19 Nov 2004) | 4 lines 2583 2584This is just ensuring that the tag for version 0.5.0 is noted. This 2585version works through rgb_bitdist, which I'll bet a nickel is a very 2586powerful test indeed. 2587 2588------------------------------------------------------------------------ 2589r108 | rgb | 2004-11-19 12:26:42 -0500 (Fri, 19 Nov 2004) | 4 lines 2590 2591This is a "permanent" checkin. I think that this fixes rgb_bitdist 2592nicely to use sample() and provides a prototype for doing other 2593tests. 2594 2595------------------------------------------------------------------------ 2596r106 | rgb | 2004-11-18 21:09:25 -0500 (Thu, 18 Nov 2004) | 11 lines 2597 2598This is a fairly major fix -- I was truncating blen in bits.c at 2599the sizeof(uint), not 8*sizeof(uint). One lesson is that this 2600truncation isn't right anyway. We rather need to just punt/die. 2601 2602I'm wondering now if the apparent failure that is still present 2603(although not nearly as bad) for the larger ntuples is because fewer 2604bins pass the cutoff in the formation of the primary sample pvalue(s). 2605 2606We might just try lowering this cutoff a bit. I don't know exactly what 2607a "degree of freedom" is, but we do need to be pretty careful with it. 2608 2609------------------------------------------------------------------------ 2610r105 | rgb | 2004-11-18 18:43:21 -0500 (Thu, 18 Nov 2004) | 6 lines 2611 2612Now it REALLY looks like it works, and even the best rng's look like 2613they FAIL the test in fairly short order. Now we're cookin' with gas, 2614although I've got to see the details of the failure soon enough. 2615 2616Hmmm, maybe I need to have a lot more bins... 2617 2618------------------------------------------------------------------------ 2619r104 | rgb | 2004-11-18 18:25:52 -0500 (Thu, 18 Nov 2004) | 3 lines 2620 2621Just to verify that it APPEARS to work to quite high precision through 2622triplets. We could just keep adding things, I suppose... 2623 2624------------------------------------------------------------------------ 2625r103 | rgb | 2004-11-18 18:17:39 -0500 (Thu, 18 Nov 2004) | 22 lines 2626 2627This is now working. Working amazingly well, actually. Well enough 2628to double the size of the bits in rgb_bitdist_test(). 2629 2630The one MAJOR remaining problem is that I cannot use samples for tests 2631that return a vector of pvalues. Oh, and it is fairly difficult to 2632pass arguments to the testing function in when it is an argument TO 2633samples(). 2634 2635This means that I have two itty bitty problems to solve -- one is to 2636pass in parameters (possibly by making them global variables). This 2637makes sense IF I want to be able to control them from the command line 2638anyway. The other is to return a vector of pvalues. The only way I 2639can think of doing this is to make pvalues[] a global vector as well 2640of length (say) 1K. This puts an upper bound on the number of pvalues 2641that can be returned by a test, but that SHOULDN'T be much of a problem, 2642as it is really a question of what granularity one wishes to evaluate p 2643at. 2644 2645Anyway, just a BIT more work and rgb_bitdist should be production ready, 2646AND I should be perfectly ready to clean up p-sampling and testing as 2647separate entities in the other tests. 2648 2649------------------------------------------------------------------------ 2650r102 | rgb | 2004-11-18 17:28:50 -0500 (Thu, 18 Nov 2004) | 2 lines 2651 2652This MIGHT be working. 2653 2654------------------------------------------------------------------------ 2655r101 | rgb | 2004-11-18 15:42:41 -0500 (Thu, 18 Nov 2004) | 2 lines 2656 2657I sent this home, I did, I did. 2658 2659------------------------------------------------------------------------ 2660r100 | rgb | 2004-11-18 15:08:32 -0500 (Thu, 18 Nov 2004) | 14 lines 2661 2662This is still fairly screwed up, at least in the sense that 2663it doesn't look like rgb_bitdist works. Curiously, it LOOKS like 2664it WORKS -- walking through the code, it looks VERY much like it 2665is collecting two bits at a time and correctly incrementing the 2666correct bit count in the correct vector. 2667 2668The final histogram, however, comes out wrong, wrong, wrong. 2669 2670I may have to make this simpler. Or maybe I'm doing something else 2671wrong -- come to think of it, the totals in the histograms shouldn't 2672equal the number of samples for EACH value of the ntuple, only the 2673total should sum to the number of samples. Maybe this is what is 2674wrong... 2675 2676------------------------------------------------------------------------ 2677r99 | rgb | 2004-11-18 11:27:27 -0500 (Thu, 18 Nov 2004) | 13 lines 2678 2679We have to go into Duke, but we are very much ready to finish off bits.c 2680and rgb_bitdist.c to where we can eliminate BOTH rgb_binomial AND 2681rgb_bit2.c AND at least one, maybe 3-4 diehard tests AND a couple or 2682three sts tests as being equivalent to this test, for particular call 2683values. I have great hope that this rgb_bitdist will become "the" bit 2684frequency test for all random bit sequences. There may still be a point 2685to tests that look at intervals >>between<< bit sequences thought. 2686 2687In fact, I suspect that the best way to proceed with the latter is to 2688test lagged correlation for arbitrary lags in a long bitstring. This 2689SAME TEST applied with arbitrary displacements between samples might be 2690revealing... 2691 2692------------------------------------------------------------------------ 2693r98 | rgb | 2004-11-17 14:57:04 -0500 (Wed, 17 Nov 2004) | 5 lines 2694 2695This is HIGHLY BROKEN but is absolutely necessary. We have to break 2696this code up to unify the replicated pieces and streamline the 2697testing processes now that we know how a test "works" in the 2698abstract. 2699 2700------------------------------------------------------------------------ 2701r97 | rgb | 2004-11-16 22:40:28 -0500 (Tue, 16 Nov 2004) | 16 lines 2702 2703A bugfix commit. The sanity check in get_bit() is broken and is 2704commented out -- if I'm going to allocate rand_int[] vectors other than 2705size in length, I cannot test on a global size to see if get_bit() is 2706out of bounds. This is STILL broken in that there is a risk with no 2707warning, but there is also functionality for the moment (and I have 2708to write a bunch of new bitlevel functions and can rewrite get_bits 2709at the same time). 2710 2711More important, I found a real bug in Btest where I was initializing 2712btest->chisq to zero before accumulation but was accumulating in chisq. 2713Curiously, it worked a lot of the time the old way, but only for certain 2714rng's. I may have memory management problem, which isn't surprising 2715given the slovenliness of the code at this moment...;-) 2716 2717 rgb 2718 2719------------------------------------------------------------------------ 2720r96 | rgb | 2004-11-16 18:46:17 -0500 (Tue, 16 Nov 2004) | 2 lines 2721 2722This is a tagged checkin, about to push. 2723 2724------------------------------------------------------------------------ 2725r94 | rgb | 2004-11-16 18:45:43 -0500 (Tue, 16 Nov 2004) | 2 lines 2726 2727This appears ready for a checkin. 2728 2729------------------------------------------------------------------------ 2730r93 | rgb | 2004-11-16 18:19:54 -0500 (Tue, 16 Nov 2004) | 4 lines 2731 2732This appears to FINALLY fix rgb_binomial so that it reliably works. 2733It remains to be seen whether or not it is any more senstitive than e.g. 2734sts_monobit. 2735 2736------------------------------------------------------------------------ 2737r92 | rgb | 2004-11-16 15:11:18 -0500 (Tue, 16 Nov 2004) | 3 lines 2738 2739This is STILL broken as far as the Ntests are concerned. I've really 2740got to figure this out... 2741 2742------------------------------------------------------------------------ 2743r91 | rgb | 2004-11-16 10:51:23 -0500 (Tue, 16 Nov 2004) | 2 lines 2744 2745Send this to Duke to finish this morning. 2746 2747------------------------------------------------------------------------ 2748r90 | rgb | 2004-11-14 12:40:14 -0500 (Sun, 14 Nov 2004) | 61 lines 2749 2750This is a pretty serious bugfix -- probably need to update the website. 2751Basically, my kstest was simply wrong last night; now it is working, 2752I've also added the Kuiper form of the KS test, and will program 2753Anderson and Darling's version (the one used, apparently, in Diehard) 2754when I get around to it. However, for tests involving more than a very 2755few p-values in a vector, it shouldn't really matter -- Kuiper KS and the 2756regular KS and Anderson-Davis KS should all GENERALLY generate similar 2757p-distributions -- different perhaps where they don't matter, but very 2758similar at the ends. The key question is just whether one has a 2759tendency to pass a vector of p-values where the other would consistently 2760fail it. So far it looks like USUALLY if one fails the other fails. 2761 2762I think I'm still going to want to do a histogram picture of binned 2763pvalues and do a Pearson chisq p-test on the result. This should really 2764be pretty easy... maybe today, maybe not. 2765 2766We're getting close to being ready to go BACK and mess with the Ntest 2767and Xtest stuff. I think that now that I understand Pearson vs the 2768alternatives, I can PROBABLY arrange things so that I can use a single 2769set of common tools to do all the test assessment. 2770 2771One thing, for example, would be to make each test return a p-value, 2772period, and put the samples loop in rand_rate_work, to ALWAYS fill a 2773vector of p-values and ALWAYS do KS tests, confidence interval tests, 2774and histogram tests. This would have a number of advantages -- being 2775able to produce a really pretty, really standardized picture of results 2776for one. 2777 2778A second thing that would make this tool relatively interesting to the 2779mass unwashed would be to put a nice little GUI onto it. There are two 2780generic ways to do this. One is to leave it a command line tool but 2781REALLY clean up the output result so that it is just a single line 2782per test with ks test scores for the various forms of test with three 2783lines of # delimited frame, period. Then I can make a perl-Gtk app to 2784call the binary, parse the result, and (e.g.) plot histograms or do 2785other nifty graphical things. The other is to use Gtk directly, but 2786perhaps have the GUI only come up if there is an appropriate command 2787line flag (or not). 2788 2789A third thing to work on is clearly going to be splitting the source 2790into distinct components in distinct directories. We will need a common 2791library containing the kstest, chisq, Ntest, Xtest etc code, the input, 2792the output, etc. We will need a directory containing extensions to the 2793GSL random number library, e.g. /dev/random, /dev/urandom, empty, and 2794shuffled because the one thing that is absolutely true is that we need 2795to add a shuffling/mixing random number generator, one that permits us 2796to set up a shuffling list and refill it from a secondary LIST of rng's! 2797 2798A fourth thing (noted already elsewhere) is to do the simplest of tests 2799-- apply a KS test to the GSL distribution-specific generators 2800themselves. If a "test" is generically generating a known distribution 2801presuming randomness and then seeing if the result is indeed the 2802targeted distribution, then EVERY distribution generator in the GSL can 2803simultaneously be the target of a test for algorithmic purposes AND a 2804test component for the GSL rng's. 2805 2806Beyond that, I need to implement spectral tests and tests for 2807hyperplanes in N dimensions and uniformity tests. Sigh. I think that I 2808DO need to write a grant proposal for this -- I think there is enough 2809work to justify it. 2810 2811------------------------------------------------------------------------ 2812r89 | rgb | 2004-11-14 04:38:33 -0500 (Sun, 14 Nov 2004) | 3 lines 2813 2814Tagged and on the repository as 0.4.3, with diehard 3d spheres and a 2815MAYBE working KS test. 2816 2817------------------------------------------------------------------------ 2818r87 | rgb | 2004-11-14 04:37:35 -0500 (Sun, 14 Nov 2004) | 2 lines 2819 2820Sort of playing with KS -- I'm not done here yet... 2821 2822------------------------------------------------------------------------ 2823r86 | rgb | 2004-11-14 03:04:37 -0500 (Sun, 14 Nov 2004) | 8 lines 2824 2825OK, found my REALLY stupid bug. I was computing the absolute 2826length of r from the origin, not the distance between point pairs. 2827No, I wasn't even doing that well -- I was computing the dot product 2828of the random vectors. Now things look nearly correct. 2829 2830All I need is a KS test and life would be, if not complete, well, worth 2831living. 2832 2833------------------------------------------------------------------------ 2834r85 | rgb | 2004-11-14 02:22:29 -0500 (Sun, 14 Nov 2004) | 5 lines 2835 2836This "works". Except that it doesn't. It's very odd, but although 2837it works perfectly as far as I can tell by any measure, r is simply not 2838as small as it should be in order to make the pvalue come out between 28390 and 1. 2840 2841------------------------------------------------------------------------ 2842r84 | rgb | 2004-11-13 20:19:53 -0500 (Sat, 13 Nov 2004) | 2 lines 2843 2844THis is on the way to being another test. 2845 2846------------------------------------------------------------------------ 2847r83 | rgb | 2004-11-13 17:19:55 -0500 (Sat, 13 Nov 2004) | 2 lines 2848 2849This is hopefully a tagged snapshot with a new test! 2850 2851------------------------------------------------------------------------ 2852r81 | rgb | 2004-11-13 16:50:54 -0500 (Sat, 13 Nov 2004) | 8 lines 2853 2854OK, time to bump the revision number, as birthdays is home and even 2855works tolerably, as far as I can tell. 2856 2857SOON I'm going to do the KS test on vectors of p's. SOON I'm going to 2858really clean up the code so that chisq -> p is consistently computed, 2859and so that a set of p's is consistently evaluated for the 2860random/nonrandom decision. 2861 2862------------------------------------------------------------------------ 2863r80 | rgb | 2004-11-13 12:17:57 -0500 (Sat, 13 Nov 2004) | 2 lines 2864 2865This is it, ready to proceed. 2866 2867------------------------------------------------------------------------ 2868r79 | rgb | 2004-11-13 12:12:24 -0500 (Sat, 13 Nov 2004) | 3 lines 2869 2870This checks in a placeholder for a Kolmogorov-Smirnov test, likely to 2871be applied to a vector of p-values. 2872 2873------------------------------------------------------------------------ 2874r78 | rgb | 2004-11-13 12:06:36 -0500 (Sat, 13 Nov 2004) | 10 lines 2875 2876We'll commit this for the moment. I think the sensible thing to do is 2877to create as general as possible a tool for generating Pearson's chisq 2878for discretely binned data, in particular and immediately for the 2879Poissonian birthday histogram but also for other purposes. Note that 2880these routines should not only generate chisq, but when possible go 2881ahead and compute goodness of fit p-values, ideally in a vector 2882associated with independent trials. This vector of p-values can itself 2883then be subjected to a kolmogorov-smirnov analysis and transformed into 2884a conclusion for the generator being tested. 2885 2886------------------------------------------------------------------------ 2887r77 | rgb | 2004-11-13 04:34:29 -0500 (Sat, 13 Nov 2004) | 3 lines 2888 2889Just added output of lambda, which is indeed 2 with the parameters 2890given... 2891 2892------------------------------------------------------------------------ 2893r76 | rgb | 2004-11-13 04:32:46 -0500 (Sat, 13 Nov 2004) | 7 lines 2894 2895This is REALLY CLOSE to having diehard birthdays finished. We just 2896need to add a chisq test for Poisson distributions sampled samples times 2897with known (per sample) lambda, and a loop to convert a table of chisq into 2898a table of p-values. I'm tempted to bump minor and tag, but I shouldn't 2899need to -- I've been really careful and things really look like they're 2900working so far. 2901 2902------------------------------------------------------------------------ 2903r75 | rgb | 2004-11-12 21:02:55 -0500 (Fri, 12 Nov 2004) | 2 lines 2904 2905This is a simple checkin prior to doing diehard birthdays test. 2906 2907------------------------------------------------------------------------ 2908r74 | rgb | 2004-11-12 20:32:58 -0500 (Fri, 12 Nov 2004) | 2 lines 2909 2910This splits off the confidence interval test from STS docs. 2911 2912------------------------------------------------------------------------ 2913r73 | rgb | 2004-11-12 20:28:07 -0500 (Fri, 12 Nov 2004) | 3 lines 2914 2915This is a small adjustment (still in 0.4.1 I guess). Let's try another 2916diehard, I think. 2917 2918------------------------------------------------------------------------ 2919r72 | rgb | 2004-11-12 20:16:48 -0500 (Fri, 12 Nov 2004) | 10 lines 2920 2921This is actually a fairly functional diehard test! 2922 2923I think that we can actually implement a test for the uniformity of 2924p-values as suggested by NIST to run on TOP of the existing confidence 2925interval test. This would actually break the p-distribution down by 2926interval and return a p-value of its own computed against the assumption 2927of uniformity. Or I could get fancier and try kolmogorov-smirnov, if 2928GSL doesn't have one and I work hard enough to program one. If this is 2929really distinct -- it isn't clear that it is. 2930 2931------------------------------------------------------------------------ 2932r70 | rgb | 2004-11-12 17:32:03 -0500 (Fri, 12 Nov 2004) | 4 lines 2933 2934This is actually sort of semi-functional. What I >>really<< need now 2935is canned Kolmogorov-Smirnov code. Could it be that this is in the 2936GSL already? I'll be it is... 2937 2938------------------------------------------------------------------------ 2939r69 | rgb | 2004-11-11 10:59:28 -0500 (Thu, 11 Nov 2004) | 2 lines 2940 2941Continuing to hack this up. 2942 2943------------------------------------------------------------------------ 2944r68 | rgb | 2004-11-10 17:19:21 -0500 (Wed, 10 Nov 2004) | 3 lines 2945 2946This is a nearly functional diehard_runs -- I just need to figure out 2947what the expected values and sigmas are... 2948 2949------------------------------------------------------------------------ 2950r67 | rgb | 2004-11-10 00:32:44 -0500 (Wed, 10 Nov 2004) | 4 lines 2951 2952This is simply lovely. A nice litte addition to the Makefile that 2953automatically indicates the current version in the abstract. I actually 2954have things fairly distributable! 2955 2956------------------------------------------------------------------------ 2957r66 | rgb | 2004-11-10 00:24:18 -0500 (Wed, 10 Nov 2004) | 10 lines 2958 2959OK, added a few minor changes to manage the bits issue yet another way. 2960 2961Really, I'm going to have to figure out a consistent way of indicating 2962whether a test can have size OR bits OR both OR neither specified. 2963 2964Also, it would be really lovely to have another outer loop and to 2965present the lowest p in a set of (say) ten runs of a test combo. 2966Although in many cases running with -s 10x larger should do the same 2967thing, really. 2968 2969------------------------------------------------------------------------ 2970r65 | rgb | 2004-11-09 23:53:49 -0500 (Tue, 09 Nov 2004) | 2 lines 2971 2972This is it and running, version 0.4.0 as published. Seems to work. 2973 2974------------------------------------------------------------------------ 2975r63 | rgb | 2004-11-09 23:53:15 -0500 (Tue, 09 Nov 2004) | 2 lines 2976 2977One last checkin, then a tag, then a checkin as published. 2978 2979------------------------------------------------------------------------ 2980r61 | rgb | 2004-11-09 20:43:14 -0500 (Tue, 09 Nov 2004) | 3 lines 2981 2982This is a tagged release, mostly bugfixes. At the moment it all looks 2983like it works. 2984 2985------------------------------------------------------------------------ 2986r59 | rgb | 2004-11-09 20:37:58 -0500 (Tue, 09 Nov 2004) | 9 lines 2987 2988This seems to work perfectly, for the very short moment. It is by no 2989means perfect or mutually exclusive. We very definitely need to 2990generalize the bitdist test to handle bit ntuples of arbitrary length, 2991where the length is a variable. 2992 2993I think I'll retag this. It is also probably time to think about 2994putting this up on the website, especially if I'm going to write a 2995proposal on it. 2996 2997------------------------------------------------------------------------ 2998r58 | rgb | 2004-11-09 17:14:57 -0500 (Tue, 09 Nov 2004) | 2 lines 2999 3000Because it wasn't checked in! 3001 3002------------------------------------------------------------------------ 3003r57 | rgb | 2004-11-09 17:14:36 -0500 (Tue, 09 Nov 2004) | 2 lines 3004 3005Why didn't bit2.c go home? 3006 3007------------------------------------------------------------------------ 3008r56 | rgb | 2004-11-09 15:09:36 -0500 (Tue, 09 Nov 2004) | 3 lines 3009 3010This is going home with a split out routine and some nice changes that 3011will make it easier to add new tests with arbitrary numbers. 3012 3013------------------------------------------------------------------------ 3014r55 | rgb | 2004-11-09 14:30:32 -0500 (Tue, 09 Nov 2004) | 2 lines 3015 3016Just checking repository Root. 3017 3018------------------------------------------------------------------------ 3019r54 | rgb | 2004-11-09 14:30:05 -0500 (Tue, 09 Nov 2004) | 2 lines 3020 3021Let's send this home... 3022 3023------------------------------------------------------------------------ 3024r53 | rgb | 2004-11-09 09:51:31 -0500 (Tue, 09 Nov 2004) | 7 lines 3025 3026OK, fixing Makefile to actually get this home, AND adding the URL 3027of the web reference from the last checkin: 3028 3029 http://world.std.com/~franl/crypto/random-numbers.html 3030 3031(we need to implement some of its hyperplane tests). 3032 3033------------------------------------------------------------------------ 3034r52 | rgb | 2004-11-09 09:48:40 -0500 (Tue, 09 Nov 2004) | 5 lines 3035 3036We're actually working on this once again. I need to get my own "runs" 3037test working, as it will replace a whole RANGE of STS, and I need to 3038implement a spectral distribution test with bins as is done in the 3039nice web reference I found. 3040 3041------------------------------------------------------------------------ 3042r51 | rgb | 2004-11-08 09:52:52 -0500 (Mon, 08 Nov 2004) | 2 lines 3043 3044This adds yet another built-in device to GSL. 3045 3046------------------------------------------------------------------------ 3047r50 | rgb | 2003-06-10 11:21:15 -0400 (Tue, 10 Jun 2003) | 3 lines 3048 3049This adds an "empty" generator to help us determine gsl call overhead 3050separately. 3051 3052------------------------------------------------------------------------ 3053r49 | rgb | 2003-01-30 17:16:15 -0500 (Thu, 30 Jan 2003) | 4 lines 3054 3055This is broken as shit. I see what I did -- I made the ntest evaluation 3056and presentation routines use n+1 bits (because in rgb_binomial I needed 3057to do the end of the binomial). However, I have to fix it later... 3058 3059------------------------------------------------------------------------ 3060r48 | rgb | 2003-01-30 15:12:20 -0500 (Thu, 30 Jan 2003) | 2 lines 3061 3062Forgot to send this... 3063 3064------------------------------------------------------------------------ 3065r47 | rgb | 2003-01-29 14:19:55 -0500 (Wed, 29 Jan 2003) | 4 lines 3066 3067Not obviously broken, and time to add bitpair counters. Should be 3068really easy -- left-shift in two bits at a time to creat the int index 3069of the counter, then increment it. 3070 3071------------------------------------------------------------------------ 3072r46 | rgb | 2003-01-29 09:27:09 -0500 (Wed, 29 Jan 2003) | 2 lines 3073 3074Some NOTES on future work. 3075 3076------------------------------------------------------------------------ 3077r45 | rgb | 2003-01-29 09:14:38 -0500 (Wed, 29 Jan 2003) | 8 lines 3078 3079This checks in a whole new test, which should probably be combined with 3080 sts_monobit (it generates monobit stats as it goes) 3081 rgb_persist (one can easily generate a bitmask as one goes) 3082 rgb_binomial (one can generate binomial stats on top of monobit as one 3083 goes). 3084 3085 and possibly with more tests. 3086 3087------------------------------------------------------------------------ 3088r44 | rgb | 2003-01-26 02:54:43 -0500 (Sun, 26 Jan 2003) | 7 lines 3089 3090This last little pair of changes causes measure_rate to use its own, 3091fixed, number of samples ("more than enough"). It also installs a 3092"summary report" mode that isn't horribly useful because of conflict 3093between e.g. -b, -n, -s definitions here and there. Also, different 3094tests need to be run in different ways to demonstrate failure (or a 3095lack thereof). 3096 3097------------------------------------------------------------------------ 3098r43 | rgb | 2003-01-26 02:23:28 -0500 (Sun, 26 Jan 2003) | 9 lines 3099 3100OK, we haven't done TOO much, but we have definitely learned that 3101all the rng's that are weak in rgb_persist will definitely fail the 3102monobit test (for obvious reasons). Furthermore, when a generator 3103is weak in certain bits and we evaluate the bits from the other end 3104(whichever end that might be!) it can often PASS the monobit test. 3105 3106Bits that repeat, random_max's that aren't powers of two-1 (and probably 3107EVEN powers of two at that) are going to be trouble! 3108 3109------------------------------------------------------------------------ 3110r42 | rgb | 2003-01-26 00:00:04 -0500 (Sun, 26 Jan 2003) | 4 lines 3111 3112This is a VERY IMPORTANT new test, rgb_persist(), and a very useful 3113new routine, dumpbits(). Read NOTES (and inline comments and output) 3114to see a bit of what it does and why it is important. 3115 3116------------------------------------------------------------------------ 3117r41 | rgb | 2003-01-25 16:55:32 -0500 (Sat, 25 Jan 2003) | 3 lines 3118 3119This actually works. In fact, it works fabulously. I can directly 3120and fairly powerfully look for bitlevel correlations in the output. 3121 3122------------------------------------------------------------------------ 3123r40 | rgb | 2003-01-25 15:53:55 -0500 (Sat, 25 Jan 2003) | 16 lines 3124 3125OK, we've learned the hard way that some bits in e.g. boroshi don't 3126change AT ALL, EVER. Which makes it pretty hard to be random, of 3127course. 3128 3129So we're going to invent a new tool -- rgb_persist(), which doesn't 3130(yet) to a formal statistical test. It just is going to dump successive 3131unsigned ints from the rng (bitwise) AND maybe run a string of &'s on 3132the string of ints returned. If they share any 1 bits, the successive 3133&'s will preserve them a LOT longer than permitted by binary flips on 3134the slots. 3135 3136This could be made into a fairly powerful bitlevel sequential 3137correlation test in several ways. We'll investigate them as we go, but 3138one reason to write this now is that I'm not quite convinced that what 3139I'm seeing isn't some sort of bug in the get_bit() routine or the like. 3140 3141------------------------------------------------------------------------ 3142r39 | rgb | 2003-01-25 10:54:02 -0500 (Sat, 25 Jan 2003) | 3 lines 3143 3144This is well on the way to being MUCH better, and ready to 3145systematically extend. 3146 3147------------------------------------------------------------------------ 3148r38 | rgb | 2003-01-24 19:50:32 -0500 (Fri, 24 Jan 2003) | 2 lines 3149 3150And now we send the tagged package to Duke. 3151 3152------------------------------------------------------------------------ 3153r36 | rgb | 2003-01-24 19:50:07 -0500 (Fri, 24 Jan 2003) | 2 lines 3154 3155Checking in the notes. 3156 3157------------------------------------------------------------------------ 3158r35 | rgb | 2003-01-24 17:52:03 -0500 (Fri, 24 Jan 2003) | 20 lines 3159 3160This is worth a minor bump. First, we fixed get_bit(). Second, we 3161completed sts_runs (for what it is worth, which isn't a whole lot as 3162nearly everything that fails it also fails monobit and binomial as 3163expected). However, working through it suggests how to make binomial 3164work better. 3165 3166Next (to make it easier to check results relative to the sts documents) 3167I need to implement -b (get_bit(0 permits this pretty much 3168transparently, at least in the sts routines) and implement a -f filename 3169filled with e.g. raw bitstrings or ascii floats or binary numbers 3170in xmlish wrappers that indicate the storage mechanism? Thus I can test 3171explicit short bitstrings against the explicit sts numbers to be sure 3172that my erfc and conversions (and sometimes slightly different 3173implementation) yield the same answers as theirs, except where I don't 3174care because I think theirs are (basically) wrong. 3175 3176See also NOTES (about to be checked in) for a fairly detailed beginning 3177critique of sts, which I don't think is particularly strong or useful, 3178really. 3179 3180------------------------------------------------------------------------ 3181r34 | rgb | 2003-01-24 16:43:14 -0500 (Fri, 24 Jan 2003) | 6 lines 3182 3183This is my home-grown version of sts_runs. It is no better than the 3184actual sts version, really, but the sts version is not terribly good. 3185I'm going to add a (hopefully vastly improved) binomial version of the 3186test to rgb_binomial, where I can do all the tests at once with a 3187single set of code and multiple trials (random number seeds). 3188 3189------------------------------------------------------------------------ 3190r33 | rgb | 2003-01-23 00:51:56 -0500 (Thu, 23 Jan 2003) | 3 lines 3191 3192Just adding some notes, and preparing to add the next sts test, 3193TOMORROW. 3194 3195------------------------------------------------------------------------ 3196r32 | rgb | 2003-01-22 23:52:47 -0500 (Wed, 22 Jan 2003) | 2 lines 3197 3198I have no idea why the tag went down into fitany... 3199 3200------------------------------------------------------------------------ 3201r30 | rgb | 2003-01-22 23:52:07 -0500 (Wed, 22 Jan 2003) | 14 lines 3202 3203This ups the minor revision number to 0.3.0. Worthwhile because now I 3204have BOTH an erfc AND a Q evaluation of p-value. I could certainly 3205prettify sts_monobit, but since I generally think that it isn't that 3206great a test (although it does indicate how starkly many rng's FAIL to 3207be even this random) I won't do so right away. 3208 3209Next (after tagging and resync'ing) is going to be adding more tests. 3210At this point adding a test should be pretty easy, given the hopefully 3211reusable routines I have written to do the pre- and post- processing. 3212All I really have to do is input the expected values, write a loop to 3213generate the "experimental" statistic, and pass everything on to a 3214standard set of tools for outputting the results and deciding on the 3215quality of the results. 3216 3217------------------------------------------------------------------------ 3218r29 | rgb | 2003-01-22 23:46:08 -0500 (Wed, 22 Jan 2003) | 7 lines 3219 3220All right, this LOOKS like it correctly implements the STS monobit 3221frequency test. I would still claim that anything that fails this test 3222will also fail the binomial test, and that in addition things that pass it 3223(e.g. the vax rng) FAIL the binomial test, so the monobit test is 3224a waste of time and more prone to error. However, mine is not to reason 3225why... 3226 3227------------------------------------------------------------------------ 3228r28 | rgb | 2003-01-22 13:04:47 -0500 (Wed, 22 Jan 2003) | 7 lines 3229 3230This is working incredibly well, and I've split off nearly everything 3231required to make further n-point chisq tests trivial to implement and 3232assess. All that remains is to do a 1-point (normal) test such as the 3233sts_monobit test (which should really be done internal to the 3234rgb_binomial test and may one day be, but for the moment we'll just do 3235it directly). 3236 3237------------------------------------------------------------------------ 3238r27 | rgb | 2003-01-22 08:33:21 -0500 (Wed, 22 Jan 2003) | 2 lines 3239 3240Just making SURE this is at Duke... 3241 3242------------------------------------------------------------------------ 3243r26 | rgb | 2003-01-21 18:56:15 -0500 (Tue, 21 Jan 2003) | 18 lines 3244 3245This works just lovely! 3246 3247HOWEVER, it is also clear that running it once, twice, three times, 3248for EACH generator looking for good ones is a PITA. We'll have to 3249eventually rearrange this so that there is a "search mode" that runs 3250a loop through all known generators, identifying the ones that pass at 3251least at the 1% or higher level. 3252 3253BTW, I'm now prepared to bet a nickel that the rgb binomial test has a 3254great deal of sensitivity, since it fails all but literally three or 3255four of the available RNG's for absurdly short data strings. As in they 3256aren't even APPROXIMATELY random...NONE of them. If one used them to 3257generate a humble binomial distribution numerically it would be in 3258significant error. 3259 3260I do need to alter this test so that I can run it for arbitrary bit 3261string lengths, but for the moment I'm not going to worry about it. 3262 3263------------------------------------------------------------------------ 3264r25 | rgb | 2003-01-21 16:40:07 -0500 (Tue, 21 Jan 2003) | 3 lines 3265 3266This is now VERY CLOSE. I should be able to determine chisq in a matter 3267of minutes when I return... 3268 3269------------------------------------------------------------------------ 3270r24 | rgb | 2003-01-21 14:05:50 -0500 (Tue, 21 Jan 2003) | 2 lines 3271 3272This is considerably cleaner and more decrufted... 3273 3274------------------------------------------------------------------------ 3275r23 | rgb | 2003-01-21 13:35:01 -0500 (Tue, 21 Jan 2003) | 3 lines 3276 3277This finishes the split off of list_rand and list_rngs from the code. 3278I do need to "fix" the Usage() routine to reflect the change. 3279 3280------------------------------------------------------------------------ 3281r22 | rgb | 2003-01-21 13:08:34 -0500 (Tue, 21 Jan 2003) | 3 lines 3282 3283Breaking things up into subroutines a bit better to clarify the program 3284structure. 3285 3286------------------------------------------------------------------------ 3287r21 | rgb | 2003-01-17 15:37:14 -0500 (Fri, 17 Jan 2003) | 7 lines 3288 3289This is coming along, although I'm silly for not just finishing the 3290monobit test before introducing a binomial test. Still, all very 3291instructive. 3292 3293I need to get all this on my laptop and take it with me, along with the 3294notebook. 3295 3296------------------------------------------------------------------------ 3297r20 | rgb | 2003-01-17 14:28:36 -0500 (Fri, 17 Jan 2003) | 10 lines 3298 3299Fixes a nasty bug in sts_monobit, which I think I'm gonna rename 3300rgb_binomial (and screw sts's monobit test, which is immensely sloppy 3301compared to actually systematically exploring the binomial distribution 3302of 1's and 0's in the overall bit strings generated by different seeds. 3303 3304Actually, a better thing still is to leave sts_monobit, but add 3305rgb_binomial and document that it is more sensitive (in particular, that 3306e.g. alternating series that easily pass monobit fail binomial, and that 3307NOTHING that fails monobit will PASS binomial). 3308 3309------------------------------------------------------------------------ 3310r19 | rgb | 2003-01-17 01:06:32 -0500 (Fri, 17 Jan 2003) | 2 lines 3311 3312Sending off the tag 3313 3314------------------------------------------------------------------------ 3315r17 | rgb | 2003-01-17 01:06:16 -0500 (Fri, 17 Jan 2003) | 8 lines 3316 3317OK, this is good for a full minor number bump to 0.2.0. We have 3318basically installed the guts of the STS monobit test. All that we 3319lack is the computation of the statistics and p-value, which should be 3320fairly straightforward, especially with the gsl handy. I SHOULD be 3321able to just cumulate the one-count (e.g.) in a vector and hand it to 3322the gsl stats routines and have mean, stddev, skew, kurtosis, and 3323anything else I might like just handed back to me... 3324 3325------------------------------------------------------------------------ 3326r16 | rgb | 2003-01-17 00:16:59 -0500 (Fri, 17 Jan 2003) | 4 lines 3327 3328Just a bit of cleanup, and some moderately important additions. 3329 3330Now we REALLY need to think about tests. 3331 3332------------------------------------------------------------------------ 3333r15 | rgb | 2003-01-16 23:23:32 -0500 (Thu, 16 Jan 2003) | 2 lines 3334 3335Tagged. 3336 3337------------------------------------------------------------------------ 3338r13 | rgb | 2003-01-16 23:23:04 -0500 (Thu, 16 Jan 2003) | 7 lines 3339 3340This is about ready for a semipermanent snapshot, so I bumped the 3341minor version number. I'd say that we are now "good" with the ability 3342to add sw rng's, including interfaces to hw rng's square within the gsl 3343format. 3344 3345Now to give de old tests a try... 3346 3347------------------------------------------------------------------------ 3348r12 | rgb | 2003-01-16 22:54:25 -0500 (Thu, 16 Jan 2003) | 6 lines 3349 3350Hot diggity dawg! It works! However, I don't need types.c. All I 3351need is to follow the dev_random.c template and call a routine 3352add_my_rngs() (to be defined) before working with gsl's rng's, and 3353keep track (crudely) of which ones are which. So this can be decrufted 3354a bit and then reorganized now that I know how it works. 3355 3356------------------------------------------------------------------------ 3357r11 | rgb | 2003-01-16 21:54:49 -0500 (Thu, 16 Jan 2003) | 4 lines 3358 3359We'll try these as the basic wrappers required. With luck we'll 3360override the types subroutine in gsl itself, although I do have my 3361doubts... 3362 3363------------------------------------------------------------------------ 3364r10 | rgb | 2003-01-16 21:38:52 -0500 (Thu, 16 Jan 2003) | 6 lines 3365 3366This significantly improves the Usage and cl parsing, and pre-structures 3367it for addition of sts/diehard tests. 3368 3369We still need to see if we can gsl-wrap our own tests without a full 3370gsl recompile. 3371 3372------------------------------------------------------------------------ 3373r9 | rgb | 2003-01-16 15:40:56 -0500 (Thu, 16 Jan 2003) | 2 lines 3374 3375Sending the tagged copy home... 3376 3377------------------------------------------------------------------------ 3378r7 | rgb | 2003-01-16 15:40:38 -0500 (Thu, 16 Jan 2003) | 2 lines 3379 3380This is now going to be v_0_1_0. 3381 3382------------------------------------------------------------------------ 3383r6 | rgb | 2003-01-16 15:39:55 -0500 (Thu, 16 Jan 2003) | 15 lines 3384 3385This is now functional UP TO all the gsl rngs, not any of the add-ons. 3386 3387Which is fine, as we'll probably completely change how the add-ons work. 3388 3389Next, we need to do all of the following, in some order: 3390 3391 a) figure out how to wrap up new gsl_rngs, preferrably without 3392recompiling the whole damn library. 3393 b) decruft all the command line options and no-longer-used variables. 3394 c) add back command line options for doing quality tests. Start with 3395the very simplest test -- something from diehard or the bits test from 3396sts. 3397 d) In the meantime, increment revision, tag, and consider "publishing" 3398as we go. 3399 3400------------------------------------------------------------------------ 3401r5 | rgb | 2003-01-16 15:14:54 -0500 (Thu, 16 Jan 2003) | 3 lines 3402 3403This SHOULD split rand_rate off so it has its own CVS tree outside of 3404the "random" project overall, which I think is for the best. 3405 3406------------------------------------------------------------------------ 3407r4 | rgb | 2003-01-16 15:13:05 -0500 (Thu, 16 Jan 2003) | 4 lines 3408 3409This actually works, and needs to be saved in snapshot form. I'm not 3410at ALL certain that I'm getting accurate measurements in terms of the 3411number of rands per second I can generate, but this too, we shall see... 3412 3413------------------------------------------------------------------------ 3414r3 | rgb | 2003-01-13 17:12:27 -0500 (Mon, 13 Jan 2003) | 2 lines 3415 3416This is a fair amount of progress to having something working... 3417 3418------------------------------------------------------------------------ 3419r2 | rgb | 2003-01-11 19:07:56 -0500 (Sat, 11 Jan 2003) | 4 lines 3420 3421This is basically the original checkin for my lookin-major random number 3422project. By the time this is done, I'd doggone better have a paper or 3423two out of it, if not more. 3424 3425------------------------------------------------------------------------ 3426