Documentation Source Text

<h3>Is it close enough?</h3>

<p>The precision provided by IEEE 754 Binary64 is sufficient for most computations.
For example, if "47.49" represents a price and inflation is running
at 2% per year, then the price is going up by about 0.0000000301 dollars per
second.  The error in the recorded value of 47.49 represents about 66 nanoseconds
worth of inflation.  So if the 47.49 price is exact
when you enter it, then the effects of inflation will cause the true value to
exactly equal the value actually stored
(47.4900000000000019895196601282805204391479492187) in less than 
one ten-millionth of a second.
Surely that level of precision is sufficient for most purposes?

<h1>Extensions For Dealing With Floating Point Numbers</h1>

<tcl>hd_fragment ieee754ext {ieee754 extension}</tcl>
<h2>The ieee754.c Extension</h2>

<tcl>hd_fragment ieee754m {ieee754_mantissa() function} \
   {ieee754_exponent() function} </tcl>
<h3>The ieee754_mantissa() and ieee754_exponent() functions</h3>

<p>The text output of the one-argument form of ieee754() is great for human
readability, but it awkward to use as part of a larger expression.  Hence
The ieee754_mantissa() and ieee754_exponent() routines were added to return
the M and E values corresponding to their single argument F
value.
For example:

<codeblock>
sqlite> .mode box
sqlite> SELECT ieee754_mantissa(47.49) AS M, ieee754_exponent(47.49) AS E;
┌──────────────────┬─────┐

There is no division operator at this time.

<p>Use the decimal_cmp(A,B) to compare two decimal values.  The result will
be negative, zero, or positive if A is less than, equal to, or greater than B,
respectively.

<p>The decimal_sum(X) function is an aggregate, like the built-in
[sum() aggregate function], except that decimal_sum() computes its result
to arbitrary precision and is therefore precise.

<p>Finally, the decimal extension provides the "decimal" collating sequences
that compares decimal text strings in numeric order.

<h1>Techniques</h1>