### Storage of a Rational Pi

Last week, after having discovered a rather simple methodology for translating a floating-point computational representation of the irrational number,*pi*, into a rational number with a decimal exponent, within a fixed-precision floating point implementation, in a software system -- which I denoted,

*a rational pi*, in a previous article, here at my DSP42 web log -- I was all the more cheered, when I discovered that there is also a methodology available for translating

*pi*or any other floating point number, into a

*rational*value, within a machine's respective data space, namely as represented with the ANSI Common Lisp

*rational*and

*rationalize*functions. On having discovered that simple feature of the ANSI Common Lisp standard, I was quite cheered to observe:

...as within the Common Lisp implementation in which I had performed that calculation, namely Steel Bank Common Lisp (SBCL) version 1.2.1 (x86-64) on Microsoft Windows. An equivalent value is produced, with that form, in SBCL 1.2.4 (x86-64) on Linux.(rationalize=>pi)245850922/78256779

Though the behaviors of the

*rational*and

*rationalize*functions are defined, broadly, in ANSI Common Lisp, but -- of course -- such translation of floating point values into ratio values would be nothing so directly and explicitly standardized as of IEEE floating-point arithmetic. Indirectly, however, given a value of

*pi*calculated to the greatest possible precision of floating point values within a single Common Lisp implementation, one would assume that between two separate Common Lisp implementations, as such -- both implementing the IEEE standards for floating-point arithmetic -- that the form,

**(rationalize**, would return an equivalent rational value, in each respective Common Lisp implementation.

*pi*)Incidentally, for those of us not having a membership in the IEEE, the article -- i.e [Goldberg1991] -- What Every Computer Scientist Should Know About Floating Point Arithmetic, by David Goldberg (XEROX PARC) (1991) -- that article may serve to explain many of the principles represented in IEEE floating-point arithmetic, candidly whether with or without an accessible draft of the standards defining the IEEE floating-point arithmetic.

### Ratio as Rational Number

This might sound like some fairly*dry*or perhaps

*droll*material to be writing about. Certainly, with so many implementations of IEEE floating-point arithmetic, in computing, one might wish to simply accept the

*ulps*and

*relative errors*of the floating point implementation, and set a software program to continue, nonetheless, along its axiomatic course. Certainly, by any stretch of arithmetic, 1/3 will always be

*an irrational number, when reduced to a floating point value.*

So, there's

*"The rub,"*essentially. The number 1/3 itself is a

*rational number*-- having the corresponding

*mathematical accuracy*of a rational number,

*per se*-- though its

*floating point*representation is not a rational number.

Conveniently, perhaps, ANSI Common Lisp defines a numeric type,

*ratio*, disjunct to the numeric type

*, integer --*both of which, together, serve to fulfill the set of all types of

*rational*number.

Without making a comprehensive review of ANSI Common Lisp, albeit, one might simply observe that the Common Lisp

*ratio*type is utilized in many mathematical operations within a Common Lisp implementation. For example, in a simple evaluation in SBCL, specifically:

(/ 1 3)=>1/3

### Rational Magnitude and Degree

This short web log article, presently, will endeavor to illustrate a relevance of*rational values*as

*intermediary values*within multi-step mathematical formulas. Rather than preferring a

*ratio*type rationalization of

*floating-point*numbers, however, this article will develop a

*decimal exponent*encoding for rationalization of

*floating-point numbers*.

This article will develop an example onto a methodology for an estimation of net circuit impedance within a single-source AC circuit comprised of resistive, inductive, and capacitive (R,L,C) circuit elements, in which -- namely -- firstly, each of net inductive reactance, net capacitive reactance, and -- if applicable -- net parallel reactance is calculated -- those values deriving from the respective

*net inductance*and

*net capacitance*, and single-source

*frequency*, in the respective circuit being analyzed. Then, one would apply the

*reactance*value together with the

*resistance*in the circuit, for calculating the net circuit

*impedance*and its respective

*phase angle*, through any exacting approach to the computation of those values, dependent on the nature of the exact circuit network -- thus, in a conventional methodology, ultimately estimating a net circuit

*impedance*, such that may then be applied in estimating a net circuit

*current*, subsequently in estimating the

*current*and

*voltage*at individual

*circuit elements*, within the circuit being analyzed, thusly. At all points, in such calculation, it would be possible for the floating-point implementation to introduce its own natural errors -- whether of a hand-held calculator, or a program system at a desktop computer -- as due to floating point

*ulps*and

*relative error*, such as addressed in [Goldberg1991].

Without venturing to estimate whether such a methodology may be the best or most accurate methodology available for an estimation of net circuit

*impedance*, presently it may serve as a simple example of a multi-step equation utilizing of floating-point values.

At the outset, in such a calculation, the value

*pi*is encountered, as namely for calculating the net

*inductive reactance*and net

*capacitive reactance*in the circuit. For a series (R,L,C) circuit with a single-source AC power supply operating at a frequency

*f*Herz, the estimation -- as a calculation onto an imperfect mechanical domain, certainly -- the estimation may begin as follows, axiomatically:

net inductance (series)The reader will be spared the details of a further calculation or estimation of net

L_{T}= L_{1}+ L_{2}+ ... L_{n}

net capacitance (series)

C_{T}= 1 / (1/C_{1}+ 1/C_{2}+ ... 1/C_{n})

inductive reactance

X_{L}= 2 * pi * f * L_{T}

capacitive reactance

X_{C}= 1 / (2 * pi * f * C_{T})

*impedance*, by any single, known methodology, as would be in an analysis of such types of electrical circuit -- the subject matter of such as the ECT-125 course, at DeVry University Online.

Presently, this article shall focus about: That a concern with regards to

*floating point contagion*is introduced, so soon as at in the calculation of each of

*X*

_{L }and

*X*.

_{C}### Towards a Methodology for Decimal Scaling in Rationalization of Numeric Input Values

Within the last two of the preceding equations -- those representing, each, an implicit*diadic function*, accepting of values of

*f*and respectively,

*L*

_{T }or

*C*

_{T }-- within those functional equations, if

*pi*is then represented as a floating-point number, or if

*f*, L

_{T}, or C

_{T }is represented as a floating-point number, then of course each of

*X*

_{C }and

*X*

_{L }likewise would be calculated as a floating-point number. In a Common Lisp application, the resulting value would be of the greatest precision of the input values -- insofar as measuring the precision of individual floating-point numeric values.

If, instead, each input value,

*n*, to the respective functions would be represented as a numeric object with a rational magnitude,

*m*and an integer decimal degree,

*d*, such that:

```
```**n = m * 10^d**

...then those calculations may be performed all within the rational number line, wherein even the intermediary values may be stored as rational, decimal-shifted numeric objects *(m, d).*The respective calculations for each of

*inductive reactance*and

*capacitive reactance*all rely on the simple mathematical operations of multiplication and division. In a Common Lisp application, then if those calculations could be conducted with values all of type

*cl:rational*, the result would be, in each, a numeric object of type

*cl:rational.*

Essentially, this methodology applies a

*decimal shift*for integral values -- preferring a

*decimal*base for representation of floating-point values, contrasted to a

*binary*base -- in a manner that serves to ensure that

*m*and

*d*would both be rational values, representative of any floating point value

*n*. This methodology would serve to ensure that a

*rational decimal*value may be computed for any intermediary real number value, within a mathematical operation.

Furthermore, this methodology allows for a manner of

*scaling*of

*n*onto

*(m,d)*into any alternate

*scale of (m,d) --*as per the decimal prefix values standardized of the

*Systeme Internationale*(SI) -- to any scale for

*m*other than the

*initial scale*,

*d.*For

*m*being of type

*cl:integer*,

*then,*the value (m,d) may be scaled simply by incrementing or decrementing

*d.*

Of course, this in itself does not serve to eliminate the possibility of encountering a floating-point value in an arithmetic computation. For instance, in something of a trivial example, given:

then:n_{1}= 100 => (m_{1}, d_{1}) = (1, 2) n_{2}= 300 => (m_{2}, d_{2}) = (3, 2)

The quotient of nn_{1}/ n_{2}= 1/3 => (m_{3}, d_{3}) = (1/3, 0)

_{1 }and n

_{2 ,}in the value's floating point representation, would be an irrational number. In an implementation of the type,

*ratio*, however: The quotient may be stored as a

*ratio*, rather than as a

*floating point*number.

In applying such a methodology -- as here, denoted onto a decimal base, base 10 -- it may be possible to eliminate

*floating-point*values from within the

*intermediary values*of any series of mathematical calculations. Any initial

*input values*to a calculation may be converted into such

*decimal scalar*values -- for each

*n,*initializing a

*decimal scalar*object storing

*n*as a rational magnitude,

*m*, with an integer decimal degree,

*d*. Subsequently, all mathematical operations may be performed onto

*(m, d)*

On a sidebar with regards to

*base two*, ie

*binary scale*encoding for numeric objects: Considering that a numeric value -- even an integer value -- within a software system, would be encoded as a binary value, within the software system's data space, then it may seem more advantageous to perform such a

*shift*onto

*base 2*, in keeping with the natural base of the containing data space

*.*With the numeric value initially provided as a decimal digit, however, the initial precision of the input value may be lost if the shift is not performed onto the input value's base, namely the decimal base, base 10.

Whereas the conventional scalar measurement prefixes standardized in the Systeme Interationale are also defined onto the decimal base, then of course the decimal base scalar value,

*(m, d)*, may be effectively re-scaled for any prefix, with simply an adjustment applied onto

*d*, proceeding to any instance in decoding the rationally scaled decimal value.

### Inequalities Resulting of Floating-Point Type Inconsistency in Arithmetic Operations

A prototypical example is provided, onto the numeric value,*pi*, and a fraction of

*pi*, in a comparison onto a value

*functionally equivalent*or

*ideally equivalent*to the fraction of pi, the latter produced of the trigonometric transcendental function,

*atan*:

In the last instance, the call to=>(typep pi 'double-float)T(= (/pi4) (atan 1d0))=>T(= (/=>pi4) (atan 2d0 2d0))T(= (/ pi 4) (atan 2 2))=>NIL

*atan*produces a value of type

*single-float,*such that does not have the same floating-point precision as the

*double-float*value,

*pi*.

Thus, it might seem well to extrapolate that all values that are

*input*to a mathematical system -- as via

*read --*should be

*type coerced*-- in a semiotics of programming languages not Common Lisp, essentially to

*cast*a value -- to

*type coerce*all

*number*type values to

*double-float --*that being a floating-point type of some precision -- insofar as interacting with functions that accept a value of type

*float*and that consistently produce a

*floating-point*value, i.e. insofar as with regards to

*floating-point functions*.

In coercing every input

*floating-point type*numeric value into a value of a single

*floating-point*numeric type, it may be possible to ensure a greater degree of

*floating-point accuracy*, throughout a program system -- thus, obviating some concerns with regards to

*floating point contagion*.

Notably, there is a feature defined in ANSI Common Lisp, namely the

*special variable*,

*cl:*read-default-float-format*.*The conclusion of this article, an application of that variable is denoted for an extension to ANSI Common Lisp, in the form of an application of ANSI Common Lisp.

### In Search of the Elusive CL:Long-Float Numeric Type

*Presently, this article will introduce a*That if this article may be interpreted as with a perspective towards any Lisp implementations implementing a

**sidebar:***long-float*value type -- assuming that the latter may be implemented to a greater floating-point precision than the

*double-float*numeric type -- then the reader may wish to transpose the term,

*long-float,*into every instance of the term,

*double-float,*denoted in this document, thus implicitly preferring a

*floating-point numeric type*of a greater

*floating-point precision*.

### Functions Accepting of Integer Values Only

Of course, not every function in the Common Lisp numbers dictionary would accept a value of type*double-float*. For instance, the function

*isqrt*accepts values only of type

*integer*. Inasmuch, it may be noted that -- in a prototypical regards -- the double-float value

*1.0d0*is equivalent to the integer value,

*1.*If it would be thought necessary, then a

*type coercion*could be performed onto the double-float 1.0d0 to its

*integral value 1*-- with measure for accuracy -- as within an

*overloaded math functions*system, such as provided via Igneous-Math [math-ov], in the specific method dispatching provided by Igneous-Math system, in its present revision (1.3).

### Towards a Numeric Equivalence Between Numerically Rationalized Constants and Values Returned of Transcendental Functions

An

*ideal*fraction of pi,*pi/4,*represents an*ideal*angle of*exactly 45 degrees*-- essentially,*one eighth*of the radial angle of*2pi*, for*2pi*representing the total, singular measure of the radial angles in a*unit circle*.
Of course, when

*pi*must be implemented as a measurement within a computational system -- as effectively limited, then, to the*precision*of the*floating point*numeric features of the computational system -- then the definition of an*ideal angle*onto*pi*becomes effectively entangled with the definition of the same floating point implementation. Considering that all systems implementing the IEEE floating point standard would produce equivalent values for*pi*-- as when provided with a singular, conventionally accepted*reference value*for*pi*-- then one may expect a sense of*accuracy*between the respective floating point implementations, for*fractions onto pi*, as much as onto any floating-point operations conforming to the IEEE floating point standard. Presently, one might not proceed, at length, to denote any of the possibly nondeterministic qualities of such a relatively simple assertion with regards to floating-point accuracy.
If the Common Lisp

*rational*and*rationalize*functions may be applied as, in effect, to limit the number of possible instances of errors resulting of floating point*ulps*and*relative error*conditions -- literally, then, to ensure that any single, floating-point value would be*type coerced*to an appropriate rational value, as soon as a floating-point value would be introduced to a mathematical system -- but such an application may also be met with questions, namely: Whether to apply*cl:rational*or alternately, to apply*cl:rationalize,*and whence?*cl:*

*rationalize*and

*cl:*

*rational*separately, onto each of: (1)

*pi*, (2) a

*fraction of pi*, and (3) a value returned by

*cl:atan*, in an evaluation of

*cl:atan*that produces -- essentially -- a

*fraction of*

*pi,*namely towards an ideal value of

*pi/4 radians*, i.e.

*45*angular

*degrees*.

;; double-flat => rationalized rational => equivalent(= (rationalize (/=>pi4d0)) (rationalize (atan 2d0 2d0)))T;; double-float=> rationalized rational => equivalent(= (rationalize (/=>pi4)) (rationalize (atan 2d0 2d0)))T ;;pibeing of a double-float type;; With aappliedrationalizedpiinternal to the;;fractionalform,however, thefractional form;; is then unequal to itsapproximate functional equivalent.;; Ed. Note: This example was developed with SBCL. ECL presents a different result ;; than illustrated, certainly as resulting of subtle differences in implementation of ;; the function,cl:rationalize;; In applying(= (/ (rationalize=>pi) 4) (rationalize (atan 2d0 2d0)))NIL, ascl:rationalinternal to the fractional form, ;; as well as applyingonto the value returned by ;; thecl:rationalatanfunction, the two values are thenequivalent.(= (/ (rationalpi) 4) (rational (atan 2d0 2d0)))=>T

With regards to distinctions between the functions,

*cl:rational*and

*cl:rationalize*, the wording presented in the Common Lisp Hyperspec (CLHS) may seem somewhat ambiguous, in one regards, as towards a question: What is a

*completely accurate*floating point value? The question might seem tedious, perhaps, as it may be a difficult question to develop an accurate answer unto. In such regards, of course, one might revert to observing the behaviors of individual Common Lisp implementations.

Original emphasis retained, with

__emphasis added__, in quoting the CLHS dictionary for the functions

*cl:rational*and

*cl:rationalize*:

"Ifnumberis afloat,rationalreturns arationalthat is mathematically equal in value to thefloat.rationalizereturns arationalthat approximates thefloatto the accuracy of the underlying floating-point representation.

"rationalassumes that thefloatis.completely accurate

One might extrapolate, from that summary, that it might be advisable to apply"rationalizeassumes that thefloatis accurate only."to the precision of the floating-point representation

*cl:rationalize,*throughout. In implementations in which the precision of the Lisp implementation's floating-point number system is governed, effectively, by the IEEE floating-point standard, then certainly one could assume that values produced with

*cl:rationalize --*specifically, of

*cl:rationalize*applied onto double-float values -- that the results would be consistent, across all such implementations -- as when the behaviors of

*cl:rationalize*are governed expressly onto the underlying floating-point implementation, and the underlying floating-point implementation is consistent with the IEEE standard for floating-point arithmetic.

To where, then, may one relate the disposition of

*cl:rational?*This article proposes a thesis: That if the IEEE standard for floating-point arithmetic is accepted as the industry standard for floating-point arithmetic, and if the IEEE standard for floating-point arithmetic may represent an implementation of floating-point arithmetic both to an acceptable

*precision*in addition to an acceptable

*accuracy*in computations within and among individual IEEE floating-point implementations, then -- in a sense -- perhaps the IEEE floating-point standard may be denoted as

*"The nearest thing possible to a completely accurate floating-point implementation"?*Of course, that might be a

*mathematically contentious*assertion, though it might anyhow represent a

*pragmatically acceptable*assertion, towards assumptions of precision and accuracy within computational systems implementing and extending of Common Lisp.

In a practical regards: Considering the example -- presented in the previous -- as with regards to an ideal fractional value of

*pi*, namely an ideal

*pi/4*and its representation in a single Common Lisp system, as both (1) via a

*ratio*onto

*pi*and (2) in a

*numeric*

*rationalization*of an

*ideally equivalent*value returned via the

*transcendental*trigonometric function,

*atan,*then it may seem that it would instead be advisable to apply

*cl:rational, as*

*consistently and directly onto floating-point values, in all instances of when a floating-point value is*

*produced*-- as whether

*produced*via input or

*produced*via a floating-point calculation -- produced within a Common Lisp program system.

###
Concerning the Elusive *cl:long-float* Numeric Type

ANSI Common Lisp defines a type cl:long-float, with a *minimum precision*and a

*minimum exponent size*equivalent to those qualities of the type,

*cl:double-float*. On a sidebar, if one may wish to develop a further understanding of the relevance of those values, within a floating-point numeric implementation, certainly one may consult any amount of

*"Existing work"*, such as, conveniently: [Goldberg1991]

In a practical regards, it might be assumed that most Common Lisp implementations would implement or would emulate -- respectively -- the C data types,

*float*and

*double*[Wikpedia] for the Common Lisp

*cl:single-float*and

*cl:double-float*types.

Common Lisp implementations might also endeavor to implement or to emulate the C

*long double*numeric type [Wikpedia,

*ibid.*] as extending of the IEEE standards for floating-point arithmetic [Wikipedia]. Conceivably, the C

*long double*numeric type could be implemented or emulated with the elusive cl:long-float numeric type, and then extended with so many compiler-specific optimizations -- such optimizations, perhaps, providing a veritable "Icing on the rational pi" within Common Lisp applications.

### Towards Subversion of Floating Point Contagion

Concerning the behaviors of

*floating-point numeric coercion*within implementations of ANSI Common Lisp, it might be advisable for an implementation of a mathematical system to prefer*the most precise floating-point implementation available*, within a Common Lisp implementation. Conventionally, that would be the type,*double-float*.
In a simple analysis of possible sources of numeric values within a Common Lisp application, essentially a numeric value may be introduced into an application either via

*input*or via*calculation.*Concerning calculation of numeric values in Common Lisp, it would be assumed that for any calculation accepting a floating-point value, that the result of the operation would be of the same precision as the highest-precision input value -- with however much for numeric accuracy, as across possible floating point contagion, in instances of floating point coercion.
In regards to how a numeric value may be input into a Common Lisp program, one might denote at least three possible, essentially distinct input sources:

- REPL - The read/eval/print loop (REPL)
- Source file
- Compiled, "Fast loading" i.e. FASL file

In regards to the first two of those input sources, one would assume that the type of any floating-point numeric values would be selected as per the value of

Without venturing into any manner of a lengthy analysis of implementation-specific compiler behaviors and implementation-specific FASL encoding schemes, it might be denoted that a compiler may encode -- as when writing objects into an object form in a FASL file -- that a Lisp implementation may encode a floating-point value, essentially a numeric object, as being of a specific format not functionally equivalent to the value of cl:*read-default-float-format*, in any instantaneous time. Similarly, it may be possible for a Lisp implementation to

*cl:*read-default-float-format* .*It might seem, then, as if that was sufficient to ensure that all floating-point values introduced via input to a mathematical system would be of an expected floating-point format, perhaps exactly the floating-point format specified in cl:*read-default-float-format**.*Without venturing into any manner of a lengthy analysis of implementation-specific compiler behaviors and implementation-specific FASL encoding schemes, it might be denoted that a compiler may encode -- as when writing objects into an object form in a FASL file -- that a Lisp implementation may encode a floating-point value, essentially a numeric object, as being of a specific format not functionally equivalent to the value of cl:*read-default-float-format*, in any instantaneous time. Similarly, it may be possible for a Lisp implementation to

*read*a numeric value from a*FASL file*, without the value being*type coerced*according to cl:*read-default-float-format*.### Conclusion: Specifications for Floating-Point Type Coercion, Decimal Rationalization, and Default Floating-Point Format for the Lisp Reader

So, if a mathematical system was to endeavor to ensure that all

*floating-point mathematical operations*performed within the system would be performed onto the highest-precision floating point data type available in the implementation, then although it may serve to introduce an additional set of instructions into any functional forms within the same mathematical system, but the same mathematical system -- in interfacing with any function consistently returning a floating point numeric type -- may endeavor to consistently*type coerce*numeric values to the*highest precision*floating point data type available -- as insofar as in any direct interfaces onto such*floating point functions*, such as the transcendental trigonometric functions in Common Lisp. Of course, this might serve to introduce some errors, with regards to floating-point type coercion, while it would at least serve to address any errors as may occur when comparing values derived of differing floating-point precision.
It would may be a matter of a further design decision, then, as for whether the exacting floating-point format would be specified statically, at compile time, or would default to the value of cl:*read-default-float-format* at time of evaluation. Certainly, both behaviors may be supported -- the exact selection of which could be governed with specific definitions of

*cl:*features**elements, as may be applied within the source code of the system.
That, in itself, may not serve to obviate some concerns with regards to floating-point ~~or cl:rationalize~~.

*ulps*and*rounding errors*, however. So, it might furthermore be specified -- in so much as of an axiomatic regards, certainly -- that in an implementation of a mathematical object system,*viz a viz*Igneous-Math: That any procedure interfacing directly with*floating-point mathematical operations,*in Common Lisp, would return a numeric value directly rationalized with cl:rational -- referencing the example denoted in the previous, as with regards to*a rational fraction of pi*and a numeric value*functionally equivalent*or*ideally equivalent*to a*fraction of pi*, but as calculated via the transcendental trigonometric function,*atan,*onto any specific floating point precision, then the return value being*numerically rationalized*with either cl:rational
Thirdly, for ensuring a manner of

*type consistency*of values*input*via source files and*input*via the Common Lisp REPL, the mathematics system may endeavor to apply a floating-point numeric type of the highest available precision in any single Lisp implementation -- as towards the value of cl:*read-default-float-format*. Certainly, an application may endeavor to avoid setting the value of cl:*read-default-float-format* itself, however. An application may signal a*continuable error*, during*application initialization --*as when the user-specified value of cl:*read-default-float-format* would not be of the greatest available numeric precision. That*continuable error*, then, may be defined as to allow the user to select the highest-precision floating point numeric type and to set the value of cl:*read-default-float-format* oneself, form within any of the*continuation forms*defined, then, in the single*continuable error*.### Sidebar in Tangent: Design of the MCi Dobelle-App System

Of course, the previous paragraph may also serve to denote that there would be a definition of an

*application*object, as well as a definition of an*initialization*phase in the definition of an*application*object -- towards a sidebar onto the dobelle-app system, in all its colloquial name, within the*MetaCommunity*group at Github.### For "Later Study," Irregularity in Fractional Rationalized Pi onto a Rationalized, Functionally Equivalent Value Computed By atan

The following software form presents another interesting example with regards to irregularities in floating point arithmetic and rationalization of floating-point values. A study of the cause of the difference between the values of*rpi4*and

*rtpi4,*of course, may be other than trivial. No doubt, such a study may entail a study directly of the implementation of the transcendental trigonometric functions, in GNU LibC.

This example was produced, originally, with SBCL 1.2.4 on Linux (x86-64), and has been tested also with CCL 1.9-r15757 on Linux (x86-64). Considering the consistency of IEEE floating point implementations, an equivalent set of return values is calculated in each implementation.

(let ((fpi4 (/ pi 4d0)) (ftpi4 (atan 2d0 2d0)) (rpi4 (/ (rationalize pi) 4)) (rtpi4 (rationalize (atan 2d0 2d0)))) (values fpi4 ftpi4 rpi4 rtpi4 (float rpi4 pi) (float rtpi4 pi) (= rpi4 rtpi4))) => 0.7853981633974483d0, 0.7853981633974483d0, 122925461/156513558, 101534659/129277943, 0.7853981633974483d0, 0.7853981633974483d0, NIL

Notably, if the function cl:rational is applied instead of cl:rationalize, the values calculated for each of

*rpi4*and

*rtpi4*are, then, exactly equivalent, and the last return value, then, is

*T*

.### Appendix: Floating-Point and Non-Floating-Point Functions Defined in ANSI Common Lisp

The following functions, for any input values, will consistently return a floating point return value

- ffloor
- fceiling
- ftruncate
- fround

The following functions may return a rational value -- as may be tested, in each implementation -- as per the Rule of Float Substitutability, in ANSI Common Lisp. When consistently returning a floating point value, then these functions may be regarded as in the same set as the previous -- this being an implementation-specific quality.

- sin
- cos
- tan
- asin
- acos
- atan
- sinh
- cosh
- tanh
- asinh
- acosh
- atanh
- exp
- expt
- log
- sqrt

Onto floating-point complex numbers:

- cis

A set of functions that accept integer values, and would return integer values, exclusively -- this mathematics system not addressing

*ash,**ldb*, or*dpb*:- gcd
- lcm
- isqrt
- evenp
- oddp

Towards consistency onto the decimal rationalization policy of the the Igneous-Math system: Within interfaces to those functions that return

Notably, this quality of the Igneous-Math system is designed with an emphasis towards

*real*numeric*values, but that**do not*or*may not*return*integer*numeric values, those functions' direct return values should be effectively transformed with a call to cl:rational, before return.Notably, this quality of the Igneous-Math system is designed with an emphasis towards

*numeric accuracy*before*minimization of object system garbage-collection calls --*as with regards to a consistent discarding of floating point values, in procedural transformation to decimal rationalized integers.
Of course, it may be advantageous towards possible re-use of the software of the Igneous-Math system, if the decimal rationalization policy would be implemented as a compile-time option, in the Igneous-Math system.

At this point, the author's attention is returned to the documentation toolchain.