Regina - Past Important Bugs

Splitting disconnected normal surfaces into connected components (Jul 2023) Identifying normalised (but not thin) triangle/tetrahedron linking surfaces (Jun 2023) 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.

Splitting disconnected normal surfaces into connected components (Jul 2023)

Summary

Details

Only C++/Python programmers were affected by this issue.

The bug did not affect:

• the graphical user interface;
• disjointness testing (which uses components() in its implementation, but in a way that did not trigger this bug);
• vertex and/or fundamental normal surfaces (which are always connected, and therefore did not trigger this bug).

Essentially, to trigger this bug, you would have needed to create your own normal surfaces in C++/Python code (e.g., by forming sums of vertex and/or fundamental surfaces), and then call the specific routines in the specific order as described above.

A workaround (if you are using Regina 7.0–7.3) is, instead of calling s.components(), to call (s*1).components(). This has the effect of creating a new surface whose connectedness is not yet known (which means the bug is not triggered).

(Back to top...)

Identifying normalised (but not thin) triangle/tetrahedron linking surfaces (Jun 2023)

Summary

Details

Only C++/Python programmers were affected by this issue: the bug did not appear in the graphical user interface.

The bug only affected (i) triangle links in normal surfaces, and (ii) triangle and tetrahedron links in normal hypersurfaces. It did not affect vertex or edge link tests at all.

The bug only affected surface/hypersurfaces s that are normalised but not thin triangle/tetrahedron links:

• The symptom was that, if the thin link test was performed on s first, before the corresponding normalised link test had been performed, then any subsequent call to the normalised test on s would return an empty list (i.e., it would incorrectly report that s is not a normalised triangle/tetrahedron link).
• The cause was essentially an over-aggressive caching of results: the thin link test would “remember” a boolean existence result, and then reuse it for both the thin and normalised link tests. However, a “no” for the thin test should not imply a “no” for the corresponding normalised test.

A workaround (if you are using Regina 7.1–7.3) is to simply call the normalised link test before the thin link test. Subsequent calls to either test on the same surface will then return the correct results.

(Back to top...)

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.

Summary

Details

The two issues above are related:

• The issue with HomGroupPresentation simplification was the root of the problem.
• The issue with GroupPresentation::recogniseGroup() was a consequence of this, and indeed the only consequence—this was the only place where Regina was actually using the problematic HomGroupPresentation simplification code.

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:

• you were just simplifying group presentations (not homomorphisms); and/or
• you were working with the group generators and relations directly (not using the text-based recogniseGroup(), i.e., the group “name”); and/or
• you were using group names to identify other types of groups (e.g., the trivial group, or cyclic groups), not extensions over Z.

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)

Summary

Details

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:

• create fixed-width bitmasks of one of the types Bitmask8, ..., Bitmask256 (the main Bitmask class was unaffected);
• swap two of these bitmasks in Python via the global regina.swap() function.

• hold a Cyclotomic object x, either by creating it yourself or by fetching it from Triangulation3.turaevViro() and/or Triangulation3.allCalculatedTuraevViro();
• explicitly negate x in Python by calling x.negate() (the operator -x was unaffected).

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

• The fixed-width bitmasks are specialised classes, mainly used for optimisation in the C++ calculation engine. They were only made accessible to Python with Regina 7.0. Moreover, they are not returned by other Regina functions: you would have had to explicitly create these bitmasks yourself.
• The heavily overloaded regina::swap() function is mainly for C++ users (as part of the shift in Regina 7.0 to value semantics). Python users do not need such a function, since Python uses reference semantics (not value semantics), and assignment operations are cheap.
• The API documentation does not actually describe an overload of regina::swap() for fixed-width bitmasks, since no such function exists in Regina's C++ calculation engine. You would have had to guess that this overload existed and tried to use it.
• Cyclotomic field elements are only returned from Regina's calculation engine when computing Turaev-Viro invariants. As invariants, Python users might want to compute these, compare them and/or hash them for fast lookup, but it seems unlikely that typical users would need to manipulate them arithmetically.

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)

Summary

Details

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:

• the NormalList argument which contained exactly one flag (e.g., only NS_FUNDAMENTAL, or only NS_IMMERSED_SINGULAR, but not a combination such as NS_FUNDAMENTAL | NS_EMBEDDED_ONLY); and
• the optional NormalAlg argument (which specifies an enumeration algorithm) was not passed.

• if the flag you passed was NS_LIST_DEFAULT, then Regina would compute immersed and/or singular vertex surfaces (i.e., it assumed the flags NS_VERTEX | NS_IMMERSED_SINGULAR instead);
• if you passed any other flag, then Regina would compute embedded vertex surfaces (i.e., it assumed the default flags NS_VERTEX | NS_EMBEDDED_ONLY instead).

The problem did not occur if:

• you did not pass the which argument (which is also optional), e.g., NNormalSurfaceList::enumerate(tri, coords); or
• you passed multiple flags in the which argument, e.g., NNormalSurfaceList::enumerate(tri, coords, NS_FUNDAMENTAL | NS_EMBEDDED_ONLY); or
• you passed an additional algorithm argument, e.g., NNormalSurfaceList::enumerate(tri, coords, NS_FUNDAMENTAL, NS_ALG_DEFAULT).

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:

• You can examine your C++ code, to see if you were calling NNormalSurface::enumerate() in the manner described above (with exactly one NormalList flag, and without passing the additional algorithm argument);
• If you have saved your data to file, then you can see what enumeration flags were actually used. You can see these flags in the graphical user interface at the top of the normal surface viewer, or you can call list.which() in Python or C++.

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

Summary

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 ≥ 2³¹ on a typical 32-bit machine, or ≥ 2⁶³ on a typical 64-bit machine).

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

• The operation (x mod m) was broken in the following scenario:
  • x was both negative and small enough to store as a native long integer; and
  • the modulus m had at some stage been too large to fit into a native long, it had subsequently been modified through some arithmetic operations so that it was now small enough to fit into a long, but the calculation engine had not yet optimised its storage and was still using a large integer representation of m; and
  • the modulus m was now small enough so that |m| ≤ |x|.
  If all of these conditions were met then the mod operation did nothing (i.e., it just returned x).
• The gcd operation was broken precisely when computing gcd(LONG_MIN, 0) or gcd(0, LONG_MIN). Here LONG_MIN represents the lowest integer that can be stored as a native long (typically -2³¹ on a 32-bit machine, or -2⁶³ on a 64-bit machine). In this case the gcd would be missing a factor of two (i.e., it would return -LONG_MIN/2 instead of the correct answer -LONG_MIN).

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 ...