I am looking at https://www.jsoftware.com/help/dictionary/d640.htm and vrand.c and https://code.jsoftware.com/wiki/Vocabulary/query and I'm trying to think how I should fit the libgmp Mersenne Twister implementation into this scheme of things.
The libgmp side of things is documented at https://gmplib.org/manual/Integer-Random-Numbers and the state initialization part is documented at https://gmplib.org/manual/Random-State-Initialization Meanwhile, the default J random state is a list of three boxes. Here, the first two are rank 0 integers and the third is a list of 312 integers. On the other hand, the libgmp random state is a single "extended integer" (and a list of function pointers). That said, inspecting the actual values, libgmp plays fast and loose with its own rules for the value of that extended integer. (After it's initialized it's apparently a chunk of memory, 313 bytes long, which happens to have the numeric value 0.) So... for now, I'm thinking I should retract my use of the libgmp mpz_urandomm() mechanism. It seems like a sealed box which won't play well with J's random state mechanisms. (It doesn't even play particularly well with the documented libgmp interface for extended integers.) I don't see this retraction as having any particularly significant cost for us. FYI, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
