Talk:Pseudo-random numbers/PCG32: Difference between revisions

m
no edit summary
mNo edit summary
 
(17 intermediate revisions by 6 users not shown)
Line 18:
==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 [http://www.rosettacode.org/wiki/[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!!!--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk: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--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk: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. --[[User:Paddy3118|Paddy3118]] ([[User talk: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.--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk: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). --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 20:04, 13 August 2020 (UTC)
Line 33 ⟶ 34:
:::Hard to argue with someone who can't count the lines of code shown, and equates their code with something from the standard library. --[[User:Paddy3118|Paddy3118]] ([[User talk: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 :-) [[User:Hout|Hout]] ([[User talk: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. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|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 :-) [[User:Hout|Hout]] ([[User talk: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. --[[User:Paddy3118|Paddy3118]] ([[User talk: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. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 06:57, 16 August 2020 (UTC)
 
== Help needed ==
 
I am trying to translate the JAVA Program to REXX.
 
Can anyone explain this stone in my way (the different values of t5)?
 
These are a few lines of a JAVA program
<pre>
long t1=(shiftedx >>> rotx); System.out.printf("%nt1=%d",t1);
int t2=(~rotx); System.out.printf("%nt2=%d",t2);
int t3=(t2+1); System.out.printf("%nt3=%d",t3);
int t4=(t3 & 31); System.out.printf("%nt4=%d",t4);
System.out.printf("%nshiftedx=%d",shiftedx);
System.out.printf("%nlong t5=(shiftedx << t4);");
long t5=(shiftedx << t4); System.out.printf("%nt5=%d",t5);
long t7=(t1|t5); System.out.printf("%nt7=%d",t7);
int t8=(int) t7; System.out.printf("%nt8=%d",t8);
 
running this program shows this in the output:
 
t4=20
shiftedx=-293022013
long t5=(shiftedx << t4);
t5=1815085056
 
When I try this in a small program,
 
long n=-293022013;
int s=20;
long t5=(n<<s);
System.out.printf("%nn=%d",n);
System.out.printf("%nt5=%d",t5);
I get
n=-293022013
t5=-307255850303488
</pre>
--Walter Pachl 08:22, 27 February 2021 (UTC)
 
::64 bit, n <<s is the bigger number. Try masking to 32-bit such as: (n << s ) & 0xffffffff to keep things 32-bit. --[[User:Wherrera|Wherrera]] ([[User talk:Wherrera|talk]]) 08:37, 27 February 2021 (UTC)
 
:: but there's no masking in the original pprogram --Walter Pachl 09:14, 27 February 2021 (UTC)
 
:: In some languages a long is 32 bits and a long long is 64 bits, so in those making it a long masks it to 32 bits. --[[User:Wherrera|Wherrera]] ([[User talk:Wherrera|talk]]) 17:24, 27 February 2021 (UTC)
 
:::I am only talking and trying to understand Java. long is 64 bits.
 
Can anyone explain on bit level how this result comes about?
<pre>
public class how {
public static void main(String[] args) {
long old=0xCEC0317BC206D20CL;
System.out.printf("%nold=%d",old);
int shifted = (int) (((old >>> 18) ^ old) >>> 27);
System.out.printf("%nshifted=%d",shifted);
}
}
old=-3548782098761985524
shifted=-671065735 ??????????????
</pre>
doing the shif1t 18, the and, and the shift 27 gives me 402944 -:(
 
and was wrong!
 
oops. my fault. I do get -671065735 if I use xor instead of the and!!!!
 
I do hope the end is nigh!
 
--Walter Pachl 20:37, 27 February 2021 (UTC)
 
I just tested this in Java 8 (1.8) and the behavior you got only happens with two ints, and the larger number happens if either is a long. --[[User:Wherrera|Wherrera]] ([[User talk:Wherrera|talk]]) 23:42, 27 February 2021 (UTC)
4,102

edits