Re: Feistel cipher, shorter string and hex to int
От | Ivan Sergio Borgonovo |
---|---|
Тема | Re: Feistel cipher, shorter string and hex to int |
Дата | |
Msg-id | 20090707142829.75d07e29@dawn.webthatworks.it обсуждение исходный текст |
Ответ на | Re: Feistel cipher, shorter string and hex to int ("Daniel Verite" <daniel@manitou-mail.org>) |
Ответы |
Re: Feistel cipher, shorter string and hex to int
|
Список | pgsql-general |
On Tue, 07 Jul 2009 12:07:48 +0200 "Daniel Verite" <daniel@manitou-mail.org> wrote: > Ivan Sergio Borgonovo wrote: > > > r2:=l1 # ((((1366.0*r1+150889)%714025)/714025.0)*32767)::int; > > -- but what about this? where does it come from? > > This function: > (1366.0*r1+150889)%714025 > implements a known method to get random numbers. I think it comes > from "Numerical recipes" by William Press. > Note that the algorithm is not tied to that function, it could be > replaced by something else (especially one that involves a private > key), but it has to be carefully chosen or the end result won't > look so random. I don't get the 1366.0 and the 714025.0. Writing 1366.0 isn't going to use float arithmetic? Is it there just to avoid an overflow? I'm going to see if using bigint is going to make any difference in speed. Finally... if I were (and I'm not) interested in using 30 bit, should I turn that *32767 into a *16383? For shift and bit mask it looks more obvious. Do you remember the name of this particular F? Since I don't see anything other than to_hex that could "shorten" an int to a string easily and quickly... it seems that returning a signed integer is OK. Everything else seems to need more processing at no real added value. Turning the int into base 32 [0-9A-N] with plpgsql looks expensive just to shorten the string to 4 char. Thanks. -- Ivan Sergio Borgonovo http://www.webthatworks.it
В списке pgsql-general по дате отправления: