On 24 May 2013, at 11:54am, Udon Shaun <udon_sh...@yahoo.com> wrote:

> But assuming that a value of some description is obtained for the seed, what 
> is the quantitative assessment of sqlite3_randomness? What is the repetition 
> rate? (2^n). Is the result of sqlite3_randomness acceptable as a 
> cryptographically secure pseudo random number generator (csprng) or is it 
> only sufficient to seed a csprng - what does "High Quality" actually mean?

The way in which SQLite's random number generators (for different platforms) 
work is on a par with those used in comparable SQL engines.  In other words, 
good enough for purposes related to database maintenance.

Unfortunately, the way SQL is defined means that there is no control over the 
ordering of processing or reporting for the results of a query.  This is 
because SQL is, by nature, a language suitable for parallel processing.  For 
instance, a command like

SELECT score,random() FROM matches ORDER BY matchID

may have to return the results of the query in a known specified order 
(assuming matchIDs are unique) but the way SQL is defined allows it to 
/process/ the results in any order it likes.  You cannot assume that the 
various random() calls were processed in the same order the rows of the result 
are returned.  A well-implemented SQL engine running on a multicore processor 
may do these things in a strange order.  Also you can't tell whether a 
particular SQL engine does

1. retrieve all required data from storage
2. sort the rows as required by the ORDER BY clause
3. calculate any calculations (including any random numbers)

OR

1. retrieve all required data from storage nearest storage block first
2. calculate any calculations (including any random numbers)
3. sort the rows as required by the ORDER BY clause

In fact it may sometimes do one and other times the other, depending on whether 
there's a convenient index.

Because there is no way of assessing the order of use of the random number 
generator, many measures used to analyse how good a generator it is just can't 
be applied.  They do things like check to see whether consecutive pairs or 
triplets, or whether sampling at regular intervals (every tenth number 
generated), correlate highly.  Looking at a SQL result you can't tell which 
results were generated in which order.  This problem makes it very difficult to 
assess the PRANG using classical methods.  Fortunately it also adds to the 
apparent 'randomness' of the results returned.

The conclusion is that if the randomness /over a collection of different rows/ 
in any SQL engine is very important to you, you substitute your own function 
instead of using random() as provided in the engine.  For SQLite you can do 
this in two ways: either generate your own random numbers in your own 
programming language, (in which case you can perfectly control which order the 
generated numbers are used) or supply a SQLite extension

<http://www.sqlite.org/loadext.html>

and implement your own function to generate random numbers by whatever method 
you want, in which case you have no idea which order the generated numbers are 
used.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to