Skip to content

Cleanup code in neg_binomial_2_lpmf and neg_binomial_2_log_lpmf #1531

Description

@rok-cesnovar

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 code

Can someone with the knowledge of this codebase double-check. It does seem at least a bit fishy.

Current Version:

v3.0.0

Activity

  1. mcol commented on Dec 20, 2019

    @mcol
    Member

    See #1496 where some of these problems have already been noticed.

  2. syclik commented on Dec 20, 2019

    @syclik
    Member
  3. rok-cesnovar commented on Dec 20, 2019

    @rok-cesnovar
    MemberAuthor

    @mcol thanks, I went to check the PR addressing that issue and I didnt see this being addressed. Not sure this contributes to the problem @martinmodrak is investigating, which I think he also fixed with the PR. It doesnt help probably.

  4. added a commit that references this issue on Jan 2, 2020
    6cd8b9d
  5. martinmodrak commented on Jan 2, 2020

    @martinmodrak
    Contributor

    @rok-cesnovar I agree that's fishy. I also think fixing it for neg_binomial_2_lpmf along #1496 in the PR #1497 makes sense, as otherwise there would be just merge conflicts. I am currently not touching neg_binomial_2_log_lpmf, so this would need to be fixed separately, possibly when handling #1495, but I don't think I'll be able to work on #1495 anytime soon, so might be worth fixing separately.

  6. mcol commented on Feb 4, 2020

    @mcol
    Member

    These are actually benign, as in doing for (size_t i = 0, size = length(mu); i < size; ++i) the variable size is actually being declared in the inner scope of the for loop, so it doesn't affect the one declare outside of it. I only realised this was the behaviour through tests, it's definitely very confusing!

  7. added this to the 3.1.0++ milestone on Feb 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions