2021-01-03 o 07:07 -0800, o...@g...com napisał:
> Jaki będzie rezultat rotr16(15,2). Czy będzie to 1111, czy
> 110000000000000011?

rotr16() to nie C.

Jeśli pytanie dotyczy specyficznego Microsoftowego rozszerzenia, to
dokumentacja jest tutaj:
https://docs.microsoft.com/en-us/cpp/intrinsics/rotr
8-rotr16?view=msvc-160

Mateusz

do góry

niedziela, 3 stycznia 2021 o 18:24:30 UTC+1 Mateusz Viste napisał(a):
> 2021-01-03 o 07:07 -0800, o...@g...com napisał:
> > Jaki będzie rezultat rotr16(15,2). Czy będzie to 1111, czy
> > 110000000000000011?
> rotr16() to nie C.
>
> Jeśli pytanie dotyczy specyficznego Microsoftowego rozszerzenia, to
> dokumentacja jest tutaj:
> https://docs.microsoft.com/en-us/cpp/intrinsics/rotr
8-rotr16?view=msvc-160
>
> Mateusz

To dotyczy tej pracy:

https://www.pcg-random.org/pdf/hmc-cs-2014-0905.pdf

Tam są używane rotate64. Kod jednego z generatorów, który mnie interesuje wygląda
tak:

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;

Chcę wiedzieć co tam jest robione, żeby napisać taki rotate poprawnie w Pythonie. Ten
sam generator XSL-RR-RR jest też wymieniony tutaj:

https://en.wikipedia.org/wiki/Permuted_congruential_
generator

do góry

2021-01-03 o 13:29 -0800, o...@g...com napisał:
> niedziela, 3 stycznia 2021 o 18:24:30 UTC+1 Mateusz Viste napisał(a):
> > rotr16() to nie C.
> >
> > Jeśli pytanie dotyczy specyficznego Microsoftowego rozszerzenia, to
> > dokumentacja jest tutaj:
> > https://docs.microsoft.com/en-us/cpp/intrinsics/rotr
8-rotr16?view=msvc-160
>
> To dotyczy tej pracy:
> https://www.pcg-random.org/pdf/hmc-cs-2014-0905.pdf

Tak, wiem. Ja tylko wskazuję na błędnie zadane pytanie: "Jak działa
rotr16 w c". Otóż nie działa, bo nie ma czegoś takiego w C.

> Tam są używane rotate64. Kod jednego z generatorów, który mnie
> interesuje wygląda tak:
>
> 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;

Powyższy kod odwołuje się do funkcji pcg_rotr_64(). Sądząc po nazwie,
to jest funkcja wchodząca w skład samego projektu.

> Chcę wiedzieć co tam jest robione

Zajrzyj głębiej w źródła, by odszukać jak PCG zaimplementował swoje
pcg_rotr_64().


Mateusz

do góry

> > 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.

do góry

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

do góry

ś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.

do góry