Description
There is some potentially dangerous code in neg_binomial_2_lpmf and neg_binomial_2_log_lpmf that I think should be made more robust. There is also possible there is a bug.
Example
This example is from neg_binomial_2_lpmf but neg_binomial_2_log_lpmf has a similar example.
In line 47 we have
size_t size = max_size(n, mu, phi);
A bit later down we have
for (size_t i = 0, size = length(mu); i < size; ++i) {
mu__[i] = value_of(mu_vec[i]);
}
for (size_t i = 0, size = length(phi); i < size; ++i) {
phi__[i] = value_of(phi_vec[i]);
}
for (size_t i = 0, size = length(phi); i < size; ++i) {
log_phi[i] = log(phi__[i]);
}So we basically overwrite the size we calculated in line 47 which is never used. And we then have
for (size_t i = 0; i < size; i++) {
if (include_summand<propto>::value) {
logp -= lgamma(n_vec[i] + 1.0);
}
if (include_summand<propto, T_precision>::value) {
logp += multiply_log(phi__[i], phi__[i]) - lgamma(phi__[i]);
}
// much more codeCan someone with the knowledge of this codebase double-check. It does seem at least a bit fishy.
Current Version:
v3.0.0
Description
There is some potentially dangerous code in neg_binomial_2_lpmf and neg_binomial_2_log_lpmf that I think should be made more robust. There is also possible there is a bug.
Example
This example is from neg_binomial_2_lpmf but
neg_binomial_2_log_lpmfhas a similar example.In line 47 we have
size_t size = max_size(n, mu, phi);A bit later down we have
So we basically overwrite the size we calculated in line 47 which is never used. And we then have
Can someone with the knowledge of this codebase double-check. It does seem at least a bit fishy.
Current Version:
v3.0.0