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

m
no edit summary
mNo edit summary
mNo edit summary
 
(5 intermediate revisions by 2 users not shown)
Line 87:
--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