Learn to solve statistical problems more accurately and efficiently by improving C#'s System.Random class.

Become a C# Programmer

We face several problems in programming that deal with uncertainity, statistics, and probabilities. System.Random class in C# doesn't provide a great approach to solving these problems, since it leads to unexpected, buggy outcomes. 
This module provides us with different approaches to improve the System.Random class. We'll be provided with several powerful techniques that solve problems more efficiently and with fewer lines of code.

Fixing Random: Techniques in C#

## Introducing `System.Random`
The C# design team tries hard to make the language a *pit of success*, where the natural way to write programs is also the correct, elegant and performant way. And then `System.Random` comes along; it is almost always wrong, and it is seldom easy to make it right.

Let’s start with the obvious problem: the natural way to use it is also the wrong way. 

The naive developer thinks "I need a new random dice roll"




```C#
void M()
{
  Random r = new Random();
  int x = r.Next(1, 6);
  ...
```
Let's highlight some of the issues with this code.

## Problem with `System.Random`
Firstly, every time `M()` is called, we create a `new Random`, but in most of the implementations of `Random` available for the last couple decades, by default, it seeds itself with the current time, and **the granularity of the timer is only a few milliseconds**. Computers run on the nanosecond scale, and so the likelihood that we’ll get two `Random`s with the same seed is very high, and therefore it is very likely that successive calls to `M()` produce runs of the same number. You never want to make a new `Random` if you can avoid it; you want to make one once, and then re-use it. But it’s a bad idea to stash it away in a static because it’s not threading safe!

This problem has been fixed in some versions of the *CLR*. In those versions, a new `Random()` now seeds itself randomly, rather than based on the current time.

Second, the arguments to `Next` are the minimum value produced, inclusive, and the maximum value produced, exclusive! This program produces random numbers drawn from $1, 2, 3, 4, 5$. The correct way to get numbers from $1$ to $6$ is, of course, `Next(1, 7)`.

The *fundamental* problem here is that *we’re working at too low a level of abstraction*. It is not the 1970s anymore when `rand()` was good enough. We have sophisticated problems in statistical modeling and the attendant probabilistic reasoning to solve in modern programming languages. We need to up our game by writing code in the "*business domain*" of probabilities, not the "*mechanism domain*" of calls to methods that return random numbers.

## Implementation 
Let's have a look at the basic `Random` class in C#:

> Try running the code again and again to notice a change in output.

# Introducing `System.Random`
The C# design team tries hard to make the language a *pit of success*, where the natural way to write programs is also the correct, elegant and performant way. And then `System.Random` comes along; it is almost always wrong, and it is seldom easy to make it right.

Let’s start with the obvious problem: the natural way to use it is also the wrong way. 

The naive developer thinks "I need a new random dice roll"




```C#
void M()
{
  Random r = new Random();
  int x = r.Next(1, 6);
  ...
```
Let's highlight some of the issues with this code.

# Problem with `System.Random`
Firstly, every time `M()` is called, we create a `new Random`, but in most of the implementations of `Random` available for the last couple decades, by default, it seeds itself with the current time, and **the granularity of the timer is only a few milliseconds**. Computers run on the nanosecond scale, and so the likelihood that we’ll get two `Random`s with the same seed is very high, and therefore it is very likely that successive calls to `M()` produce runs of the same number. You never want to make a new `Random` if you can avoid it; you want to make one once, and then re-use it. But it’s a bad idea to stash it away in a static because it’s not threading safe!

This problem has been fixed in some versions of the *CLR*. In those versions, a new `Random()` now seeds itself randomly, rather than based on the current time.

Second, the arguments to `Next` are the minimum value produced, inclusive, and the maximum value produced, exclusive! This program produces random numbers drawn from $1, 2, 3, 4, 5$. The correct way to get numbers from $1$ to $6$ is, of course, `Next(1, 7)`.

The *fundamental* problem here is that *we’re working at too low a level of abstraction*. It is not the 1970s anymore when `rand()` was good enough. We have sophisticated problems in statistical modeling and the attendant probabilistic reasoning to solve in modern programming languages. We need to up our game by writing code in the "*business domain*" of probabilities, not the "*mechanism domain*" of calls to methods that return random numbers.

# Implementation 
Let's have a look at the basic `Random` class in C#:

> Try running the code again and again to notice a change in output.

In this lesson, we introduce the System.Random in C# and highlight some of the problems with it.

Introduction to System.Random in C#

Introduction to Fixing Random

Fixing Random - Discrete Distribution

Fixing Random - Continuous Distribution

Appendix

Conclusion

Disadvantages of System.Random in C#

Introducing `System.Random`

Problem with `System.Random`