Example of call is missing.

Issue by jucor from Friday Nov 01, 2013 at 18:31 GMT
Originally opened as google-deepmind/torch-randomkit#8

I do not think that we test all possible combinations when we do not give a result tensor, in mvn.rnd. We probably should!

That would avoid the caller having to systematically resize. The rewrite of the parsing of mvn.rnd for 3 arguments in pull-request #16 supports it. I realize that mvn.rnd itself might not support it if only given 2 arguments, hence the issue #18.

Issue by jucor from Monday Nov 04, 2013 at 07:14 GMT
Originally opened as google-deepmind/torch-randomkit#14

Issue by jucor from Saturday Nov 02, 2013 at 10:53 GMT
Originally opened as google-deepmind/torch-randomkit#11

Suggested by @shakirm

Issue by jucor from Thursday Nov 14, 2013 at 09:26 GMT
Originally opened as google-deepmind/torch-randomkit#29

Hi @d11, @akfidjeland

I was wondering: which policy do we want to follow:

1. either avoid cloning at all cost, or
2. we are allowed to use the input arguments as temporary workspace and that it is up to the caller to clone before calling if he wants to be safe?

While I've always used 1. in const-less other languages, 2. seems more in line with Torch's philosophy for speed and the typical use of NN. What do you think ? We might guarantee that we do not resize, by using a new Tensor pointing to the same storage when we need to resize, i.e. we would never do

function f(x)
x:resize(1,x:numel())
end

but instead

function f(x)
x = torch.Tensor(x):resize(1,x:numel())
end

so that the caller is guaranteed that his views of the storage are never changed -- though the content of the storage might change.

What's your opinion?

Julien

So that people don't have to wonder whether they should use torch-randomkit or torch-distributions, take all the distributions from randomkit and create their RNG. That can probably be done automagically.

Hi,it's a wonderful module, but it seems doesn't support GPU. Do you plan to add GPU support ?
I come from scipy.stats, and looking for GPU accelerate on certain math function.

See discussion in google-deepmind/torch-randomkit#6

Issue by jucor from Tuesday Nov 12, 2013 at 14:00 GMT
Originally opened as google-deepmind/torch-randomkit#26

Pointed by @schaul: if calling with DxD mean and DxD covariance, do we want the D samples to be from one single full covariance matrix, or from D different diagonal covariance matrices ? This is ambiguous, so we should require the user to clarify her intent by passing a table with the flag {diagonal = true} or {diagonal = false}, in line with the options dicussed in #5 .

Issue by d11 from Monday Nov 11, 2013 at 10:53 GMT
Originally opened as google-deepmind/torch-randomkit#24

e.g. long; ulong.
http://jucor.github.io/torch-randomkit/randomkit.html#long

They appear in the menu but have no doc section.

Hi @d11

Just to make sure that we cover all the tests, we should probably extend the systematicTestCases to call mvn.[log]pdf, don't you think?

I've started using mvnpdf quite a bit, so I discover corner cases that we didn't deal with (see #16) in rnd -- and some are probably lurking in the pdf.

At the moment, cat.rnd() does not use the result tensor if categories == true, because torch.index() doesn't -- see torch/DEPRECEATED-torch7-distro#202. All other cases are fine.

Issue by jucor from Friday Nov 01, 2013 at 18:30 GMT
Originally opened as google-deepmind/torch-randomkit#6

Suggested by Shakir.

See discussion in google-deepmind/torch-randomkit#5

Just discovered they do not allow result tensor.

Found a bug in the KL divergence for Wishart and Normal-Wishart distributions where it is not identically zero when p and q are identical. Will fix this and add tests for all KL divergences that they return zero when both distributions are the same.

Issue by jucor from Friday Nov 01, 2013 at 18:34 GMT
Originally opened as google-deepmind/torch-randomkit#10

Suggested by @DaniloRezende.

Not good. Should work around using cumsum(), since this creates a new temporary tensor.

The sampler in distributions.wishart.rnd (as described in section 3: http://www.math.wustl.edu/~sawyer/hmhandouts/Wishart.pdf) is incorrectly implemented.

If Wishart samples are generated by taking the sample covariance from Gaussian-distributed data and the degrees of freedom parameter is estimated by maximum likelihood, the maximum likelihood estimate is within the range expected. For instance, if p=10, N=1e5 and nu=15, then the ML estimate of nu is within 0.01 of 15.

By contrast, when using distributions.wishart.rnd to generate samples, the ML estimate of nu is ~17.