6

That's pretty much my question in the title. It seems totally unnatural for anything else to be used.

In researching this I found that there are historical examples of hardware support for base 10, as well as the more modern examples of IBM POWER6 and system z9. Even in these cases, I do not know if FLT_RADIX would be 10 on any mainstream C compilers.

My particular concern is that I am writing code for an application that will only ever be ran on general purpose computers, and I would like to know if I can statically assert FLT_RADIX==2 without serious concern, like how I am currently statically asserting !(unsigned char)256.

phuclv
  • 37,963
  • 15
  • 156
  • 475
Jack
  • 169
  • 7
  • 1
    What is the purpose of this static assert? Is your program dependent on FLT_RADIX being 2? If so, could you explain what part of your program is dependent on that? I can see the value of statically asserting that chars contain values 0-255 (inclusive-inclusive), but the value of the FLT_RADIX assert is a mystery to me. – juhist Mar 20 '15 at 19:16
  • 5
    I believe IBM has done some work on a decimal floating-point format, using 10 bits to represent 3 decimal digits. It might exist in parallel with binary floating-point. And some IBM mainframes have used a floating-point format where the exponent is a power of 16 rather than 2; I *think* that would imply `FLT_RADIX==16`. (The `unsigned` char assertion could be written as `CHAR_BIT==8`.) – Keith Thompson Mar 20 '15 at 19:17
  • The purpose is that I am using floating types to perform integer arithmetic for performance gains (not exclusively replacing integer types, but using floating types instead in certain circumstances), and the available range of exactly representable integers depends on the number of binary digits available. The considerations are complicated significantly if there may be up to 3 leading zeros (base 16), and even more so if things are in base 10. – Jack Mar 20 '15 at 19:29
  • 2
    @juhist: One technique for finding the exact sum of two floating-point numbers (as a "high part" and "low part") is to compute `high = x+y; err = high-x; low = y-err;` where `x` is the summand with bigger absolute value. This fails, in particular, in radix 10---in two-digit radix-10 floating point, take `x = y = 9.9` and you get `high = 20`, `err = 10`, and `low = -0.10`. – tmyklebu Mar 20 '15 at 19:36
  • @KeithThompson OP's version does have the advantage of not requiring any `#include` . it's unconventional but I don't see a problem – M.M Mar 20 '15 at 20:54
  • @tmyklebu Note: The [sample](https://stackoverflow.com/questions/29174165/is-flt-radix-ever-not-2-in-c11-for-modern-general-purpose-computers#comment46566861_29174165) applies likewise when `FLT_RADIX > 2` (e.g. 10 and 16). So that is not so much a decimal issue as a non-binary one. – chux - Reinstate Monica Oct 25 '17 at 18:58
  • Hardware decimal floating-point support exists in some *general purpose CPU* like Power6 and up, so it may appear in our PCs in the future, but probably via a special type like [gcc's `_DecimalX`](https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html) in order to coexist with the existing binary floating-point types. see also https://stackoverflow.com/q/2234468/995714 – phuclv Jul 03 '18 at 06:27

1 Answers1

3

Annex F, an "optional" part of the C standard that's non-optional for any serious implementation where floating point will be used, requires IEEE single and double precision (binary32 and binary64) for float and double, respectively, so FLT_RADIX should always be 2. On systems where new decimal float stuff is supported, it's a separate extended type; FLT_RADIX==10 is not used for it.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • So the IEEE standard requires binary? I guess I missed that in annex F, or it may be by reference to the IEEE standard itself. Thanks. – Jack Mar 20 '15 at 20:10
  • 3
    Current IEEE standard *also* defines non-binary types, but those are not the ones referred to by Annex F. *F.2 Types* reads: "The float type matches the IEC 60559 single format. The double type matches the IEC 60559 double format." The terms "single" and "double" come from the original version of the standard; these formats have since been renamed to "binary32" and "binary64". – R.. GitHub STOP HELPING ICE Mar 20 '15 at 20:57
  • @Kyle Stewart "IEEE standard" does not require binary. See [formats](http://en.wikipedia.org/wiki/IEEE_floating_point#Basic_and_interchange_formats) and R comment above. – chux - Reinstate Monica Mar 20 '15 at 20:57
  • 3
    @chux: IEEE has issued a lot of standards. The one referred to in Annex F of the C11 standard is "*Binary floating-point arithmetic for microprocessor systems, second edition* (IEC 60559:1989)" – Keith Thompson Mar 20 '15 at 21:04
  • 1
    @chux, your right, I should have been more specific, the 85' standard, according to my reading, does not specify a format that is not binary, though it vaguely specifies two formats which may not be binary (extended single and extended double). However, these extended types can only apply to long double, which annex F does not say much about anyway. – Jack Mar 21 '15 at 07:19