Regina - Past Important Bugs

Normal surface enumeration ignores arguments (Sept 2016)
Mod and gcd broken for extremely large integers (Nov 2013)
Back to main page ...

This page lists some important bugs that appeared in previous versions of Regina, which might have affected your computations.

Please write to the developers if you need further information or assistance.

Normal surface enumeration ignores arguments (Sept 2016)


Affected versions 4.94–4.96 Fixed in version 5.0.
Main symptom   Regina computed embedded vertex normal surfaces, even if you asked for something else (e.g., fundamental surfaces, or immersed/singular surfaces).
Affected users C++ programmers only This only affected C++ programmers, and only those who called the NNormalSurfaceList::enumerate() function in a certain way.
Was I affected? Easy to test Just examine your C++ code and see if your calls to enumerate() follow the pattern described below.


Only C++ programmers were affected by this issue. If you only used Regina through Python or the graphical user interface, then you were not affected.

The problem was triggered when the user called NNormalSurfaceList::enumerate(tri, coords, which), and:

If these conditions were met, then the flag passed in which would be ignored. Instead:

The problem did not occur if:

The cause of the problem was that versions 4.94–4.96 of Regina contained two enumerate() functions: the modern function that takes NormalList and NormalAlg flags, and an old deprecated function that took a bool argument for whether to enumerate embedded surfaces only. If a single flag was passed (of the enum type NormalListFlag), then the C++ priority rules for type conversions meant that this was interpreted as a bool instead of implicitly calling the NormalList(NormalListFlag) constructor. Therefore the old function would be called instead.

This was fixed in Regina 5.0 by removing the old deprecated function entirely.

It is easy to test whether you were affected by this issue:

(Back to top...)

Mod and gcd broken for extremely large integers (Nov 2013)


Affected versions 4.94 only Fixed in version 4.95.
Main symptom   The mod and gcd operations gave incorrect results in some rare scenarios when working with extremely large integers.
Affected users All users This affected all users, but only in rare situations which are unlikely to be seen in practice (described below).
Was I affected? Unlikely The bug was quite difficult to trigger, and had relatively benign impacts unless you were working with experimental code direct from the repository. See below for details.


This issue only appeared where large integers were present, and only then in certain rare scenarios. Here “large integer” means an integer too large to fit into a native long type on a computer (i.e., its absolute value is ≥ 231 on a typical 32-bit machine, or ≥ 263 on a typical 64-bit machine).

There were in fact two bugs, both thankfully hard to trigger:

The mod error could in theory affect Regina's algebraic code (e.g., matrix computations related to homology). However, if you were simply calling getHomologyH1() on 3-manifold triangluations, it is extremely unlikely that you would encounter the bug. The more dangerous scenario is if you were using experimental (and more complex) algebraic code from the git repository (and in fact, this is how the bug was spotted).

The gcd error was extremely rare, in that there was only one pair of integers that could trigger it. In theory this error could affect normal surface enumeration, but here the symptom would have been both mild and obvious: you would have seen vertex surfaces that were not scaled down to their lowest integer multiple.

(Back to top...)

Back to main page ... Back to main page ...