Sorry about that. I certainly didn't intent to remove that method. I review every file and line before I commit changes, I must have not been paying very close attention.

Thank you for bringing this to my attention.

I have build and released a new NuGet package, version 2025.1001.2.129 that contains this fix.

Thanks, this looks to be back again :). Would it maybe be possible to also get a version that accepts a BigDecimal as the first argument? I've tried to create one myself but this seems to be quite difficult (the LogN and Exp functions frequently freeze up due to how much work they would need to do)

For clarity, I was trying to get it to work like this (came from ChatGPT as I'm not the strongest with this kind of math in general so it might be flawed from the start already)

  public static BigDecimal Pow(BigDecimal @base, BigDecimal exponent)
  {
      // Convert exponent to natural logarithm
      BigDecimal logarithm = BigDecimal.Log(@base);
      
      // Multiply logarithm by the decimal exponent
      BigDecimal resultLog = BigDecimal.Multiply(logarithm, exponent);
      
      // Convert back to original scale
      BigDecimal result = BigDecimal.Exp(resultLog);
      
      return result;
  }

Would it maybe be possible to also get a version that accepts a BigDecimal as the first argument?

For clarity, I was trying to get it to work like this (came from ChatGPT as I'm not the strongest with this kind of math in general so it might be flawed from the start already)

  public static BigDecimal Pow(BigDecimal @base, BigDecimal exponent)
  {
     ...

This method is essentially correct. The only thing it got wrong is there is no BigDecimal.Log() method; Use BigDecimal.Ln() instead.

I didn't think it was correct at first, so I implemented it using the same principal, then compared the methods. This is what I made:

public static BigDecimal Pow(BigDecimal @base, BigDecimal exponent, int precision)
{
	//  b^p = x^(p * log_x(b)) = e^(p*ln(b))
	// because log_x(b^p) = p * log_x(b)

	BigDecimal ln_b = BigDecimal.Ln(@base, precision);
	return BigDecimal.Exp(exponent * ln_b, precision);
}

But you are correct about behavior of LogN and Exp: Because these are implemented using the Taylor series, the asymptotic complexity depends almost entirely on its input; some values take hundreds of iterations to converge, others might take just 3.

And in the above code, we are calling both Ln and Exp, increasing the chances that one of them will not like its input value and bog down.

So for this reason, it would probably be better if I just wrote an exponentiation function directly. I have made a start on this. I don't anticipate running into any difficulties.

In the interim, use the above method for now, I guess.