# Slow arbitrary base exponentiation, a^b

**URL:** https://discourse.julialang.org/t/slow-arbitrary-base-exponentiation-a-b/25386
**Category:** Performance
**Created:** [June 18, 2019, 6:31am UTC](https://discourse.julialang.org/t/slow-arbitrary-base-exponentiation-a-b/25386 "2019-06-18T06:31:49Z")
**Posts on this page:** 3
**Page:** 2

<div class="post-metadata">

### Author: ![robsmith11](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/robsmith11/32/29641_2.png) [@robsmith11](https://discourse.julialang.org/u/robsmith11)
#### Post date: [October 18, 2019, 11:54pm UTC](https://discourse.julialang.org/t/slow-arbitrary-base-exponentiation-a-b/25386/21 "2019-10-18T23:54:01Z")

</div>

Of the two versions in the github repo, I have only implemented the “faster” version, which is very crude, definitely not accurarte to 7 digits.

I doubt the “fast” version is that accurate either. In the test folder of the repo, there are tests run for the power function against random values with a target of 1e-4 relative error.

---

<div class="post-metadata">

### Author: ![musm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/musm/32/3675_2.png) [@musm](https://discourse.julialang.org/u/musm)
#### Post date: [November 7, 2019, 7:38pm UTC](https://discourse.julialang.org/t/slow-arbitrary-base-exponentiation-a-b/25386/22 "2019-11-07T19:38:25Z")

</div>

The problem with these approximations is not that they’re faster than base, that we know. The base standard library demands that these function are within an \<= 1 ulp for _all possible input values_. Guaranteeing this is the case AND making these function perform as fast as possible is an incredibly hard thing to do. The proposed approximations are completely valid as long as you are aware that they are _not_ accurate to 1 ulp over the full float range.

When you use a^b it will be slower than exp(b), because the function `a^b` has to make those guarantees for ALL `a` and `b`, whereas for `exp(b)` we can specialize the algorithm for the fact that `a` is now a constant `ℯ` .

If you are writing a general library where you can’t guarantee inputs are within a specified range or don’t understand the magnitude of the resulting errors by these crude approximations, in general, it is recommended to stick to the base library’s elementary functions to avoid unforeseen issues from user inputs.

---

<div class="post-metadata">

### Author: ![RangeFu](https://avatars.discourse-cdn.com/v4/letter/r/e9c0ed/32.png) [@RangeFu](https://discourse.julialang.org/u/RangeFu)
#### Post date: [June 14, 2020, 1:49am UTC](https://discourse.julialang.org/t/slow-arbitrary-base-exponentiation-a-b/25386/23 "2020-06-14T01:49:25Z")

</div>

Interesting. I got similar patterns on two linux machines:

```julia
@btime directexp(a, b, c)

  63.230 μs (0 allocations: 0 bytes)

@btime cobexp(a, b, c)
  27.548 μs (0 allocations: 0 bytes)

```

However, if I use @fastmath for `^`:

```julia
@btime fastmath_directexp(a, b, c)

  21.457 μs (0 allocations: 0 bytes)

```

My julia is compiled from sources. Version info:

```julia
julia> versioninfo()
Julia Version 1.4.2
Commit 44fa15b (2020-05-23 18:35 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
  WORD_SIZE: 64
  LIBM: libimf
  LLVM: libLLVM-8.0.1 (ORCJIT, broadwell)

```

[Previous page](https://discourse.julialang.org/t/slow-arbitrary-base-exponentiation-a-b/25386.md?page=1)
