TheAlgorithms/Go · error
negative Exponent provided
Error message
negative Exponent provided
What it means
ErrorNegativeExponent is returned by modular.Exponentiation when the exponent argument is negative (math/modular/exponentiation.go:29-31). The library only implements fast modular exponentiation for non-negative exponents; a negative exponent would require a modular multiplicative inverse, which this function does not compute, so it refuses the input with -1 and this sentinel error (declared at line 21).
Source
Thrown at math/modular/exponentiation.go:21
// details:
// A simple implementation of Modular Exponentiation - [Modular Exponenetation wiki](https://en.wikipedia.org/wiki/Modular_exponentiation)
// time complexity: O(log(n)) where n is the exponent
// space complexity: O(1)
// author(s) [Taj](https://github.com/tjgurwara99)
// see exponentiation_test.go
package modular
import (
"errors"
"math"
)
// ErrorIntOverflow For asserting that the values do not overflow in Int64
var ErrorIntOverflow = errors.New("integer overflow")
// ErrorNegativeExponent for asserting that the exponent we receive is positive
var ErrorNegativeExponent = errors.New("negative Exponent provided")
// Exponentiation returns base^exponent % mod
func Exponentiation(base, exponent, mod int64) (int64, error) {
if mod == 1 {
return 0, nil
}
if exponent < 0 {
return -1, ErrorNegativeExponent
}
_, err := Multiply64BitInt(mod-1, mod-1)
if err != nil {
return -1, err
}
var result int64 = 1
View on GitHub (pinned to 5ba447ec5f)
Solutions
- Check the exponent before calling: if exponent < 0, either reject the input or compute base^(-exponent) mod m via modular.Exponentiation followed by modular.Inverse of the result mod m
- Validate/sanitize the exponent at the input boundary (e.g., parse as unsigned or clamp negatives to an error in your own code)
- If a negative exponent is legitimate for your use case, use math/big's ModInverse together with a positive power instead
Example fix
// before
result, err := modular.Exponentiation(base, exp, mod) // panics-free but errors when exp < 0
// after
if exp < 0 {
return 0, fmt.Errorf("exponent must be non-negative, got %d", exp)
}
result, err := modular.Exponentiation(base, exp, mod) Defensive patterns
Strategy: validation
Validate before calling
func validExponent(exp int64) bool { return exp >= 0 }
if !validExponent(exp) { return 0, fmt.Errorf("exponent must be >= 0, got %d", exp) } Type guard
func isNonNegative(n int64) bool { return n >= 0 } Try / catch
result, err := modular.Exponentiation(base, exp, mod)
if err != nil {
if errors.Is(err, modular.ErrorNegativeExponent) {
// handle negative exponent: invert via modular.Inverse or reject input
}
return 0, err
} Prevention
- Validate exponent >= 0 at the API boundary before doing math
- Parse user-supplied exponents as unsigned integers where possible
- Compute exponent differences with explicit checks that the result is non-negative
- Add a unit test covering a negative-exponent input
When it happens
Trigger: Calling modular.Exponentiation(base, exponent, mod) with exponent < 0, e.g. Exponentiation(2, -3, 5). Any code path that passes a user-supplied or computed int64 exponent that can go negative (subtraction, unvalidated input).
Common situations: Developers assuming the function handles modular inverses for negative exponents like math/big's Exp does not either; parsing exponents from config/CLI as signed integers where a '-' slips in; computing exponent as a difference (a-b) that turns out negative.
Related errors
- integer overflow
- no Modular Inverse exists
- empty slice provided
- factorization failed
- target not found in array
AI-assisted analysis of TheAlgorithms/Go@5ba447ec5f (2026-09-02).
Data as JSON: /api/errors/19b7a570373e130b.
Report an issue: GitHub.