# Power function

### From HaskellWiki

(link to Numeric Prelude on Wiki) |
(integral exponent) |
||

Line 21: | Line 21: | ||

But also for real numbers there are problems: |
But also for real numbers there are problems: |
||

− | For computing <hask>(-1)**(1/3::Double)</hask> the power implementation has to decide whether |
+ | For computing <hask>(-1)**(1/3::Double)</hask> the power implementation would have to decide whether |

<hask>(1/3::Double)</hask> is close enough to <math>\frac{1}{3}</math>. |
<hask>(1/3::Double)</hask> is close enough to <math>\frac{1}{3}</math>. |
||

If it does so it returns <hask>(-1)</hask>, otherwise it fails. |
If it does so it returns <hask>(-1)</hask>, otherwise it fails. |
||

Line 27: | Line 27: | ||

It may be really meant as <hask>333333333333333/10^15</hask>, |
It may be really meant as <hask>333333333333333/10^15</hask>, |
||

and a real <math>10^{15}</math>th root of <math>-1</math> does not exist. |
and a real <math>10^{15}</math>th root of <math>-1</math> does not exist. |
||

+ | Fortunately, the Haskell implementation does not try to be too clever here. |
||

+ | But it does so at another point: |
||

+ | <haskell> |
||

+ | Prelude> (-1)**2 :: Double |
||

+ | 1.0 |
||

+ | Prelude> (-1)**(2 + 1e-15 - 1e-15) :: Double |
||

+ | NaN |
||

+ | </haskell> |
||

+ | Of course, both expressions should be evaluated to <hask>1.0</hask>, |
||

+ | but a reliable check for integers is not possible with floating point numbers. |
||

So I propose some balancing: The more general the basis the less general the exponent and vice versa. |
So I propose some balancing: The more general the basis the less general the exponent and vice versa. |

## Revision as of 15:30, 16 October 2008

## 1 Question

Why are there several notions of power in Haskell, namely

## 2 Answer

The reason is that there is no definition for the power function which covers all exotic choices for basis and exponent.
It is even sensible to refine the set of power functions as it is done in the Numeric Prelude project.
In mathematical notation we don't respect types and we do not distinguish between powers of different types.
However if we assume the most general types for both basis and exponent, the result of the power is no longer unique.
Actually all possible solutions of say 1^{x},
where *x* is irrational is dense in the complex unit circle.
In the past I needed the power of two complex numbers only once, namely for the Cauchy wavelet (see also: [1]):

However, I could not use the built-in complex power function because the resulting function became discontinuous. Of course, powers of complex numbers have the problem of branch cuts and the choice of the branch built into the implementation of the complex power is quite arbitrary and might be inappropriate.

But also for real numbers there are problems:

For computingand a real 10^{15}th root of − 1 does not exist.
Fortunately, the Haskell implementation does not try to be too clever here.
But it does so at another point:

Prelude> (-1)**2 :: Double 1.0 Prelude> (-1)**(2 + 1e-15 - 1e-15) :: Double NaN

but a reliable check for integers is not possible with floating point numbers.

So I propose some balancing: The more general the basis the less general the exponent and vice versa. I also think the following symbols are more systematic and intuitive. They are used in NumericPrelude.

basis type | provides | symbol | exponent type | definition | |

any ring | * |
^ |
cardinal | repeated multiplication | |

any field | / |
^- |
integer | multiplication and division | |

an algebraic field | root |
^/ |
rational | list of polynomial zeros (length = denominator of the exponent) | |

positive real | log |
^? | any ring of characteristic zero with inverses for integers and a notion of limit | exponential series and logarithm |

- examples for rings are: Polynomials, Matrices, Residue classes
- examples for fields: Fractions of polynomials (rational functions), Residue classes with respect to irreducible divisors, in fact we do not need fields, we only need the division and associativity, thus invertible Matrices are fine

## 3 See also

- Haskell-Cafe: Proposal for restructuring Number classes