Talk:Half-precision floating-point format
This page confuses increased and decreased precision. Surely increased dynamic range is double-precision : what does 'precsie' mean ? Half-precision reduces storage requirements instead !
ie Half of what ? Hmmm ... Maybe they should be one page ?
=> To me it was perfectly clear: the precision is the amount of bits/digits past the floating point. An integer is very unprecise, because between every two integers there's a big range of other numbers. e.g. what if you want to drink 3.5 glasses of milk instead of 3 or 4? An integer is not precise enough to represent this. A single precision floating point has no problem with 3.5, or even 3.000 005 (dunnow the exact amount of zeros allowed, but my point is clear). Single precision takes up 4bytes/32bits though, so it's quite memory hungry. To combine the best of 2 worlds (small memory footprints of ints but good precision of singles/floats), half precision float/a float with 16bits/2bytes memory representation is ideal. You trade the loss of precision for the gain in less memory footprint. Indeed, with those 2 bytes, 3.000 005 is not representable. 3.05 is representable though.
Hardware Support for HP?
Is anyone aware of actual hardware providing native support for half-precision floating-point datatypes? This would be a helpful information to be added.
129.27.140.172 (talk) 15:35, 5 November 2009 (UTC)
precision with large numbers
quite clever, pulling the equivalent of a 40-bit integer out of a 16-bit space, but accuracy must surely suffer at the high end? if the largest figure is ~65500 with 10 (11?) bits of mantissa, are we moving in steps of 64 (32?) up at that end? are we not then sacrificing accuracy of representation for wide range? 193.63.174.10 (talk) 09:46, 18 October 2010 (UTC)
- (I mean - a 16 bit, unsigned integer at that point would move in single steps, being 32-64x more precise; every number beyond ~1024/2048 is in fact less precise than the integer form, and we're not able to represent "halves" until 512/1024 or less, and full single-place decimal to about 100/200) 193.63.174.10 (talk) 09:52, 18 October 2010 (UTC)
- Also, what of 20 or 24bit precision? Are there no standards for using that in either integer or float form? The number packs in to 2.5 or 3 bytes, we get somewhat better precision and the same or a wider range, without using quite so much space. Or even 21-bit (RGB+very simple transparency in 64 bits; 18/19/20 to give RGB+4/7/10bit transparency with HDR... or even 17/13 (4x half would be 16/16 of course)... i'd probably err towards 19/10 or even 19/20/18/10 RGBA) 193.63.174.10 (talk) 09:57, 18 October 2010 (UTC)