Number of groups is unsigned int

[andrsd]

Refs #90

[ragusa]

silly question: size_t is machine-dependent but often unsigned int 64 bit, right? why use such a large integer capacity when we know the groups will also be less than what can be encoded using unsigned int?

[andrsd]

The only reason for std::size_t is that LBSProblem stores groups like this:

  std::vector<LBSGroup> groups_;

which I admit is somewhat silly. It kinda says that groups might be stored in random order, but I don't think the code is capable of handling that. If you always want to iterate over groups from 0..G, I can remove the container and use a smaller integer type.

[ragusa]

The only reason for std::size_t is that LBSProblem stores groups like this:

  std::vector<LBSGroup> groups_;

which I admit is somewhat silly. It kinda says that groups might be stored in random order, but I don't think the code is capable of handling that. If you always want to iterate over groups from 0..G, I can remove the container and use a smaller integer type.

Pinging @wdarylhawkins to get his opinion, since both you and I think size_t is silly.

In forward mode, we go 0..G. In adjoint mode, we may go G..0.

[wdhawkins]

The only reason for std::size_t is that LBSProblem stores groups like this:

  std::vector<LBSGroup> groups_;

which I admit is somewhat silly. It kinda says that groups might be stored in random order, but I don't think the code is capable of handling that. If you always want to iterate over groups from 0..G, I can remove the container and use a smaller integer type.

Pinging @wdarylhawkins to get his opinion, since both you and I think size_t is silly.

In forward mode, we go 0..G. In adjoint mode, we may go G..0.

I also agree that using size_t is silly. I'd much prefer it be an unsigned int.