Talk:Double-precision floating-point format

message: This entry seems to be very technical explaining what Double Precision is, but not the benefits or applications of it.
:I miss this too :/ Too bad I can't answer the question. -- Henriok 11:36, 8 January 2007 (UTC)
replies: text: I don't think that was what they were asking. Given a fixed number of bits of precision "n", you could divide the interval over which you want to calculate in 2^n equal steps, this is integer arithmetic. Unfortunately it breaks down if the interval is not bounded or if both extremely large and extremely small values are expected and relative error is more important than absolute error. This means integers are unsuitable for a general purpose arithmetic (they are "bounded") and for many real world problems (where the relative error is most important). Now, you could save the logarithm of your values to solve this, but unfortunately adding and substracting numbers would become problematic. So double precision is essentially a hybrid approach. Shinobu (talk) 23:45, 13 December 2007 (UTC)
replies: text: I think Gerbrant is reffering to the properties of floating point, not double precision in itself.  (One can have double-precision integers). mfc (talk) 09:06, 22 December 2007 (UTC)
replies: text: Its useful because computers are unable to store true Real numbers it can only store values of some arbitrary precision.  So the computer can never truly store some values, for instance .1 or values like pi.  So in application it allows for very small numbers to be represented in the computer, so for instance if you have some program that tracks the distance.  And lets say you only care about like three zeros after the decimal place, then you could use floating points to store the values of the distance. (sorry to bring this topic back from the dead, I just wanted to give an example of when floating points would be use)  Deadcellplus (talk) 21:41, 3 October 2008 (UTC)
replies: text: Again, the question was most likely about double precision as compared to single precision, rather than floating point as compared to integer arithmetic. A lot of your explanation is also incorrect - for every number there is some encoding scheme that can finitely encode that value. The only true statement you can make is that no encoding scheme can encode an uncountable number of different real numbers, since the number of strings is countable. Floating-point arithmetic is useful because it's an encoding scheme designed to handle a wide range of real values frequently encountered in applications. Dcoetzee 00:46, 4 October 2008 (UTC)

text: Maybe my information is a bit outdated, but in the book I learned x86 assembly language from, there was a note that x87 FPUs internally always use 80-bit-precision; therefore there is no speed gain for smaller precision values, only memory storage benefits. Junkstar (talk) 09:44, 18 March 2013 (UTC)
thread_title:  Pros/Cons of Double Precision 

message: I can see the exponent and the sign, but which digits in the significand are used for the numbers before the decimal point, and which are used for after?  —Preceding unsigned comment added by 67.91.121.114 (talk) 20:24, 20 May 2008 (UTC)
replies: text: This is a good question - the short answer is, usually the position of the decimal point in the significand is fixed, so that it doesn't have to be encoded. In the IEEE encoding, the point is preceded by an implicit 1, also not encoded, and followed by the explicit bits of the significand. Underflow is a special case. Dcoetzee 00:54, 4 October 2008 (UTC)
thread_title:  Fractions 

message: If "All bit patterns are valid encoding.", then why is the highest exponent represented by bits [000 0111 1111]? I tested sets of bits for higher values in Microsoft Visual Studio (C++) and got "infinite" as a value. It also turns out that comparing a double value to that "infinite" value throws an exception... But I guess this is more related to the compiler itself.  —Preceding unsigned comment added by 69.70.33.68 (talk) 15:01, 19 March 2009 (UTC)
thread_title:  Limitations 

message: "calculations with double precision are 3 to 8 times slower than float."
What exactly does "x times slower" mean? Is it n^-x? Or n/x? How much would the logical conclusion of "1 time slower" be? This unscientific colloquial English is confusing and should be clarified. I would like to, but I cannot make sense of the source given. Thanks. Andersenman (talk) 10:52, 16 July 2014 (UTC)
replies: text: x times slower is generally understood to mean it takes x times as long.  Dicklyon (talk) 03:18, 4 December 2014 (UTC)
replies: text: THEN FOR GOD'S SAKE WHY NOT WRITE IT AS THAT?! Andersenman (talk) 10:31, 30 October 2016 (UTC)
thread_title:  Execution speed - grammar 

message: According to iee-754 verbatim:
significand. The component of a binary floating-point number that consists of
an explicit or implicit leading bit to the left of its implied binary point and a
fraction field to the right.
The word "mantissa" has no definition in the standard, nor does it appear anywhere in that text.  — Preceding unsigned comment added by 23.240.200.20 (talk) 03:01, 4 December 2014 (UTC)
thread_title:  this article is using an incorrect word 

message: The very ending of section "IEEE 754 double-precision binary floating-point format: binary64" says: "By compromising precision, subnormal representation allows values smaller than 1e−323". Shouldn't it be something like "..allows even smaller numbers up to 1e-323"?  — Preceding unsigned comment added by Honzik.stransky (talk • contribs) 21:21, 18 April 2015 (UTC)
replies: text: I think it meant that there were values smaller than 1e−323, but this was very confusing. I've done the correction. Vincent Lefèvre (talk) 10:43, 28 January 2016 (UTC)
thread_title:  subnormal representation allows values smaller than 1e−323 ??? 

message: IEEE 754 double-precision binary floating-point format: binary64 - contains the following as its first sentence:"Double-precision binary floating-point is a commonly used format on PCs, due to its wider range over single-precision floating point, in spite of its performance and bandwidth cost." [emphasis mine] Aside from the OBVIOUSLY poor usage of the word "over" when "compared to" would be much clearer, I challenge this claim. I have no idea whether it is its wider RANGE or greater PRECISION, or both which motivates its use, but both are obviously reasons to use it.
I have two other issues with this article. First is the discussions of its advantages and disadvantages sprinkled around the article are simply wrong. It may be, on a particular machine, faster than single precision. That is a fact. It may use the SAME storage as single, another fact. It may also use the same bandwidth. In a theoretical sense, double precision mathematics requires more resources but what it uses depends on BOTH the hardware and the software (not to mention firmware) of the machine it is running on. This article doesn't distinguish between what is theoretically true on some abstract machine, and what the various chip architectures, core - fpu - gpu utilizations, as well as OS and compiler/interpreter optimizations and defaults will ACTUALLY do. It needs a revision to qualify the overly broad sentiments.
Second, this article discusses various languages and whether or how they implement double-precision. This is problematical. First (repeating myself) it is chip dependent - and with the proliferation of 'non-Intel' architectures, this is more and more true. Second, it is version dependent. ANY statement of what C or JAVA does or doesn't do should include version numbers. (obviously). Thirdly for some of the more sophisticated language compilers, it may be (fully or partially) customizable.71.29.173.173 (talk) 17:21, 16 July 2016 (UTC)
replies: text: I agree, the reason seems wrong to me. Moreover, the sentence doesn't say when. Vincent Lefèvre (talk) 23:06, 16 July 2016 (UTC)
thread_title:  Advantages & Disadvantages 

message: The second example shows 26, but it should show 20 instead. The section explains exponent bias, and 20 is highly relevant to exponent bias, whereas 26 is unrelated and might as well be a random number. Also the preceding and following examples show the lower and upper limits, and in that context I would (and did) expect the middle example to show the middle. The proposed change certainly would have saved me time, and I suspect it would similarly help others who need to quickly grasp exponent bias. I will gladly make this change if there's no objection. Victimofleisure (talk) 07:26, 24 November 2017 (UTC)
replies: text: I would say: add a 4th example corresponding to 20, at the second position. Thus, there would be: the minimum exponent, the case 20, an example more generic than 20, and the maximum exponent. Vincent Lefèvre (talk) 12:45, 24 November 2017 (UTC)
replies: text: Fair enough. But I still feel it would be helpful to draw attention to the importance of 20. How about adding (zero offset) to the right of the 2nd example? This would connect it visually to the zero offset explanation that precedes the examples. Victimofleisure (talk) 04:45, 27 November 2017 (UTC)
replies: text: Why not, but note that I don't think that 20 has a particular importance, in particular due to the different conventions to represent floating-point numbers. Here, this is the exponent expressed where the significand is between 1 and 2. But in C, the significand is between 1/2 and 1, so that the zero offset (bias) would come from the encoding of 0.12 × 20 = 2−1. And integral significands can be used to, so that in this case, the zero offset (bias) would come from the encoding of 1000...0002 × 20 = 252. Vincent Lefèvre (talk) 11:41, 27 November 2017 (UTC)

text: Noted, and thanks. Simplification can aid understanding, hence it's sensible for all the examples in this section to use the same standard, as they do (IEEE 754).Victimofleisure (talk) 21:19, 27 November 2017 (UTC)
thread_title:  Proposal for minor change to exponent encoding examples 

message: The article starts with:
The status of the alternative names FP64 and float64 is unclear: are these names used for any 64-bit floating-point format or only for IEEE's double-precision format (binary64)? If this is the latter, I think that these alternative names should be introduced only in the paragraph on IEEE's double-precision format (where binary64 is introduced). — Vincent Lefèvre (talk) 23:52, 26 October 2020 (UTC)
thread_title:  Alternative names 

message: I have modified the section about execution speed. It said that functions like sin() are slower, and then continued that “this” is a particular issue on GPUs. This is not the case. The thing with GPUs is that either two single-precision cores are needed for one double-precision calculation, or that (in this case) only one of 16 cores is usable at all for double-precision. Calculations run exactly the same speed on GPUs, but fewer of them can run in parallel. — At the same time it is true that functions like sin() are slower. But this is caused by the algorithms, not the processors. 91.96.31.112 (talk) 19:53, 6 October 2022 (UTC)
thread_title:  Execution speed: Hardware vs. algorithms 

message: I just reverted an edit to IEEE 754 claiming to changed to agree with this. (Even though I don't see where.) IEEE 754 has one significant bit before the binary point, where some previously popular formats have 0 bits before the binary point. If you compare formats, it looks like the exponent is one higher than it actually is, but it really isn't. Does this article need to be changed?  (And the other similar articles.) Gah4 (talk) 07:52, 9 September 2023 (UTC)
thread_title:  exponent in decimal 

message: There seems to be a question on the origination of double precision. Fortran II, though maybe not quite from the beginning in 1958, added the DOUBLEPRECISION statement and data type. (Blanks are not significant in Fortran II code.) It might be possible to track down the data that it was added. ALGOL 60 has a DOUBLE keyword, which I presume declares double precision variables. It might take a while to track down how and when things got added to ALGOL, but it seems likely after 1958. Gah4 (talk) 07:24, 26 September 2023 (UTC)
thread_title:  in the beginning ... 

message: Fortran is usually considered the first high-level language.  Various not-so-high-level languages came earlier. Since Fortran had REAL from the beginning, it should be the first high-level language with a floating point type.  It originated on the IBM 704, the first IBM machine with hardware floating point. I don't know about non-IBM machines. Gah4 (talk) 13:11, 16 November 2023 (UTC)
thread_title:  First