Re: Proposed RAND() defn

On 29/11/10 12:38, Steve Harris wrote:
> N.B. I'm not sure that a SQL-style definition of RAND(seed) is really
> practical to define in a SPARQL context without changing a lot of other
> things.
>
> Though there's a Solution Sequence, there's nothing that requires the
> SPARQL engine to execute FILTER expressions in any particular order so
> far as I can tell. We could either drop this feature (not my
> preference), or relax the wording — if this is an issue. Relaxing the
> wording would make it hard to test. Thoughts?
>
> - Steve
>
> ----
>
> RAND
>
> The RAND function returns an xsd:double in the range [0,1), i.e. 0 ≤
> RAND() < 1. The return value may be generated using some stochastic
> process, or a pseudorandom sequence.
>
> If RAND() is called with no arguments, then it returns a potentially
> different random/psuedorandom value for each invocation.
>
> If RAND() is called with a numeric argument, then the argument is used
> as a seed value, returning a consistent value in [0,1) for each solution
> in the solution sequence for which it is evaluated. Such that, for a
> given seed RAND(seed) will return the same value whenever it's invoked
> for evaluation of the first solution in the solution sequence, and a
> possibly different value consistent value for the second solution, and
> so on.

Maybe we can specify RAND(seed) by simply saying that it will generate a 
pseudorandom sequence with the suggestion ("SHOULD") generate the same 
sequence on each run as a debugging aid.  This decouples it from 
solution sequences.

An implementation can be simply a random number generator like srand(N).

Obviously, an implementation that changes execution plan based on 
external factors (e.g. load, RAM available or somethign smart like that) 
could potentially change the number of calls to RAND but that's a bit

(it already has to worry about RAND not being a strict function)

 Andy

Received on Monday, 29 November 2010 21:49:59 UTC