List Commands Library for 50g

[pier4r]

So results crunched in the night
:AttempsLSHUF: { 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. 4096. } plus 4096 as additional iteration

:AttempsRAND: { 1329. 1112. 1568. 4096. 4096. 2121. 486. 4096. 4096. 2326. 4096. 1711. 203. 4096. 4096. 39. 1288. 1991. 4096. 1811. } plus 4096 as additional iteration.

(03-18-2018 02:35 AM)DavidM Wrote:  I then changed the "list of elements" (in both places) by adding a value of 50 to make it now have 5 elements, and changed the number before RAND in the "produce a list of N picks of elements that is the goal list" to 5 so that it would include all 5 elements in its picks. I left the length of the goal at 6. This time, both methods went "to the wall" at 15625 attempts. So neither method seemed to produce the targeted list. Did I neglect to change something appropriately? Granted, this was only 1 loop iteration so it may not be as meaningful.

No I believe you did exactly what was needed (sorry, lazy to put variables to avoid several changes at once. I'll do it later on, maybe). Also as you can see from the 4096, sometimes also RAND goes to the wall. The search is not that good.

Although this spawn an interesting problem. Knowing nothing about the "goal" to find, and assuming one cannot change the order of elements because they are needed, how can the search be improved? The best that I can see for the moment is: consume all the possibilities, just going hopping randomly around. Although if I am not wrong I did a test between sequential search and random search, and the random search was poorer. I may need to do it again as I don't remember if I removed the possibilities checked.
Also a random search requires to keep track of which possibilities were checked already, so the space requirement grows, and it may cost more than the speed requirement.

Quote:The choice I made wasn't specifically related to using the rightmost digits, but rather using a method that employed integer operations as opposed to floating point math.

Understood, well but at least you (re?)discovered, for you and those you never observe the property, how the LCG random generator behave with rightmost digits. I'd say: not bad!

Quote:So the question remains: does shifting the seed give enough improvement to continue using this method, or should some other method be deployed?

As far as I know, either one finds a solid theoretical hint to decide or, time for some tests? (plus here).

The 50g is not doing much anyway most of the time, so can be employed for science! (well, my understanding of science at least) That is quite a good employment. Sure it will take a while, as I employ mostly the real device and to get data one either employs a clever test, or a lot of iterations are needed.