Support generating random 64-bit values.

[tannergooding]

Rationale

It is sometimes desirable to generate random numbers as inputs to tests. This works nicely for the majority of the primitive types, but not for long/ulong.

As such, I propose a method be exposed that allows the generation of random 64-bit integer values.

Proposed API

public class Random
{
    public virtual long NextInt64();
    public virtual long NextInt64(long maxValue);
    public virtual long NextInt64(long minValue, long maxValue);
}

[Tornhoof]

Shouldn't be the return value be long then?

[tannergooding]

Shouldn't be the return value be long then?

Yep. Fixed

[stephentoub]

In general I think such an addition makes sense, but some questions:

• Would all three overloads actually be virtual?
• How do you see the base implementations being implemented? In particular, if someone's derived from Random and overridden other virtuals, presumably those virtuals should be used (otherwise the new methods could utilize the wrong algorithm)... which methods would these delegate to?

[tannergooding]

@stephentoub, the short answer to your questions is that they are virtual because the existing Random.Next() methods are virtual and they should behave/be implemented following the same rules as the existing algorithms (which is, overloading one does not impact the other two).

This follows the "existing" practice for the System.Random class, which AFAIK is preferred.

[stephentoub]

What about my second question? Would they be implemented entirely in terms of calls to Sample()?

[tannergooding]

I don't think they should/can reliably delegate. The overall range of the existing methods isn't sufficient to provide good distribution for long/ulong (unless we default the range to the same as int).

If a user has already extended System.Random and overridden Next, they would likely need to reimplement NextInt64 as well. Thinking about it, they could also have already exposed a NextInt64 method, in which case this could be a "breaking" change for recompilation where warn as error is enabled.

An alternative would be to extend System.Random ourselves and not make these methods virtual at all.

[stephentoub]

I don't think they should/can reliably delegate.

That's problematic then (it's why I was asking). Let's say I've created my own SecureRandom : Random type that uses RandomNumberGenerator under the covers, and I've overridden all of the virtuals to behave the way I need them to. Now we add this new base virtual method, but it's not implemented in terms of any of the existing virtuals. Someone starts using my type before I've had a chance to provide a new override, and they call the new methods, and they get functionality that behaves incorrectly.

Thinking about it, they could also have already exposed a NextInt64 method, in which case this could be a "breaking" change for recompilation where warn as error is enabled.

While true, that's a problem we face any time we add anything new... a new type could conflict with a type the customer named, a new method on anything that's not sealed could conflict with a method the customer added on a derived type, a new method could start to be targeted silently instead of an extension method of the same name the customer defined, etc.

[tannergooding]

That's problematic then (it's why I was asking).

Right. But I don't think we can provide new overloads, short of implementing our own sub-class/providing a new Random type (or providing some kind of compat-switch), otherwise. But maybe that is a direction worth taking...

System.Random is already fairly "frozen-in-time". AFAIK, we can't readily change the algorithm (as it is a massive breaking change to anyone relying on the deterministic output from providing a fixed-seed) and because it isn't sealed it is hard to add new overloads/methods.

[danmoseley]

Can't the default implementations just call the existing int implementations twice (and shift one), to create an appropriate long?

[tannergooding]

Can't the default implementations just call the existing int implementations twice (and shift one), to create an appropriate long?

Yes, but that doesn't necessarily provide good distribution.

[tannergooding]

It would also make the algorithm more complex in the scenarios where the user specifies a custom range.

[stephentoub]

But maybe that is a direction worth taking...

For just this method? Meh, I don't think so. There must be ways of getting the desired distribution from one of the existing sources of randomness, whether Sample(), Next(...), NextBytes, NextDouble, etc., or some combination of them, even if it makes the NextInt64 method more expensive than if it wasn't delegating.

[danmoseley]

Yes, but that doesn't necessarily provide good distribution.

It does if the existing API is producing a good distribution (mixing random bits gives random bits)?

It would also make the algorithm more complex in the scenarios where the user specifies a custom range.

Yes, but seems doable.

[tannergooding]

It does if the existing API is producing a good distribution (mixing random bits gives random bits)?

Right, but because these are pseudo-random number generation algorithms they don't have perfect distribution and that can impact the overall set of numbers generated.

Finding out the distribution characteristics of the existing algorithm (when applied to generating Int64) would be something that needs to be done as part of the implementation process.

[morganbr]

@tannergooding, are you saying that there's more of a relationship between two consecutive outputs from System.Random than there would be from the same algorithm extended to cover 64-bit numbers? I'd be very surprised if that was the case. One could make a case that the actual algorithm in System.Random is suboptimal in general, but I don't think the size of the output is important in that.