Float comparison

[Nate Eldredge]

For everything that follows you don't need the axiom of choice.

Let Z be the set of integers. There is a bijection f: R -> ZxR
where x denotes cartesian product. We define an ordering <=' on
R as follows:
For x,y in R , x <=' y iff
( f(x) = (i , x1) f(y) = (j , y1) and
( x1 < y1 or ( x1 == y1 and i <= j ) )
)

For every real x with f(x) = (i , x1) the immediate predecessor
is y where f(y) = (i-1 , x1) and the immediate successor is z
where f(z) = (i+1 , x1)

Ok, good. I guess we could be more concrete: for x in R, let I(x) be
the integer part of x and F(x) be the fractional part. Then the map
f(x) := (F(x), I(x)) is a bijection from R to [0,1) x Z, on which we can
put the lexicographic ordering (so 2.01 <' 1.02 <' 2.02 <' 1.03). The
immediate neighbors of x are x+1 and x-1.

 

[Keith Thompson]

Come on now. "the difference between 1 and the least value greater
than 1" spells out an area not representable in that fp system.

Yes, that's exactly what it means. There are no floating-point
numbers of type double between 1.0 and 1.0+DBL_EPSILON.

The uncertainty in the value includes at least that, and we haven't
even worried about values less than 1.

No, there is no uncertainty in the value. The value is what it is, as
defined by the model in the C standard. The real value of the FP
number 1.0 is exactly 1.0, no more, no less. The real value of the FP
number exactly 1.0+DBL_EPSILON is 1.0+DBL_EPSILON, no more, no less.
There are no FP numbers (of type double) between those two values.
(The reals are dense; FP numbers are not.)

... snip ...

I see no way of storing a value within the 'range' in a FP value,
and being able to read out that exact value. NOT the FP value.

Sorry, I don't know what that means. What 'range' are you talking
about?

Of course you can't store a non-representable real value in an FP
object and then retrieve that same value. You can't really even try.
You *can* store a representable value in an FP object and then
retrieve that exact value. "An object exists, has a constant address,
and retains its last-stored value throughout its lifetime", remember?

Alright so far.

Thank you.

You have left out a condition that applies to floats.

No, I haven't, and so what if I have? I'm talking about PRNs, not
floats.

(I just realized that "PRN" can also stand for pseudo-random number; I
think the context is sufficiently clear to avoid any confusion.)

The ranges
are all separate.

What ranges? PRNs do not correspond to ranges; each PRN value
corresponds to a unique real value.

There is no real number that belongs to more
than one range, which range corresponds to an exact value
recorded. This makes it possible to pick a unique value to
represent ANY real.

Sorry, you've completely lost me. PRNs correspond only to a discrete
finite subset of the real numbers. For example, there is no PRN that
corresponds to the real value one-third.

Yes. See the paragraphs above. By leaving out uniqueness you
abandon the < and > logical operations.

What part of "please quote the exact wording from the standard" are
you having trouble with? And what do you mean "leaving out
uniqueness"?

The < and > comparison operators can be applied to PRNs in an
extremely straightforward manner.

Let x and y be two PRN values. Let rx and ry be the corresponding
real values for x and y, respectively. If rx < ry, then x < y.
If rx == ry, then x == y. If rx > ry, then x > y. (Note carefully
the lack of the word "range".)

I think that is enough
difference. You don't have anything that says that PRN represents
all values between (PRN + deltaH) and (PRN - deltaL).

No, of course I don't.

The C
standards description of EPSILON covers that, and forces the
existance of a 'range'.

No. It. Bloody. Well. Does. Not.

If it did, you would be able to cite wording from the C standard that
proves it. I''ve literally lost track of the number of times I've
asked you to cite the standard to support your claims. You have
either ignored my request, or cited sections of the standard that
either are completely irrelevant or directly contradict your claims.

And if you can't do so, then I can only assume that you're talking
about your own personal model of floating-point numbers, a model
that is inconsistent with the one defined by the C standard.
In that case, I suggest that since you're not talking about C,
you should take this discussion to another newsgroup. (I might
or might not participate in such a discussion.)

Some only.

Please be more specific. What calculations can be done with C
floating-point numbers that cannot be done with PRNs? A single
example would suffice, at least for a start.

 

[user923005]

"Dik T. Winter" <[email protected]> ha scritto nel messaggio






int add(double*  r,  double a, double b)
{double  c, cc, aa, bb;
 if(a==NaN||b==NaN)         {*r=Nan; return 0;}
 if(a>b){aa=a; bb=b;}
 else   {aa=b; bb=a;}
 if(is_oo_positive(aa))
    {if( is_oo_negative(bb)){*r=NaN; return 0;}
     else                   {*r= aa; return 0;}
    }
 if(bb>0){c=aa+bb; /*aa>=bb>0*/
          if(fag_overflow()){*r=c; return 0;}
          cc=aa-c+bb; *r=c+cc;     return 1;
         }
 *r=aa+bb; return 1;

}

int mul(double*  r,  double a, double b)
{double  c, cc, aa, bb;
 if(a==NaN||b==NaN)
     {*r=NaN; return 0;}
 if(is_oo(a)||is_oo(b))
    {*r=a*b; return  0;}

 c=a*b; if(fag_overflow())
               {*r=c; return 0;}
 cc=a-c+b; *r=c+cc;
 return 1;

}

int sub(double*  r,  double a, double b) {return add(r, a, -b);}

int div(double* r,  double a, double b)
{
 if(a==NaN||b==NaN)
     {*r=NaN; return 0;}
 *r=a/b;
 if(*r==NaN) return 0;
 return 1;

}

so these not shoule intruduce errors more than the input,
(and pheraps the last digit??)
very good to know

For most of these functions, +/-INF is far more likely than NAN.

You can subtract two numbers of very nearly equal magnitude and get
total loss of precision.

I do not see your routines are terribly useful. If you are going to
expend huge effort to ensure that the calculations are in order, it
would be much better to use interval arithmetic.

Of course, if you understand the nature of the calculations and the
nature of the inputs, you don't need any muck in the way.

 

[Flash Gordon]

You have deleted material at this point without marking it implying that
the only comment I made was the one below.

You have deleted material posted by me below this point implying that I
did not write anything else.

Deleting the material showing your other errors without marking it is
not considered acceptable by the references on nettiquette you yourself
often quote, and it is also something you have recently denied doing.

No, you don't, not without looking at the programming that did the
store.

The C STANDARD states otherwise. Keith has already quoted the relevant
paragraphs in several posts over the past few days.

I think there is no argument that the precise value stored
in a FP object is a real.

It is a real in the same sense that the value stored in an int is a
real. If you exclude NaNs and infinities it is a member of a finite
subset of the rationals, which in turn is a subset of the reals.

Now quote the section of the C standard that states that floating point
numbers are reals (or ranges of reals). Not a statement by you that they
cannot be anything else, but a direct quote from the standard.

So is the value stored in the adjacent
object (i.e. the closest one numerically which exhibits a
difference via the '<' and '>' operators).

See above.

It is also a well known
fact that between any two different reals you can find an infinity
of other real values.

Yes, which are not in the set of values making up the floating point
numbers.

So I claim it is highly unlikely that you
can tell the exact value stored in that object.

Yes I can, I just read it out.

Remember, any
value in that infinity of values will result in the identical
construction of the FP object.

No, there are an infinite number of *reals*, there are exactly NO
floating point numbers between them.

I think the problem is that you insist on thinking of floating point
numbers as being reals. They are not reals, they are fundamentally
different to reals. Here are some of the differences:
1) Reals don't have NaNs, most floating point representations do
2) Reals don't have infinities, most floating point representations do
3) Reals don't have an upper or lower bound, floating point numbers do
4) There are an infinite number of reals between any two reals. There
are only a finite number (sometimes 0) of floating point numbers between
any two floating point numbers
5) With floating point numbers you sometimes have (a+b)+c != a+(b+c)


Now, so you can address the material you snipped without marking (or at
least appologise for snipping it without marking, here is the full
article including the material you deleted without any indication of
having done so.
---------------

>>> Flash Gordon wrote:
>>>> Keith Thompson wrote:
>>>>>
>>> ... snip ...
>>>
>>>>>> So what? doubles are used to store reals, more or less. ints
>>>>>> are used to store integers. 1.0+DBL_EPSILON/2.0 is a real[1].
>>>>>> 1.5 is NOT an integer.
>>>>>>
>>>>>> [1] but not a storable real, in a double.
>>>>> It's that "more or less" that bites you, isn't it? Your model
>>>>> makes some sense if you ignore those pesky details where it
>>>>> falls apart.
>>>> <snip>
>>>>
>>>> In addition doubles *are* used to store exact integral values
>>>> and integer types *are* used to store approximations. Any claim
>>>> that you have stored a range when you have in fact stored the
>>>> exact value that you intended to store is clearly wrong and would
>>>> make error analysis impossible.
>>> So what? You are referring to the programming that is using that
>>> object. I am talking about what you can deduce from the object in
>>> isolation.

>> That value is. The point is, that taken in isolation you do NOT know
>> that it is a range. Taken in isolation you only know what the actual
>> stored value is. is a single exact value specified by a well-defined
>> model which may represent either an exact quantity or a range which
>> could be (and ofen is) far larger than the ranges you are talking about.
>>
>> The standard actually talks about values that "can be represented
>> exactly" in section 6.3.1.5 (paragraph 2).

>
> Yes, but that is simply a number.

Yes, which is all that is actually stored.

> You do know what the 'range'
> is. The number does not express the range of numbers that will be
> stored with that identical value, and simply cannot be told apart. In

isolation what you know is the range of values that can have

> been represented thusly.

In isolation you know exactly what value *has* been stored, you just
can't tell whether the programmer intended to store a value that cannot
be represented.

> ... snip ...
>
> Go forth and implement a FP system.

I've implemented FP arithmetic (sufficient to solve my problem, not a
full system) in assembler already thanks. The data fed in to it was
exact values, the data extracted from it and finally converted to
integers was exact values. The intervening calculations were
approximations which gave a known acceptable limit on the error of the
settings given to the hardware when compared to the theoretical
mathematical values the algorithm I had to implement an approximation of.

Now address the point that your claim is in direct contradiction to the
wording of the standard.

You have yet to address how float can be a subset of double if the items
in the two sets are fundamentally different (i.e. if the range about 1.0
for the closest approximation to 1.0 is different in the two sets).

> Then examine when and how it
> fails.

It did not fail because I understood exactly what was needed and
carefully worked through it to ensure that the errors and approximations
stayed within acceptable limits.

> You will soon appreciate the fundamental truths about such
> a system. You will soon see how all values (apart from zero, NaNs,
> Infs) are approximations, and how they cannot overlap.

If you think that zero is exact then you are being inconsistent.
Calculations (including the conversion of a floating point number in the
source code) can yield 0 when the "correct" value is non-zero but
smaller than the smallest number representable in the floating point system.

> One point
> is that taking a value and writing it down does NOT convert it from
> an approximation to something exact.

No, nor does it convert something exact in to an approximation.

Note that no one has claimed that any type in C can store exactly all
rationals within any given range.

 

[Keith Thompson]

Flash Gordon wrote: [...]

In isolation you know exactly what value *has* been stored, you
just can't tell whether the programmer intended to store a
value that cannot be represented.

No, you don't, not without looking at the programming that did the
store. I think there is no argument that the precise value stored
in a FP object is a real.
Agreed.

So is the value stored in the adjacent
object (i.e. the closest one numerically which exhibits a
difference via the '<' and '>' operators).
Agreed.

It is also a well known
fact that between any two different reals you can find an infinity
of other real values.

Agreed. At this point, I almost hoped that you had finally gotten the
point, but ...

So I claim it is highly unlikely that you
can tell the exact value stored in that object. Remember, any
value in that infinity of values will result in the identical
construction of the FP object.

.... here's where you went off the rails.

The value stored in a floating-point object is not, cannot be, any
arbitrary real number. The values stored in a floating-point object
can *only* be one of the finitely many values of the object's type.

I think you're saying that, for example, given:
double x;
x = 1.0 / 3.0;
you cannot tell, just by examining the contents of x, that the real
value one-third was stored in x.

Well of course you can't, because the real value one-third *wasn't*
stored in x. The value stored in x was some value that's exactly
representable as a double, some value that's merely close to
one-third. And you can tell exactly what that floating-point value
was simply by examining the contents of x.

Concretely, on my system, the value stored in x is exactly
0.333333333333333314829616256247390992939472198486328125
and that's exactly what I see when I examine the contents of x later
in the same program.

Note that it wasn't the assignment that generated the FP
approximation, it was the "/" operator, which operates on
floating-point values, not on real values. The real value one-third
never occurred in the program, not even in the abstract semantics.
The real value one-third can't even be expressed in C.

Your claim that
it is highly unlikely that you can tell the exact value stored in
that object
is directly contradicted by C99 6.2.4p2:
An object exists, has a constant address, and retains its
last-stored value throughout its lifetime.
Should I believe you, or should I believe the C standard? Or is there
some way I haven't seen that the two are consistent?

 

[Keith Thompson]

I have been thinking about this and still do not know how CBF came to that
nonsense.

[...]

He made a mistake, which he later acknowledged.

 

[Keith Thompson]

CBFalconer wrote: [...]

I think there is no argument that the precise value stored
in a FP object is a real.

It is a real in the same sense that the value stored in an int is a
real. If you exclude NaNs and infinities it is a member of a finite
subset of the rationals, which in turn is a subset of the reals.

Now quote the section of the C standard that states that floating
point numbers are reals (or ranges of reals). Not a statement by you
that they cannot be anything else, but a direct quote from the
standard.

C99 5.2.4.2.2p1-2. In particular:

A _floating-point number_ (x) is defined by the following model:

x = [mathematical expression] emin <= e <= emax

See <http://www.mib.org/~kst/5.2.4.2.2.gif> or a PDF copy of the
standard for the actual expression.

(Note that a floating-point number is by definition a real number, not
a range.)

[...]

I think the problem is that you insist on thinking of floating point
numbers as being reals. They are not reals, they are fundamentally
different to reals.

I disagree. The floating-point numbers are a subset of the reals.
The subset obviously does not share all the characteristics of the
full set.

Here are some of the differences:
1) Reals don't have NaNs, most floating point representations do
2) Reals don't have infinities, most floating point representations do

Ok, I'll give you those. I've been excluding NaNs and infinities,
usually explicitly. But floating-point numbers other than NaNs and
infinities are reals.

3) Reals don't have an upper or lower bound, floating point numbers do

The subset has bounds, but each member of the subset (FP numbers) is a
member of the full set (reals).

4) There are an infinite number of reals between any two reals. There
are only a finite number (sometimes 0) of floating point numbers
between any two floating point numbers

Again, it's a subset relationship.

5) With floating point numbers you sometimes have (a+b)+c != a+(b+c)

"+" on FP numbers is a different operation than "+" on reals.

[big snip]

 

[Dik T. Winter]

>
> You must mean *c = a + b and *cc = a - *c + b

Right.

 

[Dik T. Winter]

>
> What do you have in mind here? I confess I can't think offhand of such
> an ordering.

Take all pairs (r, i) where r is a real in [0, 1) and i is an integer. Order
them lexicographically. Now given (r, i), (r, i-1) is its predecessor and
(r, i+1) its successor. Map (r, i) to the real r+i.

 

[Dik T. Winter]

> Anyway, from your message
> it's not clear whether you've seen it or not but CBF acknowledged
> that he made a mistake several days ago. See
> < http://groups.google.co.uk/group/comp.lang.c/msg/c9aa8d95feab47fd >

That article did not arrive here.

 

[Beej Jorgensen]

The model, at least if you look at just those two paragraphs
[5.2.4.2.2p1-2], defines a mapping from floating-point values to real
values, not vice versa.

Hey, Keith--sorry to bring this back up, but I'm not following exactly
what you mean here. Can I not take the digits of a real number and use
the model to construct a floating point number?

-Beej

 

[Keith Thompson]

The model, at least if you look at just those two paragraphs
[5.2.4.2.2p1-2], defines a mapping from floating-point values to real
values, not vice versa.

Hey, Keith--sorry to bring this back up, but I'm not following exactly
what you mean here. Can I not take the digits of a real number and use
the model to construct a floating point number?

Not in general, no, but it depends on what kind of mapping you're
looking for.

First off, what exactly do you mean by "the digits of a real number"?
In what base? For most real numbers, for whatever base you choose,
there are infinitely many digits.

The real problem is that there are only finitely many floating-point
numbers of a given type. Each FP number, INAIAU, maps to a unique
real number, and each of these real numbers maps back to the original
FP number. But there are infinitely many real numbers for which there
is no corresponding FP number.

For any real number in the range -DBL_MAX .. DBL_MAX, you can compute
the *nearest* FP number, and that's also a useful mapping, but it's
not exact. And it doesn't cover numbers outside that range -- though
you could map such numbers to +/-Infinity.

You can construct a mapping from all real numbers to FP numbers in any
number of ways, and many such mappings are quite useful. But they're
all somewhat arbitrary in one way or another, compromising for the
exactness that's impossible to achieve.

[*] Ignoring NaNs and infinities as usual.

 

[Beej Jorgensen]

The model, at least if you look at just those two paragraphs
[5.2.4.2.2p1-2], defines a mapping from floating-point values to real
values, not vice versa.

Hey, Keith--sorry to bring this back up, but I'm not following exactly
what you mean here. Can I not take the digits of a real number and use
the model to construct a floating point number?

Not in general, no, but it depends on what kind of mapping you're
looking for.

It was the "in general" part that I was missing from the previous post.
It seems to me the standard does define a mapping from *representable*
reals to floating point values, yes? (Via The Model.)

-Beej

 

[Flash Gordon]

CBFalconer wrote: [...]

I think there is no argument that the precise value stored
in a FP object is a real.

It is a real in the same sense that the value stored in an int is a
real. If you exclude NaNs and infinities it is a member of a finite
subset of the rationals, which in turn is a subset of the reals.

Now quote the section of the C standard that states that floating
point numbers are reals (or ranges of reals). Not a statement by you
that they cannot be anything else, but a direct quote from the
standard.

C99 5.2.4.2.2p1-2. In particular:

A _floating-point number_ (x) is defined by the following model:

x = [mathematical expression] emin <= e <= emax

See <http://www.mib.org/~kst/5.2.4.2.2.gif> or a PDF copy of the
standard for the actual expression.

(Note that a floating-point number is by definition a real number, not
a range.)
Agreed.

[...]

I think the problem is that you insist on thinking of floating point
numbers as being reals. They are not reals, they are fundamentally
different to reals.

I disagree. The floating-point numbers are a subset of the reals.
The subset obviously does not share all the characteristics of the
full set.

I agree that they are a subset (apart from the exceptions that we agree on).

"+" on FP numbers is a different operation than "+" on reals.

It is because the operators behave differently that I think it is better
to not think of them as being reals, but rather as being a set of their
own which just happens to be a subset of the reals. Just as a lot of the
time one thinks of integers as integers rather than simply being a
subset of reals. I think that it is because they behave differently to
real but CBF thinks of them as reals that he insists they must be ranges
of reals.

My minds gone blank on the word I'm looking for. There is a word in
maths for the set and the operators on it (i.e. like a class in most OO
languages), but I can't for the life of me remember what it is. However,
that is what we are dealing with in C when we want to know anything more
than the current value of a variable.

I don't think you and I are that far apart (thinking of floating point
as a sub-set of reals is valid since it is true, it is just the
operators behave differently).

 

[Keith Thompson]

The model, at least if you look at just those two paragraphs
[5.2.4.2.2p1-2], defines a mapping from floating-point values to real
values, not vice versa.

Hey, Keith--sorry to bring this back up, but I'm not following exactly
what you mean here. Can I not take the digits of a real number and use
the model to construct a floating point number?

Not in general, no, but it depends on what kind of mapping you're
looking for.

It was the "in general" part that I was missing from the previous post.
It seems to me the standard does define a mapping from *representable*
reals to floating point values, yes? (Via The Model.)

Sure. Well, it does so implicitly. The Model defines a mapping that
specifies, for each FP value, what its real value is. You can
trivially invert that mapping to get a mapping from a subset of the
reals to FP values. INAIAU.

 

[Spiros Bousbouras]

INAIAU.

You have managed to come up with an abbreviation not
even Google knows about.

 

[Keith Thompson]

Keith Thompson said:


"In Numerical Analysis I Am Unmatched"?

Ooh, I like it! And I suppose it's literally true; there's probably
nobody else in the world whose numerical analysis skills exactly match
mine. Not that that's necessarily a good thing.

 

[CBFalconer]

Yes, that's exactly what it means. There are no floating-point
numbers of type double between 1.0 and 1.0+DBL_EPSILON.


No, there is no uncertainty in the value. The value is what it is, as
defined by the model in the C standard. The real value of the FP
number 1.0 is exactly 1.0, no more, no less. The real value of the FP
number exactly 1.0+DBL_EPSILON is 1.0+DBL_EPSILON, no more, no less.
There are no FP numbers (of type double) between those two values.
(The reals are dense; FP numbers are not.)

First, I am only dealing with one flavor of floating point at a
time. No need for the complications, which don't affect anything
except the sizes.

Second, there certainly is a range. If we can't tell the
difference, from the fp value, between that actual value, and a
value just less that x*(1+EPSILON), neglecting the equivalent
identity between values less than x, that value x is covering a
'range'. We are NOT analysing the software that initialized x, we
are analyzing the value stored in x.

Sorry, I don't know what that means. What 'range' are you talking
about?

The same 'range' I have been talking about all through this. For a
fp value x, it is usually the values from x*(1-EPSILON) through
x*(1+EPSILON). This is fundamental.

Of course you can't store a non-representable real value in an FP
object and then retrieve that same value. You can't really even try.
You *can* store a representable value in an FP object and then
retrieve that exact value. "An object exists, has a constant address,
and retains its last-stored value throughout its lifetime", remember?

But the point is you don't know anything about what was stored, or
how it was computed, etc. You are just looking at the fp object
and examining its value.

Thank you.


No, I haven't, and so what if I have? I'm talking about PRNs, not
floats.

(I just realized that "PRN" can also stand for pseudo-random number; I
think the context is sufficiently clear to avoid any confusion.)


What ranges? PRNs do not correspond to ranges; each PRN value
corresponds to a unique real value.

I said you have omitted the ranges. Without those I showed some
problems.

Sorry, you've completely lost me. PRNs correspond only to a discrete
finite subset of the real numbers. For example, there is no PRN that
corresponds to the real value one-third.


What part of "please quote the exact wording from the standard" are
you having trouble with? And what do you mean "leaving out
uniqueness"?

The < and > comparison operators can be applied to PRNs in an
extremely straightforward manner. ...

No they can't, if you want to compare the values that were stored.

Lets store the value A in a, B in b. Neither A nor B fit the PRN
'value' exactly. So a has PRN value ap, and b has PRN value bp.

Nothing says anything about the relationships between these values
that don't fit the PRN value. A may be less than B, yet ap may be

bp.

This is what is regularized by the C standards reference to
EPSILON, and the value where it is applied.

I'm going to ship this reply, (which is much too long) and go take
a nap. I'll return some time later.

 

[Beej Jorgensen]

You have managed to come up with an abbreviation not
even Google knows about.

"Interesting New Abbreviation INAIAU Apparently Unknown."

-Beej

 

[Keith Thompson]

Keith Thompson wrote: [snip]

I disagree. The floating-point numbers are a subset of the reals.
The subset obviously does not share all the characteristics of the
full set.

I agree that they are a subset (apart from the exceptions that we agree on).

"+" on FP numbers is a different operation than "+" on reals.

It is because the operators behave differently that I think it is
better to not think of them as being reals, but rather as being a set
of their own which just happens to be a subset of the reals. Just as a
lot of the time one thinks of integers as integers rather than simply
being a subset of reals. I think that it is because they behave
differently to real but CBF thinks of them as reals that he insists
they must be ranges of reals.

My minds gone blank on the word I'm looking for. There is a word in
maths for the set and the operators on it (i.e. like a class in most
OO languages), but I can't for the life of me remember what it
is. However, that is what we are dealing with in C when we want to
know anything more than the current value of a variable.

The word you're looking for is "group" or "field".

It's been a while since I've studied this stuff, but a group is
basically a set (could be of anything) with an "additive" operation
that has certain properties (it's closed over the set, there's an
additive identity (0), each element has an additive inverse (-x,
such that -x + x = 0), and the operation is transitive ((x+y)+z) =
(x+(y+z))).

If the operation happens to be commutative, it's an "Abelian group".

A "field" is a group with some added properties: I think the
"additive" operation has to be commutative, and there's also a
"multiplicative" operation with certain other required properties.

I don't think you and I are that far apart (thinking of floating point
as a sub-set of reals is valid since it is true, it is just the
operators behave differently).

Right. The set of floating-point numbers is a subset of the set of
real numbers, but the group of FP numbers under FP addition is not a
subgroup of the group of real numbers under real addition. In fact, the
FP numbers under FP addition don't form a group at all, since the set
isn't closed under addition. (I suppose you might be able to turn it
into a group by defining the result of "+" for cases whose behavior is
undefined in C, but I don't think it would be worth the effort.)