OSDev.org

No call for help, just being curious.

Does anybody know what the FLT_GUARD and FLT_NORMALIZE macros mean? You can find them in many <float.h> versions but they are not standard. Borland defines both as 1, Microsoft as 0. They are mentioned in the MSDN but without explanation.

Roel

I could find FLT_NORMALIZE - it defines whether all floating point values are normalized (i.e. no denormals): http://tigcc.ticalc.org/doc/float.html#FLT_NORMALIZE

I couldn't find anything about GUARD either. I also couldn't find either in MinGW's and Cygwin's libc, together with the absence in C'99 makes the bottom line read "don't bother", IMHO.

Hi Combuster, thanks for your reply.

Combuster wrote:I could find FLT_NORMALIZE - it defines whether all floating point values are normalized (i.e. no denormals): http://tigcc.ticalc.org/doc/float.html#FLT_NORMALIZE

If I'm not mistaken, the 80x87 always automatically normalizes floating point values, which makes me wonder why MSVC defines FLT_NORMALIZE as 0.

Combuster wrote:I couldn't find anything about GUARD either. I also couldn't find either in MinGW's and Cygwin's libc, together with the absence in C'99 makes the bottom line read "don't bother", IMHO.

I've never seen them used either. They're probably a fossilized product from era's long gone, so I guess you're right.

Hobbes wrote:If I'm not mistaken, the 80x87 always automatically normalizes floating point values

You're probably thinking of something else: http://en.wikipedia.org/wiki/Denormal

Combuster,
I'm not sure if I understand you correctly. What do you think I was referring to?

Floats are stored as a mantissa and an exponent part.

With normalized floats, the value of the float is 1.{mantissa} times 2^{exponent}.

With denormalized floats, the value of the float is 0.{mantissa} times 2^{exponent}.

I.e., denormalized floats can represent values closer to zero than normalized floats can.

You "normalize" a float (on paper) by shifting the mantissa to the left (and reducing the exponent) until the first set bit is shifted out to the left (becoming the implicit leading "1" of a normalized float).

AFAIK, not all FPU's can handle denormalized floats, so it's a configuration thing.

The thing here is that implicitly forcing an 1.(mantissa), you force that a certain precision is always achieved. with 0.(mantissa), you can have the first mantissa bits zero and lose precision bits at the end, while you might be able to shift the mantissa left and decrease the exponent, to get the same number with more precision bits.

Point here is, denormals have less accuracy than normalized numbers; the former may have leading zeroes and it always loses a significant bit where normalized numbers have the leading 1.*. A problem with normals is that there's no "zero" - the closest would be something like 1 * 2^-511 (depending on exponent bits). So what they did is make the lowest exponent select normal or denormal mode.

The point here is that the x86 FPU does both normals (for nonzero floats and doubles) and denormals (long doubles and values near zero), effectively giving the "uses normalized floats" definition an ambigous interpretation, since normalized floats are only used in a subset of cases (even when excluding ±zero, ±INF and NaNs).

Combuster,
Are you referring to the extended precision having an explicit 1 bit instead of an implicit one? Because that's what makes normalizing necessary. You can't normalize a denormalized single or double precision.

Are you referring to the extended precision having an explicit 1 bit instead of an implicit one?

I think we were discussing FLT_NORMALIZE, and not LDBL_NORMALIZE , but yes, long doubles have an explicit bit but are still forced to be normalized.

Hobbes wrote:You can't normalize a denormalized single or double precision.

Yes you can - you can make it zero. Incidentally, that behaviour is a feature of several SSE implementations (look for denormals-are-zeroes and flush-to-zero)