Skip to content

Releases: tommyettinger/juniper

0.5.0 "The Only Card I Need"

09 Dec 08:20
Compare
Choose a tag to compare

This release fixes some omissions in Deserializer, but most importantly changes the "default" generator used by distributions to AceRandom instead of WhiskerRandom. AceRandom doesn't have the correlation issues that WhiskerRandom does after just a few generations (32 should be more than enough for Ace, but Whisker never decorrelates), it has a longer expected period and actually has a guaranteed minimum period (2 to the 64). It's also about the same speed as WhiskerRandom, though likely a tiny bit slower if only generating longs with nextLong().

The previous release didn't get a GitHub release, so I'll include some notes for it too. FlowRandom is new; it isn't especially fast, but it does what LaserRandom and MizuchiRandom really struggle with: It has two long states, a period of 2 to the 64, and 2 to the 64 streams, with the ones tested all apparently decorrelated enough to pass a tough test. LaserRandom has half as many streams and they are all highly correlated; MizuchiRandom isn't terribly fast and also has half as many valid streams, though they aren't correlated if you skip invalid streams. LineWobble had some GWT compatibility issues, which are fixed now. It also has new wobbling functions added, such as trobble(), a trigonometric wobble that takes advantage of the tables in digital's TrigTools.

OK, I hope this works for everyone!

0.4.2 "ATA: All The Acronyms"

08 Nov 03:41
Compare
Choose a tag to compare

A main new feature here is the inclusion of three generators someone else initially wrote: Sfc64Random, Jsf32Random, and Crand64Random. SFC is by Chris Doty-Humphrey and was released as part of his PractRand test suite. JSF32 is an older generator that still passes tests today; it was written by Bob Jenkins. Crand64 is by Tyge Løvset and was released as part of STC. Also new is Respite32Random; it's still a work in progress at this point, but it's a good option if correlations between initial states aren't a concern. Respite32Random's correlation issues aren't quite as severe as those in Xoshiro128PlusPlusRandom, but Xoshiro128PlusPlusRandom has a longer period. Oh yeah, and there's also PouchRandom, which I wrote; it's similar to SFC64 but has half the minimum guaranteed period (down to 2 to the 63, or 9 quintillion, or "almost certainly enough for a game") and has some minor seed constraints. Why would you want PouchRandom? It's the fastest generator here that passes PractRand and ReMort testing, faster even than WhiskerRandom; it also doesn't have correlations between similar initial states for very long.

This release also updates digital to the latest release, 0.4.3, which is important because the previous release, 0.4.2 (and maybe some other releases before it), wouldn't compile on GWT if a GWT app depended on digital.

Enjoy your random numbers!

0.3.9 "Time Flies"

05 Sep 06:29
Compare
Choose a tag to compare

Whoops, I forgot to make a GitHub release for versions 0.3.3 through 0.3.8 . They're all on Maven Central, though! This one should probably be preferred of the group, but it's up to you. See the CHANGES for the full details as far as I can remember them. The main thing to note is that this depends on digital 0.4.0 now, instead of some digital version before 0.3.3 in the last GitHub release. Other changes are mostly small; there are a few new generators, like Xoshiro256MX3Random and InterpolatedRandom, and some smallish breaking changes, like the output of Ziggurat changing in some rare cases (I had implemented one line of the algorithm incorrectly). There are leap() methods on several generators to jump very far ahead in a sequence (potentially to another subsequence, but with a guaranteed minimum distance). LineWobble has had many improvements made, for 1D noise. That's about it!

0.3.2 "No Two For You"

23 May 02:15
Compare
Choose a tag to compare

This release on GitHub skips past... all of the 0.2.x releases published to Maven Central only. So, covering all the changes would be a challenge. The main thing here is that 0.3.1 and 0.3.2 are bugfix releases, and 0.3.2 should always be preferred over 0.3.1 and probably 0.3.0 (some behavior changed since 0.3.0, but only the setSeed() methods for AceRandom and ScruffRandom, and the results of TupleQuasiRandom). There's lots of new features relative to the last release on GitHub, 0.1.9, like the additions of LongSequence, ArchivalWrapper, and KnownSequenceRandom, which all work together to allow storing sequences of generated longs and replaying results. There's ReverseWrapper, which changes the state in reverse, and can be used to undo shuffles, for instance. The new ScruffRandom class is quite good, and is almost as fast as WhiskerRandom while offering a minimum period guarantee of 2 to the 64 calls to nextLong().

Well, there's probably more, but you'll find it!

0.1.9 "Now More Normal"

05 Feb 04:39
Compare
Choose a tag to compare

This release changes the GWT inherits to ones that reliably work (this actually happened in 0.1.8), and improves the quality/range of normal-distributed values produced by Ziggurat. There was a subtle "jog" in the graph of normal-distributed values in 0.1.8 and some earlier versions, where in the "trail" of the most extreme-magnitude values, the start of the trail had a cluster of unusually-frequent values and then suddenly dropped back to normal. There was also some sort of bias in how high-magnitude Ziggurat could produce positive numbers compared to negative ones, and positive values were able to be higher. Now both positive and negative numbers can have higher magnitudes than before (a sign that it's approximating the trail better), and the "jog" is gone. Ziggurat probably isn't quite as fast now when the problematic cases occur (less than 0.4% of the time), but the rest of the time, it should be comparable.

See the README.md for the different GWT instructions.

0.1.7 "Everywhere A Sign"

11 Dec 03:40
Compare
Choose a tag to compare

This release adds a new EnhancedRandom (AceRandom) and adds or changes a few methods in EnhancedRandom and Ziggurat. Ziggurat produces different results given the same seed in this version, relative to the last version, which affects Gaussian-distributed variables and anything that uses a normal distribution. The same is true for nextInclusiveFloat() and nextInclusiveDouble(), which should be faster now due to using an algorithm closer to nextExclusiveFloat()/nextExclusiveDouble(). There's the new nextExclusiveSignedFloat() and nextExclusiveSignedDouble() methods, which act like their non-signed counterparts but can produce floating-point numbers from -1 to 0, both exclusive, and from 0 to 1, both exclusive. VanDerCorputQuasiRandom receieved an important fix that allows it to be deserialized, also.

0.1.6 "Stepping Out Into The World"

08 Oct 04:13
Compare
Choose a tag to compare

This set of release notes includes 0.1.5 too, since I never posted a release for that on GitHub (it is still on Maven Central). There's a fair amount of new stuff here as a result: PasarRandom is a 320-bit PRNG, two new quasi-random number generators (QRNGs), the Arcsine distribution, leap() methods in several classes to jump ahead a fixed number of generations, and a switch to using the Ziggurat method for generating normal-distributed values. The dependency on digital is now 0.1.4 .

0.1.4 "Couch Lounging"

09 Sep 04:21
Compare
Choose a tag to compare

This release primarily exists to fix CauchyDistribution and LogCauchyDistribution by updating the dependency on digital, but it also adds the new LumpDistribution. Updating digital improves our TrigTools.tan() method (and tanTurns(), which we use), so there isn't a clear artifact in the results. LumpDistribution has reasonably adjustable high-to-low bias and extreme-to-central bias, and it could be useful in a variety of places, but I don't know how to calculate its mean, median, mode, or variance. Help on this would be welcome!

0.1.3 "Wobbly Puppy Paws"

29 Aug 03:50
Compare
Choose a tag to compare

This release mostly exists to fix the copy() methods on each Distribution class, because each returned a Distribution before instead of the actual type being copied. It also should improve the angle-based wobble methods in LineWobble, since some random numbers they used were too small in range. There's very little else here! Well, some improved docs in the README.md, I guess. This is mostly needed for the kryo-more serialization library I have in-progress; having correct copy() methods should help it a lot.

0.1.2 "Healing Belly Rubs"

16 Aug 06:21
Compare
Choose a tag to compare

This release is simply a set of small hotfixes for 0.1.1: DistributedRandom had an incorrect serialization method, and ZipfianDistribution allowed a skew of 1.0 (which resulted in a division by 0.0 and some messy results accordingly). The rest of the release is the same as 0.1.1, so here are its release notes repeated:

This release is smaller than 0.1.0, but includes two new distributions (ZipfianDistribution and LogCauchyDistribution), and the first class to actually use Distribution practically, DistributedRandom! DistributedRandom wraps an EnhancedRandom and a Distribution to make another EnhancedRandom that distributes its results in any of various ways. ZipfianDistribution was requested because it makes sense in many situations where smaller results are more frequent (like Pareto), but the result needs to be bounded (unlike Pareto). No one specifically requested LogCauchyDistribution, but it has a really unusually-shaped graph, so it could be good for toying with the expectations of players in a game.