View source for Extended precision

{{Short description|Floating-point number formats}}
{{Distinguish|arbitrary-precision arithmetic}}
{{Floating-point}}
{{Computer architecture bit widths}}
'''Extended precision''' refers to [[floating-point arithmetic|floating-point]] number formats that provide greater [[precision (computer science)|precision]] than the basic floating-point formats.<ref>{{Harvtxt|IEEE 754|2008|loc=¶&nbsp;2.1.21}} defines ''extended precision format'' as "A format that extends a supported basic format by providing wider precision and range."</ref> Extended-precision formats support a basic format by [[floating-point error mitigation|minimizing roundoff and overflow errors]] in intermediate values of expressions on the base format.  In contrast to ''extended precision'', [[arbitrary-precision arithmetic]] refers to implementations of much larger numeric types (with a storage count that usually is not a power of two) using special software (or, rarely, hardware).

==Extended-precision implementations==
There is a long history of extended floating-point formats reaching back nearly to the middle of the last century.{{when|date=April 2024}}. Various manufacturers have used different formats for extended precision for different machines. In many cases the format of the extended precision is not quite the same as a scale-up of the ordinary single- and double-precision formats it is meant to extend. In a few cases the implementation was merely a software-based change in the floating-point data format, but in most cases extended precision was implemented in hardware, either built into the [[Central processing unit|central processor]] itself, or more often, built into the hardware of an optional, attached processor called a "[[floating-point unit]]" (FPU) or "floating-point processor" ([[Floating-point unit|FPP]]), accessible to the [[CPU]] as a fast input / output device.

===IBM extended-precision formats===
The [[IBM 1130]], sold in 1965,<ref name=IBM_1965>{{cite press release |last=Francis |first=C.G. |title=IBM introduces powerful small computer |date=11 February 1965 |publisher=International Business Machines Corporation (IBM) |department=Director of Information |place=[[White Plains, New York]] |url=http://www.ibm1130.net/1130Release.html |url-status=dead |archive-url=https://web.archive.org/web/20190705200515/http://www.ibm1130.net/1130Release.html |archive-date=2019-07-05}}</ref> offered two floating-point formats: A 32-bit "standard precision" format and a 40-bit "extended precision" format. Standard-precision format contains a 24-bit [[two's complement]] [[significand]] while extended-precision utilizes a 32-bit two's complement significand. The latter format makes full use of the CPU's 32-bit integer operations. The characteristic in both formats is an 8-bit field containing the power of two [[exponent bias|biased]] by 128. Floating-point arithmetic operations are performed by software, and [[double-precision floating-point format|double precision]] is not supported at all. The extended format occupies three 16-bit words, with the extra space simply ignored.<ref>{{cite book |series=IBM 1130 |title=Subroutine Library |edition=9th |year=1974 |publisher=IBM Corporation |pages=93 |url=http://media.ibm1130.org/1130-037-ocr.pdf}}</ref>

The [[IBM System/360]] supports a 32-bit "short" floating-point format and a 64-bit "long" floating-point format.<ref>{{cite book |series=IBM System/360 |title=Principles of Operation |edition=9th |year=1970 |publisher=IBM Corporation |page=41}}</ref> The 360/85 and follow-on [[IBM System/370|System/370]] add support for a 128-bit "extended" format.<ref>{{cite book |title=IBM System/370 Principles of Operation |edition=7th |year=1980 |publisher=IBM Corporation |pages=9{{hyphen}}2{{ndash}}9{{hyphen}}3}}</ref> These formats are still supported in the current [[z/Architecture|design]], where they are now called the "[[IBM hexadecimal floating-point|hexadecimal floating-point]]" (HFP) formats.

===Microsoft MBF extended-precision format===
The [[Microsoft BASIC]] port for the [[6502]] CPU, such as in adaptations like [[Commodore BASIC]], [[AppleSoft BASIC]], [[KIM-1 BASIC]] or [[MicroTAN BASIC]], supports an [[40-bit MBF|extended 40-bit variant]] of the floating-point format ''[[Microsoft Binary Format]]'' (MBF) since 1977.<ref name="Steil_2008">{{cite web |title=Create your own version of Microsoft BASIC for 6502 |first=Michael |last=Steil |website=pagetable.com |date=2008-10-20 |url=https://www.pagetable.com/?p=46 |page=46 |access-date=2016-05-30 |url-status=live |archive-url=https://web.archive.org/web/20160530092603/http://www.pagetable.com/?p=46 |archive-date=2016-05-30}}</ref>

===IEEE 754 extended-precision formats===
The [[IEEE 754]] floating-point standard recommends that implementations provide extended-precision formats. The standard specifies the minimum requirements for an extended format but does not specify an encoding.<ref>{{cite report |title=IEEE Standard for Floating-Point Arithmetic |author=IEEE Computer Society |date=August 29, 2008 |publisher=IEEE |id=IEEE Std 754-2008 |url=https://ieeexplore.ieee.org/document/4610935 |doi=10.1109/IEEESTD.2008.4610935 |ref=CITEREFIEEE_7542008 |isbn=978-0-7381-5752-8 |at=§3.7}}</ref> The encoding is the implementor's choice.<ref>{{cite web |url=https://babbage.cs.qc.cuny.edu/IEEE-754.old/References.xhtml#report |work=IEEE-754 Reference Material |access-date=2012-02-19 |author=Brewer, Kevin |title=Kevin's Report}}</ref>

The [[IA32]], [[x86-64]], and [[Itanium]] processors support what is by far the most influential format on this standard, the Intel 80-bit (64-bit significand) "double extended" format, described in the next section.

The [[Motorola 68881|Motorola 6888x]] math coprocessors and the [[Motorola 68040]] and [[Motorola 68060|68060]] processors also support a 64-bit significand extended-precision format (similar to the Intel format, although padded to a 96-bit format with 16&nbsp;unused bits inserted between the exponent and significand fields, and values with exponent zero and bit 63 one are normalized values<ref>{{cite book |title=Motorola MC68000 Family |series=Programmer's Reference Manual |year=1992 |publisher=NXP Semiconductors |pages=1-16,1-18,1-23 |url=https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf}}</ref>). The follow-on [[Freescale ColdFire|Coldfire]] processors do not support this 96-bit extended-precision format.<ref>{{cite book |title=ColdFire Family |series=Programmers' Reference Manual |year=2005 |publisher=Freescale semiconductor |page=7{{hyphen}}7 |url=http://cache.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf}}</ref>

The FPA10 math coprocessor for early [[ARM architecture family|ARM]] processors also supports a 64-bit significand extended-precision format (similar to the Intel format although padded to a 96-bit format with 16&nbsp;zero bits inserted between the sign and the exponent fields), but without correct rounding.<ref>{{cite web |url=https://chrisacorns.computinghistory.org.uk/docs/GECPlessey/GECPlessey_FPA10DataSheet.pdf |title=FPA10 Data Sheet |author=<!--Not stated--> |date=11 June 1993 |website=chrisacorns.computinghistory.org.uk |publisher=GEC Plessey Semiconductors |access-date=26 November 2020}}</ref>

The x87 and Motorola&nbsp;68881 80-bit formats meet the requirements of the IEEE 754-1985 double extended format,<ref name="Kahan97">{{cite web |url=https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF |title=Lecture notes on the status of IEEE standard&nbsp;754 for binary floating-point arithmetic |first=William |last=Kahan |date=1 October 1997}}</ref> as does the IEEE&nbsp;754 [[quadruple-precision floating-point format|128-bit]] binary format.

==x86 extended-precision format==
The x86 extended-precision format is an 80-bit format first implemented in the [[Intel 8087]] math [[coprocessor]] and is supported by all processors that are based on the [[x86 architecture|x86 design]] that incorporate a [[floating-point unit]] (FPU).

The Intel 8087 was the first [[x86]] device which supported floating-point arithmetic in hardware. It was designed to support a 32-bit "single precision" format and a 64-bit "double-precision" format for encoding and interchanging floating-point numbers. The extended format was designed not to store data at higher precision, but rather to allow for the computation of temporary double results more reliably and accurately by minimising overflow and roundoff-errors in intermediate calculations.{{efn|"This format is intended mainly to help programmers enhance the integrity of their single and double software, and to attenuate degradation by round-off in double matrix computations of larger dimensions, and can easily be used in such a way that substituting quadruple for extended need never invalidate its use." {{nowrap|— [[x87]] designer [[William Kahan|W. Kahan]]}}<ref>{{cite web |url=https://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF |first=William |last=Kahan |author-link=William Kahan |title=Lecture notes on the status of IEEE standard&nbsp;754 for binary floating-point arithmetic |date=1 October 1997 |pages=5}}</ref>}}<ref name="Einarsson2005">{{cite book |author=Einarsson, Bo |title=Accuracy and reliability in scientific computing |url=https://books.google.com/books?id=sh4orx_qB_QC&pg=PA9 |access-date=3 May 2013 |year=2005 |publisher=SIAM |isbn=978-0-89871-815-7 |pages=9ff}}</ref><ref>{{cite web |url=https://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html |title=Intel&nbsp;64 and IA-32 Architectures |series=Software Developer's Manual |volume=1 |at=§8.2 |publisher=Intel Corp. |date=March 2012}}</ref> All the floating-point registers in the 8087 hold this format, and it automatically converts numbers to this format when loading registers from [[computer memory|memory]] and also converts results back to the more conventional formats when storing the registers back into memory. To enable intermediate subexpression results to be saved in extended precision scratch variables and continued across programming language statements, and otherwise interrupted calculations to resume where they were interrupted, it provides [[instruction (computer science)|instructions]] which transfer values between these internal registers and memory without performing any conversion, which therefore enables access to the extended format for calculations{{efn|"High-level languages will use extended (invisibly) to evaluate intermediate sub-expressions, and later may provide extended as a declarable data type."<ref>{{cite journal |last=Coonen |first=Jerome T. |title=An implementation guide to a proposed standard for floating-point arithmetic |journal=IEEE Computer |date=January 1980 |pages=68–79|volume=13 |doi=10.1109/MC.1980.1653344 |s2cid=206445847 }}</ref>{{rp|page=70}} }} – also reviving the issue of the accuracy of functions of such numbers, but at a higher precision.

The [[floating-point unit]]s (FPU) on all subsequent [[x86]] processors have supported this format.  As a result, software can be developed which takes advantage of the higher precision provided by this format. [[William Kahan]], a primary designer of the [[x87]] arithmetic and initial IEEE&nbsp;754 standard proposal notes on the development of the x87 floating point: "An extended format as wide as we dared (80&nbsp;bits) was included to serve the same support role as the 13&nbsp;decimal internal format serves in Hewlett-Packard's 10&nbsp;decimal calculators."<ref>{{cite web |url=https://www.cs.berkeley.edu/~wkahan/MathSand.pdf |title=Mathematics written in sand - the hp-15C, Intel 8087, etc. |first=William |last=Kahan |date=22 November 1983}}</ref>  Moreover, Kahan notes that 64&nbsp;bits was the widest significand across which carry propagation could be done without increasing the cycle time on the 8087,<ref>{{cite journal |first=David |last=Goldberg |date=March 1991 |title=What every computer scientist should know about floating-point arithmetic |journal=ACM Computing Surveys |volume=23 |issue=1 |page=192 |doi=10.1145/103162.103163 |s2cid=222008826 |url=http://www.validlab.com/goldberg/paper.pdf}}</ref> and that the x87 extended precision was designed to be extensible to higher precision in future processors:
: "For now the [[extended precision#x86 extended-precision format|10&nbsp;byte extended format]] is a tolerable compromise between the value of extra-precise arithmetic and the price of implementing it to run fast; very soon two more bytes of precision will become tolerable, and ultimately a [[quadruple-precision floating-point format|16&nbsp;byte format]]. ... That kind of gradual evolution towards wider precision was already in view when [[IEEE 754|IEEE Standard&nbsp;754 for Floating-Point Arithmetic]] was framed."<ref>{{cite book |first=Nicholas |last=Higham |article=Designing stable algorithms |title=Accuracy and Stability of Numerical Algorithms |edition=2 |publisher=Society for Industrial and Applied Mathematics (SIAM) |year=2002 |page=43}}</ref>

This 80-bit format uses one bit for the sign of the significand, 15&nbsp;bits for the exponent field (i.e. the same range as the 128-bit [[quadruple-precision floating-point format|quadruple precision IEEE 754 format]]) and 64&nbsp;bits for the significand. The exponent field is [[excess-N|biased]] by 16383, meaning that 16383 has to be subtracted from the value in the exponent field to compute the actual {{nobr|power of {{math|2}}.}}<ref>{{cite report |title=80C187 80-Bit Math Coprocessor |type=datasheet |publisher=[[Intel Corporation]] |date=November 1992 |page=4 |url=https://0x04.net/~mwk/doc/intel/80187.pdf#page=4 |access-date=2024-08-24}}</ref> An exponent field value of 32767 (all fifteen bits '''1''') is reserved so as to enable the representation of special states such as [[infinity]] and [[NaN|Not a Number]]. If the exponent field is zero, the value is a [[denormal]] number and the exponent of 2 is −16382.<ref>{{cite book |title=Intel&nbsp;64 and IA-32 Architectures Developer's Manual |volume=1: Basic Architecture |publisher = [[Intel Corporation]] |date=June 2024 |at=§4.2.2 Floating-Point Data Types, §4.8 Real Numbers and Floating-Point Formats |url=https://cdrdv2-public.intel.com/825744/253665-sdm-vol-1.pdf#page=90 |access-date=2024-08-24}}  Other volumes available at [https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html Intel® 64 and IA-32 Architectures Software Developer Manuals].</ref>

[[File:X86 Extended Floating Point Format.svg]]

In the following table, "{{mvar|s}}" is the value of the sign bit (0 means positive, 1 means negative), "{{mvar|e}}" is the value of the exponent field interpreted as a positive integer, and "{{mvar|m}}" is the significand interpreted as a positive binary number, where the binary point is located between bits&nbsp;63 and 62. The "{{mvar|m}}" field is the combination of the integer and fraction parts in the above diagram.

:{| class="wikitable"
|+ Interpretation of the fields of an x86 Extended-Precision value
! Exponent
!colspan=2| Significand
!rowspan=2| Meaning
|-
!align="center"| {{small|bits<br/>78–64}}
!align="center"| {{small|bit<br/>63}}
!align="center"| {{small|bits<br/>62–0}}
|-
!rowspan=3| all '''0'''
|align="center" rowspan=2| '''0''' ||align="center"| '''0''' || Zero. The sign bit gives the sign of the zero, which usually is meaningless.
|-
|align="center"| non-zero || Denormal. The value is {{nobr|&thinsp; {{math|(−1){{sup|''s''}} × ''m'' × 2{{sup|−16382&nbsp;}} }} &thinsp;}}
|-
|align="center"| '''1''' || align="center" | anything || Pseudo Denormal. The 80387 and later properly interpret this value but will not generate it. The value is {{nobr|&thinsp; {{math|(−1){{sup|''s''}} × ''m'' × 2{{sup|−16382&nbsp;}} }} &thinsp;}}
|-
! {{small|bits<br/>78–64}}
! {{small|bits<br/>{{nobr|63–62}} }}
! {{small|bits<br/>61–0}}
!
|-
!rowspan=7| all '''1'''
|align="center" rowspan=2| '''00''' || align="center" | '''0''' || Pseudo-infinity. The sign bit gives the sign of the infinity. The 8087 and 80287 treat this as Infinity.  The 80387 and later treat this as an invalid operand.
|-
|align="center"| non-zero || Pseudo 'Not a Number'. The sign bit is meaningless. The 8087 and 80287 treat this as a Signaling Not a Number. The 80387 and later treat this as an invalid operand.
|-
|align="center"| '''01''' || align="center" | anything || Pseudo 'Not a Number'. The sign bit is meaningless. The 8087 and 80287 treat this as a Signaling Not a Number. The 80387 and later treat this as an invalid operand.
|-
|align="center" rowspan=2| '''10''' || align="center" | '''0''' || Infinity. The sign bit gives the sign of the infinity.  The 8087 and 80287 treat this as a Signaling Not a Number. The 8087 and 80287 coprocessors used the  pseudo-infinity representation for infinities.
|-
|align="center"| non-zero || Signalling 'Not a Number', the sign bit is meaningless.
|-
|align="center" rowspan=2| '''11''' || align="center" | '''0''' || Floating-point Indefinite, the result of invalid calculations such as square root of a negative number, logarithm of a negative number, {{sfrac| 0 | 0}}, {{sfrac| infinity | infinity }}, infinity times 0, and others, when the processor has been configured to not generate exceptions for invalid operands. The sign bit is meaningless. This is a special case of a Quiet Not a Number.
|-
|align="center"| non-zero || Quiet 'Not a Number', the sign bit is meaningless. The 8087 and 80287 treat this as a Signaling Not a Number.
|-
! {{small|bits<br/>78–64}}
! {{small|bit<br/>63}}
! {{small|bits<br/>62–0}}
!
|-
!rowspan=2| any<br/>other 
|align="center"| '''0''' || anything || Unnormal. Only generated on the 8087 and 80287. The 80387 and later treat this as an invalid operand. The value is {{nobr|&thinsp; {{math|(−1){{sup|''s''}} × ''m'' × 2{{sup|''e'' − 16383&nbsp;}} }} &thinsp;}}
|-
|align="center"| '''1''' || anything || Normalized value. The value is {{nobr|&thinsp; {{math|(−1){{sup|''s''}} × ''m'' × 2{{sup|''e'' − 16383&nbsp;}} }} &thinsp;}}
|}

In contrast to the [[single-precision floating-point format|single-]] and [[double-precision floating-point format|double-precision formats]], this format does not utilize an implicit / [[hidden bit]].  Rather, bit&nbsp;63 contains the integer part of the significand and bits&nbsp;62–0 hold the fractional part. Bit&nbsp;63 will be 1 on all normalized numbers. There were several advantages to this design when the [[8087]] was being developed:
* Calculations can be completed a little faster if all bits of the significand are present in the register.
* A 64-bit significand provides sufficient precision to avoid loss of precision when the results are converted back to double-precision format in the vast number of cases.
* This format provides a mechanism for indicating precision loss due to underflow which can be carried through further operations.  For example, the calculation {{nobr|{{math| 2 × {{10^|−4930}} × 3 × {{10^|−10}} × 4 × {{10^|20}} }}}} generates the intermediate result {{nobr|{{math|6 × {{10^|−4940}} }}}} which is a [[denormal]] and also involves precision loss.  The product of all of the terms is {{nobr| {{math| 24 × {{10^|−4920}} }}}} which can be represented as a normalized number.  The [[80287#80287|80287]] could complete this calculation and indicate the loss of precision by returning an "denormal" result (exponent not 0, bit&nbsp;63 = 0).<ref>{{cite book |last1 = Palmer |first1 = John F.|last2 = Morse |first2 = Stephen P.|title = The 8087 Primer|year= 1984|publisher= Wiley Press|isbn= 0-471-87569-4 |pages= [https://archive.org/details/8087primer00palm/page/14 14]|url= https://archive.org/details/8087primer00palm/page/14}}</ref><ref>{{cite book |last1= Morse |first1= Stephen P. |last2= Albert |first2= Douglas J. |year= 1986 |title= The 80286 Architecture |url= https://archive.org/details/80286architectur00mors |url-access= limited |publisher= Wiley Press|isbn= 0-471-83185-9 |pages= [https://archive.org/details/80286architectur00mors/page/91 91]–111}}</ref>  Processors since the [[X87#80387|80387]] no longer generate unnormals and do not support unnormal inputs to operations.  They will generate a denormal if an underflow occurs but will generate a normalized result if subsequent operations on the denormal can be normalized.<ref>{{cite report |title=Intel&nbsp;64 and IA-32 Architectures Developer's Manual |volume = 1 |publisher=[[Intel Corporation]] |pages=8-21 thru 8-22 |url=https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-1-manual.html}}</ref>

===Introduction to use===
The 80-bit floating-point format was widely available by 1984,<ref>{{cite web |first = Charles |last = Severance |author-link = Charles Severance (computer scientist) |date = 20 February 1998 |title = An interview with the old man of floating-point |website = eecs.berkeley.edu |publisher = [[U.C. Berkeley]] |url=https://www.eecs.berkeley.edu/~wkahan/ieee754status/754story.html }}</ref> after the development of C, Fortran and similar computer languages, which initially offered only the common 32- and 64-bit floating-point sizes. On the [[x86 architecture|x86 design]] most [[C (programming language)|C]] compilers now support 80-bit extended precision via the [[long double]] type, and this was specified in the [[C99]] / [[C11 (C standard revision)|C11]] standards (IEC&nbsp;60559 floating-point arithmetic (Annex&nbsp;F)). Compilers on x86 for other languages often support extended precision as well, sometimes via nonstandard extensions: For example, [[Turbo Pascal]] offers an {{code|extended}} type, and several [[Fortran]] compilers have a {{code|REAL*10}} type (analogous to {{code|REAL*4}} and {{code|REAL*8}}). Such compilers also typically include extended-precision mathematical [[subroutine]]s, such as [[square root]] and [[trigonometric function]]s, in their standard [[library (computer science)|libraries]].

===Working range===
The 80-bit floating-point format has a range (including [[denormal number|subnormals]]) from approximately {{nobr| 3.65 × {{10^|−4951}} }} to {{nobr| 1.18 × {{10^|+4932}} .}} Although {{nobr|{{math| log{{sub|10}}( 2{{sup|64}} ) ≈ 19.266}} ,}} this format is usually described as giving approximately eighteen significant digits of precision (the floor of {{nobr|{{math| log{{sub|10}}( 2{{sup|63}} )}} ,}} the minimum guaranteed precision). The use of decimal when talking about binary is unfortunate because most decimal fractions are recurring sequences in binary just as {{small|{{sfrac|2|3}}}} is in decimal. Thus, a value such as 10.15, is represented in binary as equivalent to 10.1499996185&nbsp;etc. in decimal for {{code|REAL*4}} but 10.15000000000000035527&nbsp;etc. in {{code|REAL*8}}: inter-conversion will involve approximation, except for those few decimal fractions that represent an exact binary value, such as 0.625&nbsp;. For {{code|REAL*10}}, the decimal string is 10.1499999999999999996530553&nbsp;etc. The last 9&nbsp;digit is the eighteenth fractional digit and thus the twentieth significant digit of the string. Bounds on conversion between decimal and binary for the 80-bit format can be given as follows: If a decimal string with at most 18&nbsp;significant digits is correctly rounded to an 80-bit IEEE&nbsp;754 binary floating-point value (as on input) then converted back to the same number of significant decimal digits (as for output), then the final string will exactly match the original; while, conversely, if an 80-bit IEEE&nbsp;754 binary floating-point value is correctly converted and (nearest) rounded to a decimal string with at least 21&nbsp;significant decimal digits then converted back to binary format it will exactly match the original.<ref name=Kahan97/> These approximations are particularly troublesome when specifying the best value for constants in formulae to high precision, as might be calculated via [[arbitrary-precision arithmetic#Applications|arbitrary-precision arithmetic]].

===Need for the 80-bit format===
A notable example of '''the need for a minimum of 64&nbsp;bits of precision in the significand''' of the extended-precision format is the need to avoid precision loss when performing  exponentiation on [[Double-precision floating-point format|double-precision]] values.<ref name=palmer>{{cite book |last1=Palmer |first1=John F. |last2=Morse |first2=Stephen P. |year=1984 |title=The 8087 Primer |publisher= Wiley Press |isbn= 0-471-87569-4 |pages=[https://archive.org/details/8087primer00palm/page/16 16] |url= https://archive.org/details/8087primer00palm/page/16}}</ref><ref name=morse>{{cite book |last1=Morse |first1=Stephen P. |last2=Albert |first2=Douglas J. |year=1986 |title=The 80286&nbsp;Architecture |url=https://archive.org/details/80286architectur00mors |url-access=limited |publisher=Wiley Press |isbn=0-471-83185-9 |pages=[https://archive.org/details/80286architectur00mors/page/96 96]–98}}</ref><ref>{{cite journal |last=Hough |first=David |date=March 1981 |title=Applications of the proposed IEEE&nbsp;754 standard for floating-point arithmetic |journal=IEEE Computer |volume=14 |issue=3 |pages=70–74 |doi=10.1109/C-M.1981.220381|s2cid=14645749 }}</ref>{{efn|"The presence of at least as many extra bits of precision in extended as in the exponent field of the basic format it supports greatly simplifies the accurate computation of the transcendental functions, inner products, and the power function {{nobr| {{mvar|y{{sup|x}}}} ."}}<ref>{{cite journal |first=Jerome T. |last=Coonen |title=An implementation guide to a proposed standard for floating-point arithmetic |journal=IEEE Computer|date=January 1980 |pages=68–79 |doi=10.1109/MC.1980.1653344 |s2cid=206445847 }}</ref>{{rp|p=70}}}} The [[x86]] floating-point units do not provide an instruction that directly performs [[exponentiation]]: Instead they provide a set of instructions that a program can use in sequence to perform exponentiation using the equation:

:<math> x^y = 2^{\ y\ \cdot\ \log_2( x ) } </math>

In order to avoid precision loss, the intermediate results "{{math|log{{sub|2}}(''x'')}}" and "{{math|''y''·log{{sub|2}}(''x'')}}" must be computed with much higher precision, because effectively both the exponent and the significand fields of {{mvar|x}} must fit into the significand field of the intermediate result. Subsequently, the significand field of the intermediate result is split between the exponent and significand fields of the final result when {{nobr| {{math|2}}{{sup|intermediate result}} }} is calculated. The following discussion describes this requirement in more detail.

With a little unpacking, an [[IEEE 754]] [[double-precision floating-point format|double-precision]] value can be represented as:

:<math>2^{(-1)^s\ \cdot\ E}\ \cdot\ M\ </math>

where {{mvar|s}} is the sign of the exponent (either 0 or 1), {{mvar|E}} is the unbiased exponent, which is an integer that ranges from 0 to 1023, and {{mvar|M}} is the significand which is a 53-bit value that falls in the range {{nobr| {{math| 1 ≤ ''M'' &lt; 2 }} .}} Negative numbers and zero can be ignored because the logarithm of these values is undefined. For purposes of this discussion {{mvar|M}} does not have 53&nbsp;bits of precision because it is constrained to be greater than or equal to one i.e. the hidden bit does not count towards the precision (Note that in situations where {{mvar|M}} is less than 1, the value is actually a de-normal and therefore may have already suffered precision loss. This situation is beyond the scope of this article).

Taking the log of this representation of a [[double-precision floating-point format|double-precision]] number and simplifying results in the following:

:<math> \log_2(2^{(-1)^s\ \cdot\ E}\ \cdot\,M) = (-1)^s\ \cdot\ E\ \cdot\ \log_2( 2 )\ +\ \log_2(M) = \pm\ E\ +\ \log_2( M )\ </math>

This result demonstrates that when taking base&nbsp;2 logarithm of a number, the sign of the exponent of the original value becomes the sign of the logarithm, the exponent of the original value becomes the integer part of the significand of the logarithm, and the significand of the original value is transformed into the fractional part of the significand of the logarithm.

Because {{mvar|E}} is an integer in the range 0 to 1023, up to 10&nbsp;bits to the left of the radix point are needed to represent the integer part of the logarithm. Because {{mvar|M}} falls in the range {{nobr| {{math| 1 ≤ ''M'' &lt; 2}} ,}} the value of {{nobr| {{math| log{{sub|2}} {{mvar|M}} }} }} will fall in the range {{nobr| {{math| 0 ≤ log{{sub|2}} {{mvar|M}} &lt; 1 }} }} so at least 52&nbsp;bits are needed to the right of the radix point to represent the fractional part of the logarithm. Combining 10&nbsp;bits to the left of the radix point with 52&nbsp;bits to the right of the radix point means that the significand part of the logarithm must be computed to at least 62&nbsp;bits of precision. In practice values of {{mvar|M}} less than <math>\ \sqrt{ 2\ }\ </math> require 53&nbsp;bits to the right of the radix point and values of {{mvar|M}} less than <math>\ \sqrt[4]{2\ }\ </math> require 54&nbsp;bits to the right of the radix point to avoid precision loss. Balancing this requirement for added precision to the right of the radix point, exponents less than 512 only require 9&nbsp;bits to the left of the radix point and exponents less than 256 require only 8&nbsp;bits to the left of the radix point.

The final part of the [[exponentiation]] calculation is computing {{nobr| {{math|2}}{{sup|intermediate result}} .}} The "intermediate result" consists of an integer part "{{mvar|I}}" added to a fractional part "{{mvar|F}}". If the intermediate result is negative then a slight adjustment is needed to get a positive fractional part because both "{{mvar|I}}" and "{{mvar|F}}" are negative numbers.

For positive intermediate results:

:<math>\ 2^ \mathsf{ intermediate\ result } = 2^{I + F} = 2^I\ 2^F\ </math>

For negative intermediate results:

:<math>\ 2^{\mathrm{intermediate\ result}} = 2^{I+F} = 2^{I\ +\ (1-1)\ +\ F} = 2^{(I - 1)\ +\ (F + 1)} = 2^{ I - 1 }\ 2^{ F + 1 }\ </math>

Thus the integer part of the intermediate result ("{{mvar|I}}" or {{nobr|"{{math|''I'' − 1}}")}} plus a bias becomes the exponent of the final result and transformed positive fractional part of the intermediate result: {{math|2{{sup|''F''}}}} or {{nobr| {{math|2{{sup|''F'' + 1}} }} }} becomes the significand of the final result. In order to supply 52&nbsp;bits of precision to the final result, the positive fractional part must be maintained to at least 52&nbsp;bits.

In conclusion, the exact number of bits of precision needed in the significand of the intermediate result is somewhat data dependent but 64&nbsp;bits is sufficient to avoid precision loss in the vast majority of [[exponentiation]] computations involving [[double-precision floating-point format|double-precision]] numbers.

'''The number of bits needed for the exponent''' of the extended-precision format follows from the requirement that the product of two [[double-precision floating-point format|double-precision]] numbers should not overflow when computed using the extended format. The largest possible exponent of a [[double-precision floating-point format|double-precision]] value is 1023 so the exponent of the largest possible product of two [[double-precision floating-point format|double-precision]] numbers is 2047 (an 11-bit value). Adding in a bias to account for negative exponents means that the exponent field must be at least 12&nbsp;bits wide.

Combining these requirements: 1&nbsp;bit for the sign, 12&nbsp;bits for the biased exponent, and 64&nbsp;bits for the significand means that the extended-precision format would need at least 77&nbsp;bits. Engineering considerations resulted in the final definition of the 80-bit format (in particular the IEEE&nbsp;754 standard requires the exponent range of an extended-precision format to match that of the next largest, [[quadruple-precision floating-point format|quad]], precision format which is 15&nbsp;bits).<ref name=morse/>

Another example of calculations that benefit from extended precision arithmetic are [[iterative refinement]] schemes, used to indirectly clean out errors accumulated in the direct solution during the typically very large number of calculations made for numerical linear algebra.<ref>{{cite journal |url=https://www.cs.berkeley.edu/~wkahan/p325-demmel.pdf |first1=James |last1=Demmel |author1-link=James Demmel |first2=Yozo |last2=Hida |first3=William |last3=Kahan |author3-link=William Kahan |first4=Xiaoye S. |last4=Li |author4-link=Sherry Li|first5=Sonil |last5=Mukherjee |first6=E. Jason |last6=Riedy |title=Error bounds from extra-precise iterative refinement |journal=ACM Transactions on Mathematical Software |volume=32 |issue=2 |pages=325–351 |date=June 2006 |access-date=2014-04-18 |doi=10.1145/1141885.1141894 |s2cid=1340891 }}</ref>

===Language support===
* Some [[C (programming language)|C]] / [[C++]] implementations (e.g., [[GNU Compiler Collection]] (GCC), [[Clang]], [[Intel C++ Compiler|Intel C++]]) implement <code>[[long double]]</code> using 80-bit floating-point numbers on x86 systems. However, this is implementation-defined behavior and is not required, but allowed by the standard, as specified for IEEE&nbsp;754 hardware in the [[C99]] standard "Annex&nbsp;F IEC&nbsp;60559 floating-point arithmetic". GCC also provides <code>__float80</code> and <code>__float128</code> types.<ref>{{cite web |url=https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html |title=Floating Types (Using the GNU compiler collection (GCC)) }} </ref>
* Some [[Common Lisp]] implementations (e.g. [[CMU Common Lisp]], [[Embeddable Common Lisp]]) implement <code>long-float</code> using 80-bit floating-point numbers on x86 systems.
* The [[D (programming language)|D]] programming language implements <code>real</code> using the largest floating-point size implemented in hardware, for example 80&nbsp;bits for [[x86]] CPUs. On other machines, this will be the widest floating-point type natively supported by the CPU, or 64-bit double precision, whichever is wider.
* [[Turbo Pascal]] (and [[Object Pascal]] or [[Delphi (programming language)|Delphi]]) has an <code>extended</code> 80-bit type available in addition to <code>real</code> / <code>single</code> (32&nbsp;bits) and <code>double</code> (64&nbsp;bits), either natively (when a 80x87 coprocessor is present) or emulated (through the Turbo87 library); this <code>extended</code> type is available on 16-, 32-, and 64-bit platforms, possibly with [[Data structure alignment|padding]].<ref>{{Cite web |url=http://docwiki.embarcadero.com/RADStudio/Sydney/en/Delphi_Considerations_for_Multi-Device_Applications#The_Extended_Data_Type_is_different_on_different_platforms |title=The Extended Data Type is different on different platforms}}</ref>
* The [[Racket (programming language)|Racket]] run-time system provides the 80-bit extflonum datatype on x86 systems.
* The [[Swift (programming language)|Swift]] standard library provides the <code>Float80</code> datatype.
* The [[Www.PowerBasic.com|PowerBASIC]] BASIC compiler provides <code>EXT</code> or <code>EXTENDED</code> 10-byte extended-precision floating-point data type.
* [[Zig (programming language)|Zig]] provides a f80 type since version 0.10.0.

==See also==
* [[GNU MPFR]] – the GNU "Multiple Precision Floating-Point Reliably" library for C
* [[IBM hexadecimal floating-point]]
* [[IEEE 754]]
* [[long double]]
* [[x87]]

==Footnotes==
{{notelist|1}}

==References==
{{reflist|25em}}

{{data types}}

{{DEFAULTSORT:Extended Precision}}
[[Category:Computer arithmetic]]
[[Category:Floating point types]]