.tools.CubicInverseTransform is using wrong pRNG.

[RuiFilipeCampos]

MontyCarlo/MontyCarlo/tools/CubicInverseTransform.pyx

Lines 234 to 269 in 224a821

	cdef double _sample(self):
	self.R = self.N * rand()
	self.i = <int> self.R
	if self.R - self.i < self.cut_offs[self.i]:
	self.dx = rand() * self.DX[self.i]
	self.y = self.c[3, self.i]
	self.y += self.c[2, self.i]*self.dx
	self.dx *= self.dx
	self.y += self.c[1, self.i]*self.dx
	self.dx *= self.dx
	self.y += self.c[0, self.i]*self.dx
	return self.y
	self.i = self.rej_indexes[self.i]
	self.y = self.c[3, self.i]
	self.dx = rand()*self.DX[self.i]
	self.y += self.c[2, self.i]*self.dx
	self.dx *= self.dx
	self.y += self.c[1, self.i]*self.dx
	self.dx *= self.dx
	self.y += self.c[0, self.i]*self.dx
	return self.y

Using old pRNG.

[RuiFilipeCampos]

Currently using rand from std lib.

MontyCarlo/MontyCarlo/tools/CubicInverseTransform.pyx

Line 37 in 224a821

from libc.stdlib cimport rand, RAND_MAX

I'm inclined to believe that using two completely independent random number generators, using completely different algorithms, generating numbers that essentially do not interact, should not affect the results. Except for the part that the quality of the pRNG in stdlib does not compare to MIXMAX. It likely affects results in this way, but likely not in an catastrophic manner.

Regardless, MontyCarlo simulates billions of particles, so this change is important because stdlib prng will fail.

This change should be done after MVP and only when I decide on the final structure of MontyCarlo, otherwise it's just lost time compiling on a low level matrix from hell.