Re: Bit representation of a float

In article <46c2f842.1382768205@xxxxxxxxxxxxxx>,
Richard Bos <rlb@xxxxxxxxxxxxxxxxxxxxxx> wrote:

You can rely on the output making _some_ sense, since the representation
of floating point numbers must follow certain patterns as laid out in
the Standard. You must have a fixed base and precision for each floating
point type, and each FPN must have a sign, an exponent, and a fixed
number of significand digits. However, how these numbers are represented
in the underlying bits is not specified by the Standard, so you may not
immediately recognise the pattern; but it must be there.


I have just reviewed the C89 wording on it, and I'm not -convinced-
that the precision must be fixed.

FLT_RADIX must be a constant. Everything else in <float.h> is
allowed to be non-constant expressions ("non-constant" is specifically
mentioned.)

FLT_MANT_DIG and kin are defined in C89 as

number of decimal digits, q, such that any floating point number
with q decimal digits can be rounded into a floating-point
number with p radix b digits and back again without change
to the q decimal digits

It seems to me that if you had some kind of variable precision, then
FLT_MANT_DIG and kin could be the worst-case numbers, with the
possibility that you might get noticably more accuracy on some values.

The whole s/b/e/p/f[k] floating point model is just that, a -model-,
an abstraction, that need not necessarily be followed internally as long
as you can get the necessary behaviours to work out.


Not that I can see any good reason to implement anything else -- not even
any half-baked reason. But if someone implemented a format that (say)
had variable amounts of significant storage and padded the rest
[e.g., some kind of toaster where 1/32 was the finest resolution needed
for 99% of the calculations], then I don't know that that'd be ruled out.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
.

Relevant Pages

  • Re: Sine code for ANSI C
    ... >> shell script) fully conforming. ... limits mentioned in the standard. ... adding a few more translation limits. ... minimal accuracy requirements for the floating point operations. ...
    (comp.lang.c)
  • Re: compression in floating point arithmetic
    ... If you want to force floating point values to the same type, ... I was thinking that the sequence point stuff could affect in some way this behaviour, it just seemed very reasonable reading the standard, even if not explicitally stated. ... showed me that in the other way the augmented precision can be carried out. ... Of course you don't need to explain to me the entire standard, there was just a specific point I thought it was saying that the truncation was forbidden, so for me it would have been enough that someone could explain me that in this case that point doesn't apply (like for example Jack did when he showed me that the contraction thing was wrong). ...
    (comp.std.c)
  • Re: Rfd: floating point truncation V1
    ... Some other standard I looked at makes "round towards zero" ... an internal representation of floating point negative zero, "-0E", which differs ... to go for an IEEE FP extension). ...
    (comp.lang.forth)
  • Re: Very weird resolution issue. Bug ????? Seriously !!
    ... That's a good example of gray area that IEEE standard cannot ... But floating point accuracy was not my issue. ... Assumption of consistency on 'scientific' software was my mistake? ... guarantees of the standards and documentation. ...
    (comp.soft-sys.matlab)
  • Re: [xpost] a new C/C++ type that when overflow i see it
    ... The standard defines clearly what happens with floating point overflow. ... Obviously there will be implementations of C where the machine has no ...
    (comp.lang.c)