Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix serious bug in bin #2680

Merged
merged 8 commits into from
Jul 11, 2022
Merged

Fix serious bug in bin #2680

merged 8 commits into from
Jul 11, 2022

Conversation

SimonHeybrock
Copy link
Member

Fixes #2679.

@@ -62,7 +62,7 @@ auto map_to_bins_chunkwise = [](auto &binned, auto &bins, const auto &data,
const auto i_bin = bin_indices[i];
if (i_bin < 0)
continue;
const uint8_t j = i_bin % chunksize;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for my understanding, why were we only seeing the bug for number of bins larger than > 65536 if the range of uint8_t is much smaller?
Also, why is InnerIndex uint16_t instead of int16_t?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chunksize was set as 128 for less than 128**2 bins, 256 for less than 256**2` bins, etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean int16_t instead of uint16_t? Since int16_t is large enough for our needs there is no reason for risky mixing of signed and unsigned integer arithmetic.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok thanks!

Copy link
Member

@nvaytet nvaytet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, but maybe you also want @jl-wynen to have a look.

Is this one of those cases where we should be making patch releases for scipp 0.12-0.14 ?

@SimonHeybrock
Copy link
Member Author

Is this one of those cases where we should be making patch releases for scipp 0.12-0.14 ?

Worth considering... and I think in doing so I found yet another problem with our release process: Making a release writes to the top-level docs (in addition to the one in the release's folder). That is we cannot really make a release except for the latest version (at least not without fixing things up later again). This is probably a good reason to go ahead with #2606, and change the release to either (a) not deploy any docs at all, or (b) deploy only to the release folder.

@SimonHeybrock SimonHeybrock merged commit 5e410db into main Jul 11, 2022
@SimonHeybrock SimonHeybrock deleted the bin-bug branch July 11, 2022 08:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Broken bin?
3 participants