2

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.

Lance
  • 2,587
  • 19
  • 35

3 Answers3

6

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.

Doc Brown
  • 206,877
5

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).

Telastyn
  • 109,398
  • 2
    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. – Lance Mar 07 '19 at 05:40
  • 1
    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. – Lance Mar 07 '19 at 05:43
  • 1
    Having a type for random is similar to having a type for increment(int), that doesn't quite make sense to me. – Lance Mar 07 '19 at 05:44
  • 1
    https://www.haskell.org/onlinereport/random.html – Lance Mar 07 '19 at 05:51
  • Increment(int) smells like Church encoding, but I suspect that what you mean is nowhere near that... – Telastyn Mar 07 '19 at 06:10
  • 3
    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'. – High Performance Mark Mar 07 '19 at 08:08
  • 2
    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? – Doc Brown Mar 07 '19 at 10:02
  • FWIW @DocBrown I concur with you that this answer rather misconceives the nature of numbers. I see now that acceptance has been switched to your answer – High Performance Mark Mar 07 '19 at 16:20
  • 1
    I'm not talking about the nature of numbers, I'm pointing out a commonly used mechanism in computer science to attribute properties to a value. Stuff like units of measure do this all the time without violating "the nature of numbers". – Telastyn Mar 07 '19 at 16:46
  • Well, I don't see this as a problem of "the nature of numbers", it is more a problem of natural language sometimes being a little bit inexact. It is common to speak of "randomness of numbers", but what we really mean is not a property of those numbers, randomness is a property of the generation process for those numbers. – Doc Brown Mar 07 '19 at 17:48
3

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.

amon
  • 134,135
gnasher729
  • 44,814
  • 4
  • 64
  • 126