SOS doesn't like the sound of floating point math?

RE: SOS doesn't like the sound of floating point math? (dreamkeeper)

Wed, 10 Sep 2008 15:17:48 GMT

OK, I've done some homework and also followed the links provided (thanks " />). I'm slowly getting the drift where I went wrong with my observations - though it's not totally clear to me yet...

First off, I was confusing value range with dynamic range. Obviously the range of possible sample values (signal level) is much larger for floats than for fixed-point with the same resolution. However, the quantisation noise and thus dynamic range is determined by the precision only - and that's 24bit for a 32bit float. The precision is the number of digits of the significand, including the implicit bit, but without the sign bit (according to Goldberg).

When summing two floats, the accuracy of the result is determined by the difference of the values. For each 6dB difference, there will be 1 bit from the smaller value lost - provided the result isn't held for further calculations in the FPU registers. The absolute value doesn't matter because floats provide the full precision over the whole range. So this means that summing two signals with a difference of ~48dB will merely yield the resolution of an audio CD - 16bit - with regard to the smaller signal. For 64bit summing this would be ~222dB - which provides either much more room to play with or much higher accuracy than 16bit.

A difference of 48dB between sample values (not gain!) doesn't sound very much to me. Taking track and bus gains into account, much higher differences can occur all the time. In my book that makes 64bit mixing almost mandatory. OTOH, multiple tracks/buses going to one destination bus are probably summed in one swoop in the FPU (80bit) anyway, and only the result will be rounded to fit into either 32 or 64 bit. For any further processing the lost bits may or may not make an audible difference.

Once again: a mere 6dB difference and the least significant bit of the smaller value will be lost. This is because each 6dB the exponent increments/decrements, and so the significand of the smaller value needs to be shifted right before summing (yeah, it works when shifting with the implicit bit - which yields a non-normalised number for the moment) to align the exponents. Hence the LSB falls off the grid when the result is rounded (dithered?) and normalised again after the operation.

My apologies for boring you folks " />. I mostly needed to write it down for myself - so I figured, why not littering the forum with it, hehe!

werner

RE: SOS doesn't like the sound of floating point math? (The Maillard Reaction)

Wed, 10 Sep 2008 10:01:39 GMT

Thanks hv!

RE: SOS doesn't like the sound of floating point math? (hv)

Wed, 10 Sep 2008 09:48:33 GMT

http://en.wikipedia.org/wiki/Double_precision

A lot of folks don't seem to realize that 32-bit float format is the minimum precision required to handle 24-bit audio coming from an converter in fixed format. Because it's mantissa contains exactly the right number of bits to store a 0db sample... the 8 exponent bits being unused in that case. If converters ever get greater than 24-bit resolution, 32-bit floats would be inadequate.

Howard

RE: SOS doesn't like the sound of floating point math? (The Maillard Reaction)

Wed, 10 Sep 2008 09:24:11 GMT

Thanks Noel. That was a good read.

Can someone define the term "double precision"?

thanks,
mike

RE: SOS doesn't like the sound of floating point math? (Noel Borthwick [Cakewalk])

Wed, 10 Sep 2008 08:26:19 GMT

For those of you who haven't read the white paper that Ron wrote many years ago I suggest you take a look at it.

Also look through the section at the bottom of this link for some more info:
http://www.cakewalk.com/x64/default.asp

It covers many of the details in this thread.

RE: SOS doesn't like the sound of floating point math? (evansmalley)

Tue, 09 Sep 2008 18:29:05 GMT

Just for the record I am very much for Obama- that was a joke! And I'm for better ways to record music. We're just living in the dark ages and there are many good technical discoveries yet to be created. I have always thought that sampling an analog wave is a functional but primitive representation of it. The wave must be a wave and must resonate, have interference patterns, sympathetic vibrations, resonances, harmonizations, etc- according to the nature of natural waves in air. And it would be good to find a way to record that with good fidelity, not with rust on plastic that is magnetized.

And all the math can be long forgotten. And the Angels will sing along.

But that's probably years away. So I love Sonar!!! It's great in the real world!

RE: SOS doesn't like the sound of floating point math? (evansmalley)

Tue, 09 Sep 2008 16:48:58 GMT

hey John-
How about optically stored analog? with a resolution in the realm of Angstroms instead of kilohertz? Quality audio is just a technical discovery away- there is room for improvement.

Just more inane babbling... none of this stuff really matters- like you say- it's digital now...

so let's elect Mccain! woo hoo!
what's wrong with the status quo anyway?

nah seriously you have a point- I'm just not at all satisfied with digital sound- but the editing is sweet!

RE: SOS doesn't like the sound of floating point math? (John)

Tue, 09 Sep 2008 16:28:26 GMT

probably infinite angles theoretically but I think Angels don't really obsess over math being full of joy and higher knowledge- and we could learn something there probably... but they can learn dancing from us too, because we are having the body.

I do think that math doesn't really sound like music. I've scrutinized the @#%* out of it and I do think the bottom line is that waves behave (and sound) differently than rounded-off equations. People will say (we're in love) that such calculations are far beneath the human ability to perceive theoretically. But I think that musical waves really do sound different than all this theoretical blah blah blah. If you've ever been in an excellent analog signal festival and A/B'd it with a calculation that nearly to the nearest rounding-off point represents it- I hear it. The difference. It's a world apart.

But it doesn't really matter because we're stuck with digital- for now. So let's enjoy cutting splicing editing and all other kinds of cover-yur-butt stuff until we can really create beauty in music. Real beauty can make the angels cry even over the phone... it's all we can offer.

Thats one way to think about it. But I wonder what some musicians thought when Edison invented the Phonograph? It seems to me there is the same old view of anything new. I for one am fully in the digital world and it would take an army to get me back to analog. Why not do it right and go pre solid state and pre transistor. Those were fun times.

RE: SOS doesn't like the sound of floating point math? (evansmalley)

Tue, 09 Sep 2008 16:16:49 GMT

How many Angles dance on the head of a pin?

probably infinite angles theoretically but I think Angels don't really obsess over math being full of joy and higher knowledge- and we could learn something there probably... but they can learn dancing from us too, because we are having the body.

I do think that math doesn't really sound like music. I've scrutinized the @#%* out of it and I do think the bottom line is that waves behave (and sound) differently than rounded-off equations. People will say (we're in love) that such calculations are far beneath the human ability to perceive theoretically. But I think that musical waves really do sound different than all this theoretical blah blah blah. If you've ever been in an excellent analog signal festival and A/B'd it with a calculation that nearly to the nearest rounding-off point represents it- I hear it. The difference. It's a world apart.

But it doesn't really matter because we're stuck with digital- for now. So let's enjoy cutting splicing editing and all other kinds of cover-yur-butt stuff until we can really create beauty in music. Real beauty can make the angels cry even over the phone... it's all we can offer.

RE: SOS doesn't like the sound of floating point math? (kwgm)

Tue, 09 Sep 2008 13:41:27 GMT

ORIGINAL: dreamkeeper

Yeah, I'm familiar with the hidden or implicit bit. If I'm understanding correctly, the method you described requires that the same (or at least nearly the same in the case when lower bits are lost) value can be represented by two different binary numbers, yes? But that's not the case with IEEE floats. Only numbers close to the range boundaries can be almost redundant, for example:

0-01111101-11111111111111111111111 = 0.49999997
and
0-01111110-00000000000000000000000 = 0.5

I don't see any way to get from the 1st to the 2nd by shifting - hidden bit or not. And again, the further you get away from the range boundaries, the bigger the smallest-possible difference between two IEEE numbers with different exponents. I guess the answer is "42"... " />

Every computer engineer has to sit through a course in number theory and calculate the error in different floating point encoding schemes, and I recall some very dry days in graduate school when I examined specific floating point emulation algorithms in the Motorola 68000 library in great detail, but that part of my memory hasn't had a refresh cycle in almost 30 years. I'm not going to look this up, because it doesn't really matter, but what I do recall is that most 32-bit systems use a 23/24bit mantissa, and undergo something called "Von Neumann rounding" at the 23/24bit cusp. This 32-bit representation of FLOAT is or should I say, was, very commonly used for over 20 years, afaik. All that might have changed in the late 1990s when Microsoft took the lead in OS design, I don't know -- by then I worried little about the minutia of OS implementation.

Boiled down to simple English, the round-off error in a typical 32-bit floating point operation has an error that going to be in the neighborhood of 1 part in 4 million, which is a very small and negligible error in most cases. So, it's an interesting thought problem, but not relevant to your day-to-day work.

RE: SOS doesn't like the sound of floating point math? (SteveStrummerUK)

Tue, 09 Sep 2008 13:32:33 GMT

ORIGINAL: John

How many Angles dance on the head of a pin? I'm sure you guys have an answer.

LOL - now I'm really confused by all this data and equations stuff - 'tis a long long time since I did anything like this at school!

I always thought 'Do the Math' was dancing to When a Child is Born " />

RE: SOS doesn't like the sound of floating point math? (gdugan)

Tue, 09 Sep 2008 13:10:39 GMT

ORIGINAL: bitflipper

Well, a lot of this falls into the category of angels dancing on the head of a pin. In discussions about the minutia of digital audio processing, you rarely hear anybody ask "yes, but can you actually hear that?".

But like somebody pointed out in my dither-don't-matter thread, you still take these things into consideration even though they're trivial concerns individually, because the quality of the end product is the sum of many little things, not any one big thing you did. Just like you take care when performing each and every part of a song, despite knowing that it might end up ultimately buried in the mix.

The takeaway from this conversation, I think, is simple: leave yourself plenty of headroom at every step of the way.

Hey Dave,
Thanks so much for your clear and detailed explanations of some stuff that's not exactly intuitive. I always look forward to reading your posts.

RE: SOS doesn't like the sound of floating point math? (The Maillard Reaction)

Sun, 07 Sep 2008 08:09:36 GMT

But we already new that part :-)

I wanted t learn something I didn't know.

Thanks again everyone!

RE: SOS doesn't like the sound of floating point math? (j boy)

Sat, 06 Sep 2008 23:19:44 GMT

ORIGINAL: bitflipper

The takeaway from this conversation, I think, is simple: leave yourself plenty of headroom at every step of the way.

That's it alright.

RE: SOS doesn't like the sound of floating point math? (kb420)

Sat, 06 Sep 2008 20:09:11 GMT

ORIGINAL: LostChord

You've lost me here.

Maybe have a look at this: http://en.wikipedia.org/wiki/IEEE754

There are a number of things going on when using the nice little simulator:

(1) The exponent is biased, so what you are seeing is not the real thing.
(2) It's going to obey the IEEE754 conventions so you will not be able to get it to cough up the alternative representations that will be used in the FPU.

I think this is part of the confusion. So I think you will not be able to use it to demonstrate this. Lets look at your previous example, here's what you saw:

00111111010000000000000000000000 = 0.75
right-shift the fraction:
00111111001000000000000000000000 = 0.625

This is what was happening (I've included the hidden 1 as (1)):

001111110(1)10000000000000000000000 = 0.75
right-shift the fraction:
001111110(1)01000000000000000000000 = 0.625

Make any kind of sense?

No, it doesn't make sense at all. Have a look at this. It explains it all:

data=yâ€˜â€˜}*,********9******VÂ¯Ã¬Â§+H+ â„¢Å“Å’â€œÂ****+nÃ–******ÂºÂ******Ã³+yâ€˜â€˜}**********9**+***Â±=SÃªG9ÃŽ)))))))))))))_- â„¢Å“Å’â€œÂa***kyeJâ€¹â„¢~Å¸â‚¬JÅ’^Jâ€¦\ZZ
_Z`[aâ€¡JRÅ’â€¹ÂÂÅ½Jâ„¢ËœJâ€šâ€œÅ¡â€™XyÅ“â€˜QÂJâ€“â€œÅ’â‚¬â„¢Å“Å’â€œÂS2***0***~s~vog1***k|~s}~g0***kvlwg6***~|kmuxwlo|g5***~|kmu~y~kvg/***nk~og0***qox|og2***my
wwox~g+/ â„¢Å“Å’â€œÂIlmâ‚¬+**+*>Ââ‚¬SÂÃƒ|Â¼â€¦Â´CÂÃ‚[â€˜CÂÃ¾â€žÂ´OÂ®>lRÃÂâ‚¬â€¦Ã•SÃŸÃ„â€žÃ´Ã£Ã¯Ã†ÂÃ¸Â¿Å’|SoÃƒ|zâ€¦Â´CÂ|S0C}<â€¦â€œKÂ®>l1Ã‹Â<â€¦â€œÃ—Ãâ€žâ€cÃ Ã†ÂÃ—Â¿|xSÃŽB}Â²tÃ‚|vSÃŽB}Â´tÃ†ÂÃºcÃ†
}Â¶t2_Â¿â€ž}Ã³[Â¯Â¾â€¦uSÅ¾xl1Ã“Â®Ã¸|uÃ›Å¾Âºt1OÅ¾zdâ€¢cÂ¿<}SÃ‡Ââ‚¬lâ€Ã£ÃF}Ã´Ã—ÃÃ‚ÂÂ¶Â«ÃºÂº**+*Ãªj:DÃœ4*z**:Â°Ã‹RÂ´,Â®Â°Ã–,*\**.= RÂ¸ RÂ¼LcÂ¼Âc@:DÃœ4**,*:**ÃªÅ¡>sÂ»>ÃµÃ»FwÃ¼VÃ·Ã¼f}Ã€Â
Æ’Ã€ÂÆ’Ã€ÂÆ’Ã€â€¡Å¸â€¡J^Å½?**+*jR1CÃ¯B:Â®Â¾Ãœ<27Æ’/*J***Â¬RÃ:-lmâ‚¬+**+*2{HKÃ‹ÃÂ¥;Å“HKGÂÂ¥KÃžË†cÃ‹ÃŽÂ¥Ã§!HÂ¥Ã£!Â¥Â»â€¹Ë†KÃ‹Â½Â¥;Å’FCÃ¯ÃƒÅ“Â¥KÃŽÃ†[Ã‡ÂÂ¥Ã§!ÃˆÂc
Â¥Ã‡ÃkÃ“Ã¾Â¥Â¿Â½Ë†[Ã‡ÃË†Â¥OÃ¿HlÃÃŽÂ¥Ã§!Â¥Ã§!Â¥Ã§!ÃˆÂ¥Ã§!Â¥Ã—â€Ã§!Â¥Ã§!Â¥Ã§!Â¥Ã§!Â¥Ã§!Â¥Â«ÃºÂº**:**â€¹B`Â²â€ºÃ±ÃŽ!Â¥â€¹Ã‚QÂ°â€œÃŽ!ÃˆÂ¥Ã’â€˜6Â¤4Ã›!ÃˆÂ¥Ã§Â¥
Ã§!Â¥J^Å½?**2**KÂ®:|rKÂ¯>|rKÂ°BÅ’Ã²KÂ±FÂ¬2TÃ“ÃŽÃŒÂ´TÃ”Ã’ÃŒÂ´TÃ”VÃÂ¶\Ã´RÂ½Â¶\Ã´VÃÂ¸dÃ’ÃÃ¸l4SÃŽÃ¼t5Ã—Ãž~â€¦â„¢WÃ¿HÂ®:l2KÂ®:l2KÂ®:Ã¨!H27Æ’/*Âª**ZÃ°BÂÂ¶k2KÂ®:lrSÃÂ¾Å’Â´SÃÃ‚,lmâ‚¬+*Âª*
*,***VsÂ½^qÂfÃ±ÂfÃ±}fqÅ¾nqÅ¾nqÂ¾nsÃžnwn{^oÃžoÃ¾wÃ¾wâ€¡Ã¿wÃŸâ€¦Ã Ââ€¡â€¡â€¡Ââ€¡=Ââ€¡Å¸â€¡Å¸â€¡Å¸â€¡Å¸â€¡Ã¡Â«ÃºÂº**2**â€¹Âºk0CÂ®:lrKÂ¯Â¾|Â´[Ã°BÂÃ¸cJ^Å½?**2*J***jâ€º>qâ€ºFÃ³Â»NÃ³
ÃœVÃ·VÃ¹<_}]_}Â_ÂÂoÂÅ¸wÅ¾Å¸wÅ¾wÂÅ¾Å¸â€¡ÂÅ¸Å¸â€¡Å¸â€¡^â€¡Å¸â€¡Ã½Å¸â€¡Å¸â€¡Å¸â€¡Å¸â€¡A27Æ’/*r**bÂ¸=#bÂ¸=#bÂ¸=#bÂ¸N+Ã‹KÃ•**C**+*RÂ´ bÂ¸=#bÂ¼NsÃ€ÃÆ’Ã„Æ’ÃŒPâ€ÃŒÃ’Â´Ã˜,Ã‹KÃ•**

RE: SOS doesn't like the sound of floating point math? (AndyW)

Sat, 06 Sep 2008 19:59:34 GMT

ORIGINAL: John

How many Angles dance on the head of a pin? I'm sure you guys have an answer.

42. I did an experiment.

RE: SOS doesn't like the sound of floating point math? (Kicker)

Sat, 06 Sep 2008 19:52:03 GMT

ORIGINAL: bitflipper

[Consider that we're limited to the same 31 bits as an integer value (1 bit is the sign bit, so we really have only 31 bits to play with), and yet the float can represent a much larger number than the same 31-bit integer. How is this possible? It's because floats sacrifice accuracy for range. It's a fundamental flaw in the way computers do arithmetic.

Not to pick a nit, but the PC's binary numbering system uses a 2's complement system to represent negative integers.

RE: SOS doesn't like the sound of floating point math? (Mr. Ease)

Sat, 06 Sep 2008 19:14:33 GMT

I went through the whole thing of dynamic range (precision), implicit bits etc. some time ago. Here is the thread.

As you will see my particular problem was with the implicit bit as you don't get something for nothing. The "something" gained (i.e. implicit bit) does limit the range of the exponent and creates the denormalised number range but we do get the extra bit. Post 163 explains this quite clearly.

Otherwise there are good arguments regarding precision of the mantissa (c.f. dynamic range) and range of the exponent.

Hope that helps some of you get your heads round this.

RE: SOS doesn't like the sound of floating point math? (The Maillard Reaction)

Sat, 06 Sep 2008 17:20:31 GMT

I have to admit the discussion has gotten over my head but I am very much enjoying trying to follow along.

Thanks to everyone for their contributions to the discussion.

best regards,
mike

RE: SOS doesn't like the sound of floating point math? (dreamkeeper)

Sat, 06 Sep 2008 02:47:39 GMT

(1) The exponent is biased, so what you are seeing is not the real thing.

Yup, I know.

(2) It's going to obey the IEEE754 conventions so you will not be able to get it to cough up the alternative representations that will be used in the FPU.

Yup. Though I'd like to know what's going on there, and in which case there's a significant loss of detail (lower bits). It seems that losing bits does occur when summing two vastly different values, but it's not that straightforward as with shifting like fixed-point.

00111111010000000000000000000000 = 0.75
right-shift the fraction:
00111111001000000000000000000000 = 0.625

This is what was happening (I've included the hidden 1 as (1)):

001111110(1)10000000000000000000000 = 0.75
right-shift the fraction:
001111110(1)01000000000000000000000 = 0.625

Not sure I get your point there... That's the same I said, no?

Anyway, I'll dig deeper soon. I'm off til Monday - cu " />

RE: SOS doesn't like the sound of floating point math? (LostChord)

Sat, 06 Sep 2008 01:50:20 GMT

You've lost me here.

Maybe have a look at this: http://en.wikipedia.org/wiki/IEEE754

There are a number of things going on when using the nice little simulator:

(1) The exponent is biased, so what you are seeing is not the real thing.
(2) It's going to obey the IEEE754 conventions so you will not be able to get it to cough up the alternative representations that will be used in the FPU.

I think this is part of the confusion. So I think you will not be able to use it to demonstrate this. Lets look at your previous example, here's what you saw:

00111111010000000000000000000000 = 0.75
right-shift the fraction:
00111111001000000000000000000000 = 0.625

This is what was happening (I've included the hidden 1 as (1)):

001111110(1)10000000000000000000000 = 0.75
right-shift the fraction:
001111110(1)01000000000000000000000 = 0.625

Make any kind of sense?

RE: SOS doesn't like the sound of floating point math? (dreamkeeper)

Sat, 06 Sep 2008 00:59:09 GMT

Yeah, I'm familiar with the hidden or implicit bit. If I'm understanding correctly, the method you described requires that the same (or at least nearly the same in the case when lower bits are lost) value can be represented by two different binary numbers, yes? But that's not the case with IEEE floats. Only numbers close to the range boundaries can be almost redundant, for example:

0-01111101-11111111111111111111111 = 0.49999997
and
0-01111110-00000000000000000000000 = 0.5

I don't see any way to get from the 1st to the 2nd by shifting - hidden bit or not. And again, the further you get away from the range boundaries, the bigger the smallest-possible difference between two IEEE numbers with different exponents. I guess the answer is "42"... " />

RE: SOS doesn't like the sound of floating point math? (LostChord)

Fri, 05 Sep 2008 23:58:20 GMT

Nice applet " />

What is causing the confusion here is the 'hidden bit' which I think was mentioned somewhere in this thread. The high order bit is always assumed to be 1 in the mantissa and so what you are seeing is all the bits after this assumed 1.

To see this in effect enter 128 in the decimal field on the form and press return. Notice the binary value of the mantissa... zero.

My vague memories of how this works comes from implementing floating point on an MC6800 (8 bit architecture) in the mid 70s. May have some differences compared to current implementations but (I hope) not too many.

RE: SOS doesn't like the sound of floating point math? (dreamkeeper)

Fri, 05 Sep 2008 23:33:18 GMT

ORIGINAL: LostChord

Right shifting the mantissa one bit divides it by two.

Nope! Because you would only shift the fraction. Try it yourself: IEEE 754 Converter

Just don't try and do it in decimal! Or if you do make sure it's ALL in decimal (base 10).

I didn't do it in decimal, I just posted only the decimal values of the IEEE floats:

00111111010000000000000000000000 = 0.75
right-shift the fraction:
00111111001000000000000000000000 = 0.625

now increment the exponent:
00111111101000000000000000000000 = 1.25

Am I missing something? Methinks that must work differently somehow...

All good fun.

Ha! You bet! " /> (btw: I like your sig)

RE: SOS doesn't like the sound of floating point math? (LostChord)

Fri, 05 Sep 2008 22:31:34 GMT

Right shifting the mantissa one bit divides it by two. Incrementing the exponent by one multiplies it by two. Example:

(2^3)*8 = (2^4)*4

Just don't try and do it in decimal! Or if you do make sure it's ALL in decimal (base 10).

An interesting side effect of this is that with floating point you can get effects like:

(a+b)+c <> a+(b+c)

where b and c are small compared to a.

All good fun.

RE: SOS doesn't like the sound of floating point math? (dreamkeeper)

Fri, 05 Sep 2008 21:45:32 GMT

That's basically what I meant to say, but brushed over it a bit (no pun this time). Yeah, that makes sense, the resolution for the sum must be determined by the larger number. Thanks for clarifying.

EDIT: Err... wait, wait! It doesn't work like this... You cannot adjust the exponent and shift the mantissa to compensate. Because the mantissa is NO INTEGER! Right-shifting does NOT halve the whole value - it only halves the offset relative to the "range-boundary" that's determined by the exponent. For example right-shift the mantissa of 0.75 (exp=-1 and range 0.5 - 0.99999994) one bit and you get 0.625 - no way to get even close to 0.75 by changing the exponent. Guess I have some reading to do, oh well... " />" />

RE: SOS doesn't like the sound of floating point math? (LostChord)

Fri, 05 Sep 2008 20:52:23 GMT

That's only relevant when summing very large and very small values though - which IS the justification for 64bit (there must be a paper or a post by Ron Kuper about this somewhere). The small value might fall off the grid, so to say, or contributes only its upper bits to the sum.

It's more the relative maginitude between the two numbers. From memory when you add two floating point numbers the smaller has its mantissa right shifted incrementing the exponent for each bit shifted. When the exponents are equal the addition takes place. If the difference in the exponents is such that the entire mantissa in the smaller number gets shifted into the bit bucket then zero is added.

RE: SOS doesn't like the sound of floating point math? (dreamkeeper)

Fri, 05 Sep 2008 20:16:40 GMT

ORIGINAL: rosabelle

Wait wait wait! I think I know where I went wrong, and what bitflipper was getting at!

You DO lose precision when the exponent changes. That's the transition into a new, wider (or narrower) range. So the numbers in one range are closer together (or further apart) than the numbers in another, wider (or narrower) range.

That's only relevant when summing very large and very small values though - which IS the justification for 64bit (there must be a paper or a post by Ron Kuper about this somewhere). The small value might fall off the grid, so to say, or contributes only its upper bits to the sum.

Except that as the bits are flipping, every time the implicit bit would have changed, the exponent changes instead. Then when the exponent reaches a certain point you get denormals where the implicit bit is 0. So the implicit bit and the exponent kinda work together to create that full 25 bits of resolution at the expense of less range.

I don't think that's correct. Denormals only occur below the smallest normalised value (2^-126). Above that the implicit bit is always 1. I'm talking positive values only, to make it not too confusing (for me, hehe!) - my head's spinning already...

werner

RE: SOS doesn't like the sound of floating point math? (John)

Fri, 05 Sep 2008 20:14:34 GMT

How many Angles dance on the head of a pin? I'm sure you guys have an answer.

RE: SOS doesn't like the sound of floating point math? (rosabelle)

Fri, 05 Sep 2008 19:51:10 GMT

ORIGINAL: dreamkeeper

For each range you outlined, they are all represented by a mantissa of 25 bits which I call the resolution.

Not quite. The implicit bit surely is needed to calculate the actual value. But it never changes and hence doesn't increase the number of values. The latter is determined by the fraction plus sign-bit only: 24 bits.

Except that as the bits are flipping, every time the implicit bit would have changed, the exponent changes instead. Then when the exponent reaches a certain point you get denormals where the implicit bit is 0. So the implicit bit and the exponent kinda work together to create that full 25 bits of resolution at the expense of less range.