Talk:Floating-point arithmetic/Archive 2

message: I'm having a tiny problem with the pi example, the sentence "Hence the floating-point representation would start with ..." irritates me a little. Instead of merely cutting away behind the last digit I'd prefer rounding instead:
11.001001000011111
is the number with an extra digit. Simply cutting away the last digit gives
11.00100100001111
That's about 3.14154053, which is about -5.2E-5 away from pi.
Rounding up the last digit instead gives
11.00100100010000
That's about 3.14160156, which is about 8.9E-6 away from pi.
Is there something I've missed? --Nikai 22:24, 14 Apr 2004 (UTC)
replies: text: You're quite right, especially as there are non-zero bits 'out there to the right' of the original 17.  The smallest fix would be to add 'in a representation which did not allow any rounding...' or something like that. mfc 15:25, 16 Apr 2004 (UTC)

text: This is the "exponent offset" of 127 referred to in the "computer representation" section.  The bit pattern stored in the exponent field of the number in the computer is not the same as the exponent that we mean when we say things like "18.75d = 1.001011 * 2**4".  It is always higher by 127 (in single precision.) William Ackerman 23:55, 17 August 2006 (UTC)
thread_title:  binary rounding 

message: ==== howto find the exponent ====
 In order to convert -18,75 into 32 bits:
 18d = 10010b
 0,75d = 2**-1 + 2**-2 = 1/2 + 1/4 = 0,11b
 ---> 18,75d = 10010,11b =  1,001011 * 2**4
 Sign: Négatif      = 1
 Exposant: 4        = 4d + 7Fh = 83h = 100 000 11 b     Why add 7Fh (0111 1111b) ?
 Mantisse: 001011   = 001 0110 0000 0000 0000 0000
 Hence, -18,75 is 1 10000011 001011 000 000 000 000 000 00(binary) or  C196000(hexa)
 bit number      =1 23456789 012345 678 901 234 567 890 12 = 32bits              
Why add 7Fh (0111 1111b) ? []
:This is the "exponent offset" of 127 referred to in the "computer representation" section.  The bit pattern stored in the exponent field of the number in the computer is not the same as the exponent that we mean when we say things like "18.75d = 1.001011 * 2**4".  It is always higher by 127 (in single precision.) William Ackerman 23:55, 17 August 2006 (UTC)
thread_title:  base2 to base10 

message: In order to convert -18,75 into 32 bits:
 18d = 10010b
 0,75d = 2**-1 + 2**-2 = 1/2 + 1/4 = 0,11b
 ---> 18,75d = 10010,11b =  1,001011 * 2**4
 Sign: Négatif      = 1
 Exposant: 4        = 4d + 7Fh = 83h = 100 000 11 b     Why add 7Fh (0111 1111b) ?
 Mantisse: 001011   = 001 0110 0000 0000 0000 0000
 Hence, -18,75 is 1 10000011 001011 000 000 000 000 000 00(binary) or  C196000(hexa)
 bit number      =1 23456789 012345 678 901 234 567 890 12 = 32bits              
Why add 7Fh (0111 1111b) ? []
:This is the "exponent offset" of 127 referred to in the "computer representation" section.  The bit pattern stored in the exponent field of the number in the computer is not the same as the exponent that we mean when we say things like "18.75d = 1.001011 * 2**4".  It is always higher by 127 (in single precision.) William Ackerman 23:55, 17 August 2006 (UTC)
thread_title:  howto find the exponent 

message: In the section "Problems with floating point" it says that the literal 0.1 is unrepresentable, I'm not quite understanding this, can someone please explain? - Xgkkp 18:36, 5 October 2005 (UTC)
thread_title:  Literal 0.1 unrepresentable? 

message: Most implementations of floating-point numbers do not only specify how such numbers are represented but also specify what results operations on them must produce. More precisely, one usually requires a op_f b:= rnd(a op b)
for any two floating-point numbers a,b, and any (here binary) operation op (like +, -, /, *, sqrt, etc.). Here, rnd is the function that rounds its argument to the closest floating-point number, and op_f is the operation op for floating-point numbers.
I wonder whether the article should not at least mention this "fundamental property" because it is this very property that allows us to analyze what a calculation actually does! For instance, the requirement "a op_f b:= rnd(a op b)" implies that (for normalized numbers) a op_f b = (a op b) (1+eps) where |eps| is bounded. Using this, you can perform an analysis of what a formula like ((a +_f b) -_f c) *_f d), for instance, actually computes.
I know that not all implementations of floating-point numbers require a op_f b:= rnd(a op b) (I think GNU MP does not, but there are "patches" that make it do so). Nonetheless, IEEE 754 does respect it (at least for normalized numbers, if I am not mistaken). Adding a section on this "fundamental property" (anyone has a better name?!) would, I think, help a lot to understand that we CAN work and calculate with floating-point numbers (and do not have to HOPE that it is going to work well).
(I am willing to write something, of course, with your help, but would like to first ask what you think of the idea.) hbf 02:14, 25 November 2005 (UTC)
thread_title:  Shouldn't we mention how operations on floating-point numbers are (usually) carried out? 

message: I added a link to the closely related Scientific notation. I noticed it is already linked in the text but I thought there should be a specific link seeing as the two are so closely related.HappyVR 16:40, 11 March 2006 (UTC)
thread_title: Scientific notation

message: I removed the following comment left by an editor without account at the article:
:This is all very interesting, but how are they stored? Many people wish to know this!
I do hope somebody will write about the "fundamental property", mentioned above, and perhaps give more details about the implementation. -- Jitse Niesen (talk) 03:25, 20 March 2006 (UTC)
thread_title:  Implementation 

message: I removed this :
"A floating point number can be seen as a large integer, were the most significant bit is stored, then the number of the following identical bits, and then the remaining bits. Additionally, a constant denominator is defined to allow for fractions, and a constant bias to have a zero."
Not saying it's wrong - just questioning whether it helps explain anything?
Seems (to me) to be describing a different method of storing numbers - it's definately not clear to me.HappyVR 19:57, 23 March 2006 (UTC)
thread_title:  ? 

message: "Cancellation - subtraction between nearly equivalent operands"
subtraction of equivalent operands does what? Does it yeild 0? That should be explicit. Fresheneesz 19:43, 25 May 2006 (UTC)
thread_title:  problems - cancelation 

message: Why is the example not in IEEE standard? Is it in any standard? Why would we do it that way on this page when a better standard exists? Fresheneesz 19:44, 25 May 2006 (UTC)
thread_title:  example - not IEEE standard 

message: "which is called the significand or, informally, mantissa"
At Talk:Significand, I assert that mantissa is not the same thing as a significand, nor is it informal. Please discuss there. Fresheneesz 20:01, 25 May 2006 (UTC)
thread_title:  mantissa - not informal 

message: I think there should be a clear distinction on this page between base 2 and base b. Floating point numbers are, by far and away, mostly used in binary number representation. We should have a general definition using an arbitrary base, but in computers, the base is 2, and that should be the focus. Fresheneesz 20:05, 25 May 2006 (UTC)
thread_title:  Base 2 vs base ''b''