Template talk:Random portal component

This is the talk page for discussing improvements to the Random portal component template.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Max?[edit]

Must the "max" variable be included? - Tim1965 02:42, 9 May 2007 (UTC)[reply]

The computer needs to pick a random integer from 1 to max. The computer wouldn't know what to do if max is unknown.

Seed?[edit]

What does the "seed" variable actually do? I'm hoping it creates a faux-randomization (e.g., if "seed=3", then the portal will feature every third sub-sub-page).- Tim1965 02:42, 9 May 2007 (UTC)[reply]

It's not how it works. See pseudorandomness, random seed, and pseudorandom number generator. I don't understand them myself. You only need to worry about it when there are two or more components in your portal with the same number of subpages. In this case, just specify different seed numbers for the components. Regardless, each and all subpages have equal chance. --ChoChoPK (球球PK) (talk | contrib) 08:20, 9 May 2007 (UTC)[reply]

Description[edit]

How about a description of what this template actually does? Samuel Grant 17:08, 7 August 2007 (UTC)[reply]

Done. --ChoChoPK (球球PK) (talk | contrib) 08:49, 13 August 2007 (UTC)[reply]

Thanks! Samuel Grant 15:57, 13 August 2007 (UTC)[reply]

Max max?[edit]

Is there a maximum number for the max value? Can the random component randomize and cycle through, say, 100 or more entries? Cirt (talk) 20:48, 6 December 2007 (UTC).[reply]

As far as I know, there's no maximum. I'm not aware of anyone that's used a hundred entries; but, for example, Portal:War uses 60 with no problems. Kirill 02:37, 7 December 2007 (UTC)[reply]

Neat, thanks. Cirt (talk) 03:34, 7 December 2007 (UTC).[reply]

Portal:Philately[edit]

I am trying this out on "Stamp of the month" section of the Portal:Philately, for which I will soon have 12 articles setup (currently 9 are done) but have no idea who often the randomisation changes the article. I understand the article choice is made randomly but what is the delay between changes? Maybe it is determined by the number of articles to choose from, I just don't know. Thanks ww2censor (talk) 15:14, 31 December 2007 (UTC)[reply]

The selection is refreshed every time the page cache is cleared on the server, which is entirely random and unpredictable. Kirill 17:05, 31 December 2007 (UTC)[reply]

Thanks Kirill. You must be the portal answer guy. Cheers ww2censor (talk) 17:20, 31 December 2007 (UTC)[reply]

Kirill I know you said the refresh is entirely random but have you any idea when it might refresh as I have ben watching my new section now for about 2 weeks but see no action. Do I just need more patience? ww2censor (talk) 20:59, 8 January 2008 (UTC)[reply]

I changed the max setting. It should be the same number as you have in the archive. I would also suggest using a <div style="text-align:center; margin:-7px; padding-bottom:12px;">{{purge|'''Show new selections'''}} </div> button for easier refreashing, otherwise the purge server cache button is used for that. Joe I 05:23, 9 January 2008 (UTC)[reply]

Sorry for the stupid questions but, do you mean the number should be equal to the number of articles available to be randomly changed? Did you set the number to 4 because I did not yet have a full complement of 12 sub-pages but when I have filled in 5, 6 & 7, I could change the number to 12? After your edit I noticed that at first #3 article showed up but when I refreshed the portal main page #2 was displayed. Concerning the purge, do you mean that piece of code should be included in every individual archive page or on the main page? TIA Cheers ww2censor (talk) 05:35, 9 January 2008 (UTC)[reply]

I'll answer your questions in order:

do you mean the number should be equal to the number of articles available to be randomly changed? Did you set the number to 4 because I did not yet have a full complement of 12 sub-pages — Yes, the max number should be set to the maximum number of subpages ready to be shown. Since subpages 5, 6, and 7 weren't created yet, Joe I didn't set the max to 12, or something like Portal:Philately/Stamp of the month archive/5, for example, would show up on the main page.
when I have filled in 5, 6 & 7, I could change the number to 12? — Yes.
After your edit I noticed that at first #3 article showed up but when I refreshed the portal main page #2 was displayed. — That's the beauty of randomness. :)
Concerning the purge, do you mean that piece of code should be included in every individual archive page or on the main page? — Just on the main page. For an example, see the featured Numismatics Portal.

Happy editing, [sd] 03:44, 10 January 2008 (UTC)[reply]

(deindent) Thanks for the really clear and precise answers. Both sections are working now and I will add another random biographical section later on. Thanks again SD. Cheers ww2censor (talk) 15:13, 10 January 2008 (UTC)[reply]

Kirill Lokshin I have read everything in here, we are new to the random portal component thing on CKB, but I changed the max settings and everything but still won't work, I have purged, reloaded the page multiple times now, but still won't work. I use it on the Art's Portal, the selected picture contains 7 subpages, I have also set the max number to 7 in the article still no use. the programming is in English so I'd appreciate if you take a look, or give an advice at least.—‎Lost Whispers _talk 21:09, 29 December 2016 (UTC)[reply]

Counting from 1 or from 0?[edit]

In the past week or so, I have noticed this template returning subpage 0 (e.g. Portal:Wales/Selected article/0 at Portal:Wales), even though the documentation says it should return a value between 1 and max (inclusive). Has something changed somewhere? By my understanding of the template code, a return of 0 should be impossible (because of the "+1"), but I've seen it happen three times on two different portals. Does anyone know what's going on? --Stemonitis (talk) 15:34, 4 October 2011 (UTC)[reply]

Update: After some experimentation, I can confirm that {{Random number}} is returning -1 relatively often, but I'm still none the wiser as to why that should be. It uses {{Mod}}, which should only return a negative number if the denominator (in this case, max) is negative, but different instances using the same max produce returns of different signs. I think this must be a bug, but I can't quite work out where. --Stemonitis (talk) 20:17, 5 October 2011 (UTC)[reply]

I've traced it down a few levels. In one case where {{Random portal component}} returned zero, the calculation inside {{Random number}} was trying to evaluate

{{mod | (((1318326413+( 4 ))*(67)+3763704)*(67)+15473267)*(67)+831438 | 27 }}

and the answer is currently -1. That shouldn't be minus one, so there is a bug in {{Mod}}. -- John of Reading (talk) 09:55, 11 October 2011 (UTC)[reply]

(still thinking) ... or we could rewrite {{Random number}} to use the low 16 bits of NUMBEROFARTICLES, etc, so that it never calls Mod with such a large parameter. -- John of Reading (talk) 10:39, 11 October 2011 (UTC)[reply]

[EC] Ah yes, it looks like when the first parameter to {{mod}} is too large, there aren't enough significant figures to hold the stuff after the decimal point. When that gets thrown away, the wrong answer is returned.

input	{{ mod \| input \| 27 }}	{{ #expr: (input / 27) - 0.5) }}	{{ #expr: input-floor(input/27)*27 }}
2.70E⁺¹⁰ + 26	26	1000000000.463	26
1.35E⁺¹⁴ + 26	26	5000000000000.5	26
2.70E⁺¹⁴ + 26	-1	10000000000000	26
5.40E⁺¹⁴ + 26	-1	20000000000000	26
8.10E⁺¹⁴ + 26	-1	30000000000000	26
1.08E⁺¹⁵ + 26	-1	40000000000000	26
2.16E⁺¹⁵ + 26	-1	80000000000000	26
2.16E⁺¹⁶ + 26	24	8.0E+14	24
2.16E⁺¹⁷ + 26	0	8.0E+15	0
27E⁺⁹⁹ + 26	0	1.0E+99	0

So, what's the solution? Should we use something other than #time, {{NUMBEROFFILES}}, {{NUMBEROFUSERS}} and {{NUMBEROFARTICLES}}? Would putting them in a different order help? #time is on the order of 1.3 x 10⁹, much larger than any of the others, and it is multiplied by 67 three times during the course of the calculations. I suspect that if we swapped #time and {{NUMBEROFFILES}}, the problem would go away (at least for a while). --Stemonitis (talk) 11:02, 11 October 2011 (UTC)[reply]

The result is going to change once every second anyway, thanks to #time:U, so how about simplifying the big expression down to ( #time:U + (seed * prime) )? That will stay well within 32 bits so the arithmetic should be accurate. -- John of Reading (talk) 11:24, 11 October 2011 (UTC)[reply]

If that would be acceptable mathematically, then I'd be perfectly happy with it. There's a version in User:Stemonitis/Testing ground which seems to give acceptable output, but if a simpler version works just as well, then so much the better. --Stemonitis (talk) 11:28, 11 October 2011 (UTC)[reply]

The requirement that "Varying prime ... generates pseudo-random that have independent random distribution" means that the result has to depend on "prime" in at least two different ways. After some failed attempts, my proposed new template is in User:John of Reading/X1. User:John of Reading/X2 is a copy of the documentation page, modified to use my "X1", and with a "purge" link so you can try it out a few times. -- John of Reading (talk) 12:51, 11 October 2011 (UTC)[reply]

Looks good to me. I see no reason not to make those changes to the live template straight away. --Stemonitis (talk) 13:01, 11 October 2011 (UTC)[reply]

Over to you then, it's a fully protected template. -- John of Reading (talk) 13:09, 11 October 2011 (UTC)[reply]

Oh yes. Done. It shouldn't cause any problems, but I will gladly revert if we've overlooked something. --Stemonitis (talk) 13:13, 11 October 2011 (UTC)[reply]

Initially it was written this way because we only had the mod operator which operates incorrectly. the Mod template fixed that for most cases (with lots of tricks to get the correct result!), but it is still deficient in borderline cases (you've hit the case because now numbers are becoming too large to fit in 32 bit integers supported in operands of the old mod operator of #expr; the templte used instead "round 0" which requires substracting 0.5 first for emulating floor, but it is tricky s you need to test signs and values between -0.5 and +0.5). It should be corrected using simpler version of the Mod template based on the floor function instead of the old mod operator that has always caused troubles (notably when computing/converting calendar values depending on cyclic modular arithmetic), Template:mod should use floor now as in the table above (it does not require any #if or tricky use of round 0' with its own additional bugs).

Note that the current fix is incorrect as it now uses the mod operator explicitly : two modulos are computed, one for the result range by template:mod, but another incorrect using the prime value (completely wrong! you highly reduce the number of possible output values. It works superficially but the result is now far from being random : if the prime is 17, you get only 17 possible output values in the requested output range. You don't understand basic arithmetic.) The inner "mod" should be clearly removed. I can rewrite it withut using template:Mod internally (I'll use floor, it will be more efficient: see the table above, in case of precision overflow, it returns 0 correctly in the expected ouput range). verdy_p (talk) 00:48, 22 October 2013 (UTC)[reply]