środa, 6 stycznia 2021 o 13:10:02 UTC+1 fir napisał(a):
> poniedziałek, 4 stycznia 2021 o 13:28:40 UTC+1 o...@g...com napisał(a):
> > > > Chcę wiedzieć co tam jest robione
> > > Zajrzyj głębiej w źródła, by odszukać jak PCG zaimplementował swoje
> > > pcg_rotr_64().
> > Chyba jest już jasne. Autor w swojej publikacji pisze: rotate64(v,r) denotes an
unsigned 64-bit bitwise clockwise rotation
> > of r bits on v (i.e., v clockwise r ). Czyli na pewno jest to na bitach, a nie na
bajtach.
> lol, wiadomoz ze na bitach ale pytanie jest co ludzie rozumieja przez clockwize
skoro bity w powszechnym pojeciu nie tworzą chyab zbyt okreslonego kolka...kiedys
mowilo sie nie clockwize tylko w prawo
>
> - zeby takie prawo robilo clockwise to nawiasem mowiac bity musialybybyc numerowane
antyclockwise bo ta operacja to przesuwanie w tyl
>
> przyznam ze sam z tymi konwencjami mam pewne poroblemy bo niekoniecznie te rozne
konwencje orientacyjne sa chyba zawsze dobre w okreslonej sytuacji i jest tu do
wyboru chyba sporo opcji do wyboru

Faktycznie wciąż pozostawia to pole do pewnych wątpliwości. Znalazłem kod na stronie:

#if PCG_HAS_128BIT_OPS
inline pcg128_t pcg_output_xsl_rr_rr_128_128(pcg128_t state)
{
uint32_t rot1 = (uint32_t)(state >> 122u);
uint64_t high = (uint64_t)(state >> 64u);
uint64_t low = (uint64_t)state;
uint64_t xored = high ^ low;
uint64_t newlow = pcg_rotr_64(xored, rot1);
uint64_t newhigh = pcg_rotr_64(high, newlow & 63u);
return (((pcg128_t)newhigh) << 64u) | newlow;
}
#endif

To jest chyba numpy, a w numpy rotr, to rotacja w prawo.