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 bug in BlistList for two ranges that could lead to wrong results #3689

Merged
merged 1 commit into from
Oct 6, 2019

Conversation

fingolfin
Copy link
Member

Several results were wrong, and had been wrong since at least GAP 4.4.
E.g. before this commit:

gap> BlistList([0..3], [-3..-1]);
[ true, true, true, false ]

Now we get the correct result

gap> BlistList([0,1,2,3], [-3..-1]);
[ false, false, false, false ]

One major issue was the use of unsigned variables to store signed data. Two
variables were only of type long instead of Int, but on 64bit, this could
lead to further issues.

The logic handling the intersection was broken and overly complicated. The
rewritten logic should be simpler.

Finally, there is a tiny optimization enabled by switching from 1-based
indexing to 0-based.

Several results were wrong, and had been wrong since at least GAP 4.4.
E.g. before this commit:

    gap> BlistList([0..3], [-3..-1]);
    [ true, true, true, false ]

Now we get the correct result

    gap> BlistList([0,1,2,3], [-3..-1]);
    [ false, false, false, false ]

One major issue was the use of unsigned variables to store signed data. Two
variables were only of type `long` instead of `Int`, but on 64bit, this could
lead to further issues.

The logic handling the intersection was broken and overly complicated. The
rewritten logic should be simpler.

Finally, there is a tiny optimization enabled by switching from 1-based
indexing to 0-based.
@fingolfin fingolfin added kind: bug Issues describing general bugs, and PRs fixing them kind: bug: wrong result Issues describing bugs that result in mathematically or otherwise wrong results, and PRs fixing them topic: kernel backport-to-4.11 labels Oct 6, 2019
// compute bounds
i = t - s;
j = lenSub + i;
if (i < 0)
Copy link
Member Author

Choose a reason for hiding this comment

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

Note that it is crucial to compute i and j before capping the bounds; clearly the previous two lines do not commute; yet in the old code, they were in the wrong order.

long s, t; /* elements of a range */
Int lenSub; /* logical length of sublist */
Int i, j, k, l; /* loop variables */
Int s, t; /* elements of a range */
Copy link
Member Author

Choose a reason for hiding this comment

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

s, t were just of type long, so in 64 bit mode, with compilers where long is only 32 bit (basically anywhere except some Microsoft / Windows compilers), there could be overflow here. I didn't add tests for that, though.

for ( ; k+BIPEB < j; k += BIPEB )
ptrBlist[k/BIPEB] = ~(UInt)0;
for ( ; k < j; k++ )
ptrBlist[k/BIPEB] |= (1UL << k%BIPEB);
Copy link
Member Author

Choose a reason for hiding this comment

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

Note that k-1 changed to k by adjusting the bounds. I hope the optimizer would have produced identical results in both cases; but the result is certainly slightly easier to read.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.0002%) to 84.477% when pulling 1247ce7 on fingolfin:mh/fix-BlistList into 8492717 on gap-system:master.

@fingolfin fingolfin added the release notes: to be added PRs introducing changes that should be (but have not yet been) mentioned in the release notes label Oct 6, 2019
@fingolfin fingolfin merged commit 3d9c302 into gap-system:master Oct 6, 2019
@fingolfin fingolfin deleted the mh/fix-BlistList branch October 6, 2019 22:03
@fingolfin
Copy link
Member Author

Backported to stable-4.11 in 8761c8f

@fingolfin fingolfin changed the title Fix BlistList for two ranges Fix a bug in BlistList for two ranges that could lead to wrong results Nov 28, 2019
@fingolfin fingolfin changed the title Fix a bug in BlistList for two ranges that could lead to wrong results Fix bug in BlistList for two ranges that could lead to wrong results Dec 5, 2019
@fingolfin fingolfin added release notes: added PRs introducing changes that have since been mentioned in the release notes and removed release notes: to be added PRs introducing changes that should be (but have not yet been) mentioned in the release notes labels Dec 5, 2019
@olexandr-konovalov olexandr-konovalov added this to the GAP 4.11.0 milestone Feb 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-to-4.11-DONE kind: bug: wrong result Issues describing bugs that result in mathematically or otherwise wrong results, and PRs fixing them kind: bug Issues describing general bugs, and PRs fixing them release notes: added PRs introducing changes that have since been mentioned in the release notes topic: kernel
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants