This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 289: Exact exponentiation as a base module feature

2012-02-26 17:38:19
WG1 - Core
alexshinn
major
cowan
invalid
source
closed
2011-09-23 20:20:26
defect

(I proposed this in #79 as rational-expt but misdesigned and misexplained it, so it was quite properly shot down).

The expt procedure is part of the inexact module, as its result is not necessarily rational. This means that Schemes which do not provide inexact numbers will not provide expt either.

However, expt can safely return an exact result if its first argument is an exact number and its second argument an exact integer. Providing a separate exact-expt procedure in the base module allows this restricted but very useful functionality in the absence of inexact number support. Exact-expt would be analogous to exact-integer-sqrt, which is likewise in the base while sqrt is in the inexact module. Implementations which do provide inexact numbers (the vast majority at present) can simply equate exact-expt with expt.

Alternatively, we could move expt to the base module. In that case, implementations without inexact numbers must report an implementation restriction when the second argument is not an integer.

Actually, the second argument doesn't have to be an integer: the result of (exact-expt (/ p q) (/ j k)), where p q j k are all integers, is exact iff the kth root of both p and q is an integer. So the domain of exact-expt is any pair of exact rational numbers (but in some cases an exact result cannot be returned, in which case the behavior is unspecified).

resolutioninvalid
statusnewclosed

expt is already in the base library and no one has suggested otherwise.