Talk:Pseudo-random numbers/PCG32
seed_sequence is completely unused
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)
- ... 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?
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
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 [1] 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)
- (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)