Hello Alik,
Now “a” does not have upper bound, that’s why on using iterative algorithm with a >= 10000 program will stuck on infinite loop because of following line of code: double b = pow(2.0, s - 1.0); Because after overflow “b” becomes “+Inf”.
Yep, overflow can happen.
So should upper bound for “a" be set?
Yes, I agree. a >= 10000 does not make much sense... If you want uniform you should use random(), not call random_zipfian with a = 10000. Basically it suggests that too large values of "a" should be rejected. Not sure where to put the limit, though.
Should I mention in docs that there are two algorithms are used depending on values of a(s/theta)?
Yes, as a general principle I think that the documentation should reflect the implementation.
In attaching patch, I have added computeIterativeZipfian method and it’s usage in getZipfianRand. Is it better to move code of computing via cache to new method, so that getZipfianRand will contain only 2 computeXXXZipfian method calls?
I have not looked in detail, but from what you say I would agree that the implementation should be symmetric, so having one function calling one method or the other sounds good.
-- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
