Regina - Past Important Bugs

Incorrect simplification of group homomorphisms (Mar 2023)
Two Python binding errors (Oct 2022)
Normal surface enumeration ignores arguments (Sep 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.

Incorrect simplification of group homomorphisms (Mar 2023)

There are two issues here: the first issue was the bug itself, and the second issue was the only other place where the affected code was being used within Regina.


Incorrect HomGroupPresentation simplification routines
Affected versions 4.96–7.2 Fixed in version 7.3
Main symptom   In C++ or Python, calling any of the three high-level HomGroupPresentation simplification routines could give incorrect results.
Affected users C++/Python programmers only This affected programmers who called intelligentSimplify(), intelligentNielsen() or smallCancellation() on a HomGroupPresentation object.
Was I affected? Easy to test Check your C++/Python code to see if you are explicitly working with group homomorphisms (i.e., HomGroupPresentation objects), and calling one of the simplification functions listed above.
Incorrect GroupPresentation recognition for extensions over Z
Affected versions 4.96–7.2 Fixed in version 7.3
Main symptom   If a finitely presented group was an extension over Z, then GroupPresentation::recogniseGroup() (which generates the plain text “name” of a fundamental group / knot group in the graphical user interface) might have described this extension using the wrong monodromy.
Affected users All users  
Was I affected? Easy to test Only if you relied on the human-readable group names in the user interface or the string-based routine GroupPresentation::recogniseGroup(), and you were using the specific monodromies that were reported for extensions over Z.


The two issues above are related:

Specifically, if GroupPresentation::recogniseGroup() identifies a group as an extension over Z, it calls HomGroupPresentation::intelligentSimplify() to help identify the precise monodromy.

Although this was an old bug that affected all users, it is nevertheless easily to isolate the scope of the bug.

In particular, you were not affected if:

The root cause came from GroupPresentation::simplifyWord(), which would not only simplify a word in a group, but potentially rotate (i.e., conjugate) the word also. The bug then appeared because the high-level HomGroupPresentation simplification routines would use simplifyWord() to simplify images and preimages of generators under a homomorphism.

To avoid simliar problems in the future, GroupPresentation::simplifyWord() has now been renamed to GroupPresentation::simplifyAndConjugate(), in order to make its behaviour clearer.

(Back to top...)

Two Python binding errors (Oct 2022)


Incorrectly-bound swap() for fixed-width bitmasks
Affected versions 7.0–7.1 Fixed in version 7.2
Main symptom   In Python, calling regina.swap() with fixed-width bitmasks (types Bitmask8, Bitmask16, ..., Bitmask256) led to undefined behaviour.
Affected users Python programmers only This only affected those rare Python programmers who called one of the specialised swap functions above.
Was I affected? Unlikely Just examine your Python code, and see if you are explicitly creating objects of type Bitmask8, ..., or Bitmask256, and explicitly swapping them via regina.swap().
Incorrectly-bound Cyclotomic.negate()
Affected versions 5.0–7.1 Fixed in version 7.2
Main symptom   In Python, calling Cyclotomic.negate() would in fact perform a multiplicative inversion instead.
Affected users Python programmers only This only affected Python programmers who did their own arithmetic on cyclotomic field elements and called x.negate() instead of the more natural -x.
Was I affected? Unlikely Just examine your Python code, and see if you are explicitly creating Cyclotomic objects and/or retrieving them as Turaev-Viro invariants, and explicitly calling negate() on these objects.


Only Python programmers were affected by these issues: any C++ code that worked with bitmasks and/or cyclotomic field elements (including Regina's Turaev-Viro computations) was unaffected. Moreover, to trigger these bugs, you had to do the following in your own code.

To trigger the swap() bug:

To trigger the Cyclotomic.negate() bug:

It seems unlikely that anybody would have been affected by these issues:

The cause of the swap() problem was that, as noted above, Regina's C++ calculation engine does not overload regina::swap() for fixed-width bitmasks (since they are so small that a specialised swap function is unnecessary). The Python bindings incorrectly declared a regina.swap() overload for fixed-width bitmasks, but forwarded this to the C++ function that takes the more general Bitmask type instead. In Regina 7.2, the Python bindings for heavily overloaded functions such as regina::swap() have been rewritten to use typesafe C++-casts instead of the old C-style casts to resolve the overloads, thus preventing such an issue from occuring again.

The cause of the Cyclotomic.negate() function was much simpler: the python name Cyclotomic.negate was accidentally bound to the C++ method Cyclotomic::inverse() in the code that connects the two languages.

(Back to top...)

Normal surface enumeration ignores arguments (Sep 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 ...