I'm working on modernizing Rosetta Code's infrastructure. Starting with communications. Please accept this time-limited open invite to RC's Slack.. --Michael Mol (talk) 20:59, 30 May 2020 (UTC)

Talk:Pseudo-random numbers/PCG32

From Rosetta Code

seed_sequence is completely unused[edit]

I get the exact same output from the python code after removing all references to it. --Pete Lomax (talk) 00:53, 12 August 2020 (UTC)

Er, that's because it's wrong. Fixing...
--Paddy3118 (talk) 04:59, 12 August 2020 (UTC)
... Fixed.
self.inc in method seed should have updated from argument seed_sequence.
Thanks Pete :-)
--Paddy3118 (talk) 05:19, 12 August 2020 (UTC)

Inappropriate masks?[edit]

Python does not have an unsigned 64 bit integer type or an unsigned 32 bit integer type. It has an integer type whose size varies to accept its operators, and where appropriate, leading zeroes are dropped.

Most of these bit-twizzling algorithms are originally written in languages like C that have these types. To duplicate the calculations, the Python example may use 32 bit and 64 bit mask values. anding a value with them will truncate that value to a maximum of 32/64 bits.

Fpr languages with these types, this would not be an idiomatic solution. Please use those types if they are a part of your language rather than follow the Python masking route, thanks. --Paddy3118 (talk) 11:00, 13 August 2020 (UTC)

The Pseudocode[edit]

Well it is'nt really is it? The purpose of pseudocode is to clearly explain the algorithm. It doesn't does it? Let me look at method seed. It starts by setting state to zero and inc to (seed_sequence << 1) | 1. It then calls next_int() which performs some calculating and returns a value which seed ignores. Strange but wait a sec next_int() has an undocumented side effect it changes the value of state to in this case to inc. seed now adds seed_state to state and calls next_int() again ignoring the return result. The side effect this time is to set state to inc*6364136223846793005+inc. Should not all this be replaced with satate<-((inc+seed_state)*6364136223846793005+inc ? see Van_Eck_sequence#Python:_Composition_of_pure_functions and many others for examples of coding in python without relying on side effects. Those who have copied this without thought should be ashamed of themselves!!!--Nigel Galloway (talk) 14:04, 13 August 2020 (UTC)

The link mentions this code: https://github.com/imneme/pcg-c-basic/blob/master/pcg_basic.c for the algoroithm which has these side effects.
As I expected, but is finding some badly written C code on the web, converting it without examination to something you call pseudocode the way to produce a good task. Unless you can explain why you (the C code) needs to call next_int I do not think this should be promoted from draft status. P>S> The C code does it is not a good explanation--Nigel Galloway (talk) 12:21, 14 August 2020 (UTC)
I've read your criticism, and note that although this is a wiki you refrain from writing the task or suggesting improvement. It would have been better if you made alterations to the pseudocode so others could judge. As for the quality of the C code, It's by the author of the algorithm with their own priorities. Your low effort criticism is viewed appropriately. --Paddy3118 (talk) 15:48, 14 August 2020 (UTC)
Okay I've modified the task. I thought I had indicated the changes when I wrote Should not all this be replaced with satate<-((inc+seed_state)*6364136223846793005+inc ? above (ok a bit of finger trouble with satate). Is all this just an attempt by you to avoid answering the question I posed about the first draft explain why you (the C code) needs to call next_int ? What the author of some C codes priorities are is unknown to me, they are not my priorities and should not be RC's priorities.--Nigel Galloway (talk) 16:25, 15 August 2020 (UTC)


(Ps, if this is an answer to my earlier section then it may need to be a sub-header). --Paddy3118 (talk) 20:04, 13 August 2020 (UTC)
I don't know. Are you trying to blame the C code for your incompetent implementation in Python? The C code is what it is and beyond my responsibility. It is your responsibility to turn it into a good task description enabling authors to produce good implementations, even in Python!--Nigel Galloway (talk) 12:21, 14 August 2020 (UTC)
(PPs That link points to verbose code over five times longer than the other Python solutions and in an un-idiomatic functional style). --Paddy3118 (talk) 20:13, 13 August 2020 (UTC)
You think so ? look more carefully: the declarative definition of Van Eck there is significantly more concise (7 lines of new code vs 11), a smaller number of moving parts, no side effects or mutations) than the slightly messy procedural recipe next to it, which you touchingly characterise as 'idiomatic'.
The declarative version also adheres to a long-established principle of productivity, ease of refactoring, and maintenance of quality Use library functions whenever feasible which is foregrounded by the classic work of Kernighan and Plauger :-) Hout (talk) 14:57, 14 August 2020 (UTC)
Hard to argue with someone who can't count the lines of code shown, and equates their code with something from the standard library. --Paddy3118 (talk) 16:13, 14 August 2020 (UTC)
I'll take that as a concession that 7 lines of new code is indeed shorter than 11 lines of new code, and that declarative definitions are indeed simpler than messy recipes, more or less scrupulously followed, but not always very reliable, or very deeply understood :-) Hout (talk) 16:29, 14 August 2020 (UTC)
I just have to say that I find Van_Eck_sequence#Python:_Composition_of_pure_functions completely unintelligible, plus it is about 500 times slower (100,000 in 45s) than Van_Eck_sequence#Python:_Using_a_dict (1,000,000 in under 1s). Of course I also have to say that Van_Eck_sequence#Phix can manage 10,000,000 in 0.5s. --Pete Lomax (talk) 09:57, 15 August 2020 (UTC)
Absolutely, that's the beauty of Rosetta Code - approaches diverge, and divergence generates additional drafts, and sheds additional light.
I have noticed, for example, that there are those who seem more or less convinced by run-time speed as a proxy for quality (even to the point of spending long and happy weekends building stripped-down drag-racer languages :-) My own approach is a bit less exciting – I value productivity and reliability, to the point of feeling more than a little ashamed if I waste any time all in optimising prematurely, or even slightly more than is required for the task in hand.
Different people understand, and value, different things. Functional composition does require a few more concepts than the Sequence, Branch, and Loop-Mutate of the other religion, but those few extra concepts are all well rewarded – not least in more productivity and much less debugging :-) Hout (talk) 00:15, 16 August 2020 (UTC)
Your personal style is not idiomatic Python. It is longer and less intelligible by the Python community, in fact, rejected by the community and the then BDFL, as well as not coming up for reconsideration. Idiomatic functional Python is not what you write. As you avoid stating. --Paddy3118 (talk) 03:54, 16 August 2020 (UTC)
Excellent ! It sounds like you have some additional variants to offer.
I am looking forward to reading them :-)
Writing an alternative draft is, of course, the only constructive use of these divergences. I might often feel puzzled by the sheer unreliability and stylistic incoherence of some variants touchingly announced to be 'idiomatic', but these things don't need to be said.
Variant drafts are much more useful and interesting Rosetta commentaries, and much more eloquent too. Hout (talk) 06:57, 16 August 2020 (UTC)