Random Number Generator

You might have wondered how predictable machines like computers can generate randomness. In reality, most random numbers used in computer programs are pseudo-random, which means they are generated in a predictable fashion using a mathematical formula. This is fine for many purposes, but it may not be random in the way you expect if you’re used to dice rolls, roulette wheels and lottery draws.

A list of random number is a numerical sequence as defined in Wiki – “A numeric sequence is said to be statistically random when it contains no recognizable patterns or regularities; sequences such as the results of an ideal die roll, or the digits of π (as far as we can tell) exhibit statistical randomness…

We can write a random number generator to generate a list of random numbers in a given range. A random number generator (often abbreviated as RNG) is a computational or physical device designed to generate a sequence of numbers or symbols that lack any pattern, i.e. appear random. Computer-based systems for random number generation are widely used, but often fall short of this goal, though they may meet some statistical tests for randomness intended to ensure that they do not have any easily discernible patterns. Methods for generating random results have existed since ancient times, including dice, coin flipping, the shuffling of playing cards, the use of yarrow stalks in the I Ching, and many other techniques.

Intuitively, an algorithmically random sequence (or random sequence) is an infinite sequence of binary digits that appears random to any algorithm. The definition applies equally well to sequences on any finite set of characters. Random sequences are key objects of study in algorithmic information theory.

I had written a small program in Java to generate a sequence of unique random numbers within 20.

The program is here: Random Number Generator

I am creating a List in which I intend to store unique number between 1 and 20 (inclusive). Firstly, I have to get hold of the object of class Random In order to store only unique numbers, first I check after generating the random number by


whether that number already exists in the list. And, thats it. You have got a list of unique random numbers between 1 and 20.

Blogged with Flock

Tags: , , , ,


Traits for Java

What are Traits?Traits are like interfaces, but can have a method body and a class that implements a Trait inherits the method body. In many ways Traits are similar to abstract classes, but they don’t have constructors, don’t have initializers, don’t have fields, can be multiply inherited (like an interface), and super does not refer to a method in an inherited trait, instead of super you have to qualify the intended name [TraitName].[methodName]( … ).By way of example consider current best practice: you write an interface, e.g. List, write a useful abstract class to make writing lists easier, AbstractList, and then implement some lists, e.g. ArrayList. This is all well and good, but suppose you now want to add some extra methods to List, e.g. sort. You can’t because every class that implements List would need to add a sort method and you don’t have control over all the source that uses List. So instead you use a helper class, Collections, and add sort as a static method. The user then calls sort( list ) (assuming a static import is used). A better technique is a Trait, with a trait you modify List:

public interface List extends Collection {

void sort() { … } // same syntax as an interface but allows method bodies


ArrayList now automatically pick up sort and the user does not need a special import, instead just like any other instance method the user writes list.sort().


With Traits, if there is a conflict due to multiple inheritance then you have to resolve this conflict (this is a key difference from Mixins – see below). E.G.:

interface X { int m() { return 1; } }

interface Y { int m() { return 2; } }

interface Z extends X { int m() { return 3; } }

class XY implements X, Y { // conflict – 2 m’s

public int m() { return X.m(); } // resolve conflict


class XZ implements X, Z {} // no conflict – Z’s m overrides X’s

Note on Mixins

The difference between a Trait and a Mixin is that order is important. In the class XY example given above, with a Trait you have to explicitly say which m you want. With a Mixin the order in which the interfaces are mixed in determines what happens. class XY implements X, Y {} is read as first mixing in X then mixing in Y; hence the m from Y overrides the m from X, since it is mixed in afterwards.

Note on Extension Methods

An alternative way of adding methods to a class is Extension Methods, these are proposed for Java 7, but have a number of problems.

Extending existing classes

To be able to add methods to an interface without recompiling, all clients of the interface, the class loader has to be extended to automatically add in the extra methods if they are not present and to flag an error if an unresolved conflict exists. Currently the class loader flags a missing method, the required extra action would be to see if the missing method is in an implemented interface and if it can be added without conflict.

As an alternative to abstract classes

Traits would be a viable alternative to abstract classes in many cases, for example the methods in AbstractCollection could be moved to Collectionand no one would need to use AbstractCollection in the future. But a Trait cannot have any fields, therefore some abstract classes, e.g. AbstractList (it contains a field) would still be needed, although some methods may be moved to an interface.



Supporting Java Traits in Eclipse