# How to specify that a number is a random number, or a rounded number, etc

Trying to better understand how to write specifications for automated theorem proving and testing, etc. One seemingly simple example is generating a random number. I would like to know how to specify this behavior, that a function `rand()` returns a "random" number. It is straightforward to say it returns a "number", as in Haskell or any functional language you might just do `rand = number -> number`, but I would like to go further and somehow include in the specification that this number will be random. At least at a general / high level, I'm wondering how you would even write this out in natural language let alone (the goal) of some structured language or DSL.

My only attempt has been:

``````rand = number -> number that is random
``````

While it seems like it works in natural language, it really doesn't and is secretly hiding the fact that it is a circular argument. It is essentially this:

``````rand = number -> random(number)
``````

Which is this:

``````rand = number -> rand(number)
``````

Basically a "type" `rand` vs. a function `rand`, but the function produces some object that is typed like the function. Phew, I start to get confused. Wondering what it would look like to write this in a more structured (perhaps even formal) way, though a complete/exact/accurate answer isn't totally necessary.

A related example is rounding a number.

``````round = number -> number that is rounded
``````

Same situation basically as the random. I don't see how to specify that the output is a rounded number.

The reason for this question is to create a specification for a random number function to prevent regressions and optimize unit tests.

For properties like (pseudo-)"randomness" or "rounded" there exist well-known mathematical definitions. If you want to have an unambigous specification, there is no way round to utilize these definitions.

For example, a specific kind of rounding - rounding to the next nearest integer, can be specified by writing something like

`round(x) -> y`, where y is the integer among all integer numbers which minimizes |x-y| (and if that integer is not unique, let y be the larger one of the two candidates)

The mathematical definition of a specific kind of randomness is more complex, since you cannot simply "test" the randomness of a function by testing individual evaluations, you need to describe the behaviour of the function "at a whole". See Wikipedia for a full-blown formal description. Or you use a specific pseudo-random generator formula for making a spec.

Note also you were talking about properties of functions, not of numbers - you cannot tell if a number was produced by a "random" process, just by looking at the number. You also cannot tell if an (input) number was rounded correctly to some (output) number by just looking at the (output) number.

You just make it a type. Then you make sure your random number generators return that type rather than an `int` (though you probably care about real random numbers vs pseudorandom if you care enough to type them in a proof system). Because without types you can't really know if it is random (https://dilbert.com/strip/2001-10-25).

In some languages you can make it a fancy type that allows `random(int)` and `random(float)` and `random(string)` sort of things without duplication of code. Though I am not familiar enough with languages like that to offer much advice. And it's going to be troublesome in general to promote arbitrary operations over `random` while knowing if the result is still `random`.

If you're doing this on an existing language, then you get to do flow tracking or some other static analysis which probably isn't going to actually be sufficient for most languages (because they're not strict enough to know that something hasn't been tampered with, alongside the promotion problem described above).

• The weird thing is, in a different context, we might not be aware or concerned if the number is a random number. For example: `a = rand(), b = rand(), scorea = a, scoreb = b, avg(a, b)`. If you are averaging the scores, and they happened to be initialized to a random value, then the number is typed `rand(int) -> score(rand(int)) -> avg(score(rand(int)), score(rand(int)))` then it's like a really complicated type. That doesn't quite make sense. So perhaps instead you normalize them or something, I don't know. Mar 7, 2019 at 5:40
• I was hoping there was some sort of duck typing method for randomness. "If it looks random, then it is a random number", sort of thing. So instead of a type, it would have a test for its randomness. Mar 7, 2019 at 5:43
• Having a type for random is similar to having a type for `increment(int)`, that doesn't quite make sense to me. Mar 7, 2019 at 5:44
• From where I sit the randomness is a property of the function, not of its result. Once generated the number is just a number. I only raise this quibble because mathematics, which is an existing system for theorem proving and testing, doesn't seem to rely on any 'type' such as random-number, it gets by OK resting on 'number'. Mar 7, 2019 at 8:08
• The original question seems to confuse the "spec for a random generator function" with "spec for a random number" (and the latter makes no sense to me, see my answer). This answer seems to embrace this misconception - or am I missing something? Mar 7, 2019 at 10:02

You can for example say “x is a random integer that is equally distributed in the range 1 <= x <= 10”. That’s better than what you have.

Beyond that, you get a good book, study the mathematics of pseudo- random numbers, and then you can write a proper spec.

For unit tests: You can do some simple tests, like generating a million numbers, and checking that they are equally distributed, and checking that for any three consecutive random numbers a, b, c each of the six possible orderings a<b<c, a<c<b etc. Comes up one sixth of the time. That will find blatant problems, but not more subtle ones.

• For randomness, there are lots of statistical and heuristic tests in the cryptography and infosec communities. Mar 7, 2019 at 15:54