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

  1. 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
  2. Validate/sanitize the exponent at the input boundary (e.g., parse as unsigned or clamp negatives to an error in your own code)
  3. 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

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


AI-assisted analysis of TheAlgorithms/Go@5ba447ec5f (2026-09-02). Data as JSON: /api/errors/19b7a570373e130b. Report an issue: GitHub.