Talk:Pseudo-random numbers/PCG32: Difference between revisions
m
no edit summary
mNo edit summary |
|||
| (11 intermediate revisions by 4 users not shown) | |||
Line 37:
::::: 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)
| |||