List Commands Library for 50g

[pier4r]

Quote:I was actually referring to this thread. But I still think RAND is OK for most purposes that people would want to use it for on a calculator. Not up to cryptographic standards, but OK for most other purposes.

Ok I forgot that thread, I even participated there. Thanks for the link.

What I get from that thread:
- suggestion about other random number generators (to use unless RAND is perceived as not good enough)
- a nice observation of ttw, that again it applies if one wants a extra good PRGN.
- Don't use the mantissa method of the two methods mentioned in the first post.
- Paul that says that RAND is somewhat biased. Taking it as truth, I still miss "how much" is biased, and if this bias is something that one should be concerned about for such applications (LSHUF doesn't have to encrypt any message). Surely RAND is not the best thing available, therefore it has bias. Look it is not even a real RNG, it is just a PRGN. But how much is it "bad"? Is it worse than the middle square method? Unlikely, and even that method is good enough for many applications. In other words for me "bad/biased" depends on the application.
- Interestingly, at least for what I understood, no one detected (or quantified) the "problem to be" in the sentence The converted RNSEED is then divided by the BINT passed as a parameter; the remainder of this division becomes the zero-based form of the result. as instead it is mentioned in https://groups.google.com/d/topic/comp.s...discussion (where JH Meyers mentioned the short cycle of the least significant bits)

Quote:The issue I'm currently facing with LSHUF is how to effectively convert the RAND seed into an appropriate integer in the range needed for LSHUF to use for a swap target. In the past, I used the <whole seed> MOD <value>, where <value> is one greater than the largest swap target range I needed. That has now been shown to be a faulty method (because it only uses the least significant digits of the seed, which is clearly ineffective). I've proposed a potential fix (XORing the upper part of the seed onto the lower part before performing the MOD), but I don't have any way to know if that method is actually any better. While it seems like it should be, guessing is not a viable option here. Unless I can somehow confirm that this method works better.

Some questions.

Do you want to confirm that the method based on XOR is better than the method based on MOD, right? As far as I understood it doesn't mean that the method based on XOR should be as good as the RAND or other methods, it should be only better than the method based on MOD. Is that correct? If so, wouldn't be possible to set a starting test - not the most rigorous test of the world, we are still talking about shuffling lists - that capture your idea of "better" ?

I'd like to point out that existing metrics are not "truth" spoken by God, they just capture, with proper data in a proper context, certain ideas or definitions or properties. So as far as the wanted property is somehow measured in a test, that's it. As I wrote, for me a starting test would be: I produce shuffles with RAND, I produce shuffles with the new routine. The I can: (a) measure how many times with RAND an element ended up in a certain position (so doing the distribution by position), and the same with the new routine; (b) I can compare how they match a given goal list (like my test does) and how is the statistics of the attempts; (c) One can even measure how much the elements were moved from the original position with RAND and the new routine; and some other metrics that makes sense if needed. I would start with (a) and (b). Then again I would do (a) and (b) also for the previous method, based on MOD. Then I would pick the method closer to the RAND results.


Moreover, as one in RPL would use listSize RAND * 1 + IP (or using CEIL), in effect picking the leftmost digits first. Couldn't you do the same somehow? I read in the other thread that you want to be fast, but if "fast" means "I don't like the command", wouldn't it be better to be slower retaining the command? At least for me it would be.

I am not sure how the RANDSEED is composed, yes JH Meyers explain it but I do not remember precisely now. I know it is an integer. Couldn't you get the upper part of this integer, say the first 5-6 digits and apply a mod to it? This should pick a larger period, closer to the userRPL statement above.

Anyway, if you feel uncomfortable with it, all this is not worth the stress (unless you want to discover things). Surely there is in this thread or the processing list thread (or somewhere else) a usable userRPL routine to shuffle lists to put in the uRPL library. In the worst case I use mine that was not that bad.