Infinity + Infinity (or NegInfinity - NegInfinity)

S

Skybuck Flying

Hello,

I was just wondering what happens if "Infinity" is added to "Infinity" when
it comes to floating point numbers ?

And also what happens if "Negative Infinity" is added to "Negative
Infinity"... ?

In Delphi these are defined as follows (in the math.pas unit):

const
Infinity = 1.0 / 0.0;
NegInfinity = -1.0 / 0.0;

As far as I know this conforms to some kind of floating point standard.

I haven't tried to add these two numbers together yet, but I will soon try
it out.

I am just wondering from a theoretical point of view what should happen ?

Should it wrap back from infinity to infinity ?

Should it wrap back from negative infinity to negative infinity ?

Or will perhaps something weird happen ?

Bye,
Skybuck.
 
R

Robert Myers

On Oct 7, 8:54 pm, "Skybuck Flying"
I haven't tried to add these two numbers together yet, but I will soon try
it out.

I am just wondering from a theoretical point of view what should happen ?

Should it wrap back from infinity to infinity ?

Should it wrap back from negative infinity to negative infinity ?

Or will perhaps something weird happen ?

Something weird happens, all right. It's called quantum field theory,
but to add plus and minus infinity and get anything but "Who knows?,"
you have to be a quantum field theorist.

Robert.
 
J

James Kuyper

On Oct 7, 8:54�pm, "Skybuck Flying"

Something weird happens, all right. It's called quantum field theory,
but to add plus and minus infinity and get anything but "Who knows?,"
you have to be a quantum field theorist.


#ifdef __STDC_IEC_559__
then IEC 60559 should apply. I don't have a copy of that standard, but
the C standard indicates that it's closely related to ANSI/IEEE 854,
which I do have. It specifies:

"The invalid operation exception is signaled if an operand is invalid
for the operation being performed. The floating point result delivered
when the exception occurs without a trap shall be a quiet NaN. The
invalid operations are as follows:
....
(2) Addition or subtraction: magnitude subtraction of infinities such as
(+∞) + (-∞)"

The symbols in those parentheses are supposed to be infinities, though
I've found it's hard to predict whether or not symbols will display
properly.
 
J

Jasen Betts

Hello,

I was just wondering what happens if "Infinity" is added to "Infinity" when
it comes to floating point numbers ?

And also what happens if "Negative Infinity" is added to "Negative
Infinity"... ?

infinity plus infinity is indistinguishable from infinity times two.
In Delphi these are defined as follows (in the math.pas unit):

const
Infinity = 1.0 / 0.0;
NegInfinity = -1.0 / 0.0;

delphi can do that because it only runs on intel compatible hardware
and can rely on the floating point arithmetic to give the
representations it wants.
As far as I know this conforms to some kind of floating point standard.

IEEE 754
I haven't tried to add these two numbers together yet, but I will soon try
it out.

you should get "NaN" which is "Not a Number" and the same result that
0.0/0.0 gives.
Or will perhaps something weird happen ?

depends if you're expecting NaN or not.

( 1.0 / 0.0 ) + ( -1.0 / 0.0 )
= ( 1.0 + -1.0 ) / 0.0
= 0.0 / 0.0

http://en.wikipedia.org/wiki/NaN
 
J

Jasen Betts

The infinity of analysis, oo, is not defined by floating point numbers.

the real numbers and IEE 754 floating point are disjoint sets.

with a few exceptions (+Inf, -Inf, NaN) floating point can only
represent a finite subset of the rational numbers)
 
S

Skybuck Flying

Hi,

I was mostly interested in +inf + +inf. (Positive infinity + Positive
infinity)

However perhaps that situation is now unlikely in my algorithm so my
interest in this special situation is dwindling/decreasing ;)

But maybe this situation might still pop-up and then my interest in it might
go back up ;) :)

So don't expect me to look to deeply into it for now ;) (If my interest in
it changes, I'll let you know, could be within a few days, otherwise years,
or maybe never...)

Bye,
Skybuck.
 
K

Kaba

Skybuck said:
Hello,

I was just wondering what happens if "Infinity" is added to "Infinity" when
it comes to floating point numbers ?

And also what happens if "Negative Infinity" is added to "Negative
Infinity"... ?

In Delphi these are defined as follows (in the math.pas unit):

const
Infinity = 1.0 / 0.0;
NegInfinity = -1.0 / 0.0;

As far as I know this conforms to some kind of floating point standard.

Here are some interesting properties of the IEEE floating point
standard, which is the underlying technology behind most home computers.
The behaviour of high-level programming languages tend to mirror it
closely. Let x be some positive, regular, floating point number. The
basic mathematical model is the affinely extended reals, but the
standard defines a bit more (see division by zero).

Zeros:

* There are two zeros, +0 and -0.
* -0 = -(+0)
* Floating point comparison is defined so that +0 = -0 is true.

Not-A-Number (NaN):

* Produced as an error value, for example with +0 / +0.
* Multiplying, adding, subtracting or dividing with a NaN produces a
NaN. The NaN is said to be propagated.
* All comparisons (<, >, =, !=, <=, >=) with a NaN yield false.

Infinities:

* There is infinity (oo) and minus infinity (-oo).
* -oo = -(oo)
* oo + oo = oo
* -oo + -oo = -oo
* oo + -oo = NaN
* +-x + oo = oo
* +-x + -oo = -oo
* Subtraction similarly...

Division by zero:

* +-x / +0 = +-oo
* +-x / -0 = -+oo
* +-0 / +-0 = NaN

Multiplication by infinities:

* +-x * oo = +-oo
* +-x * -oo = -+oo
* +0 * +-oo = +-0
* -0 * +-oo = -+0

Division by infinities:

* +-x / oo = +-0
* +-x / -oo = -+0
 
N

nmm1

Here are some interesting properties of the IEEE floating point
standard, which is the underlying technology behind most home computers.
The behaviour of high-level programming languages tend to mirror it
closely.

Oh, no, they don't! Not even if you had got it correct.
Let x be some positive, regular, floating point number. The
basic mathematical model is the affinely extended reals, but the
standard defines a bit more (see division by zero).

Its signed zero handling is incompatible with that model in several
respects where traditional floating-point isn't.

Regards,
Nick Maclaren.
 
K

Kaba

christian.bau said:
The 0 times infinity case does not agree with IEEE754.
And note that not all comparisons with NaN yield "false": x != NaN and
NaN != x yields "true".

Yes, thanks for the fix.
 
K

Kaba

wrote:
Oh, no, they don't! Not even if you had got it correct.

Simply asserting that isn't particularly helpful. Maybe you could step
in and make a better statement, on where the behaviour agreees and where
it differs.
Its signed zero handling is incompatible with that model in several
respects where traditional floating-point isn't.

I disagree. Mathematics has one zero, the IEEE floating point has two.
However, they negative and positive zero can not be differentiated by
their action, expect when dividing by zero. But dividing by zero is not
defined in the affinely extended reals. Thus, unless I am missing
something, the IEEE floating point is a fine model for the affinely
extended reals.
 
N

nmm1

Simply asserting that isn't particularly helpful. Maybe you could step
in and make a better statement, on where the behaviour agreees and where
it differs.

The IEEE 754 model is incompatible with most language's arithmetic
models, so it isn't possible (even in theory) to answer that question
for the vast majority of languages. If you really want to know the
details, you will have to start by studying various language standards
and specifications - i.e. the definitions of the languages, not
someone's summary of them.
I disagree. Mathematics has one zero, the IEEE floating point has two.
However, they negative and positive zero can not be differentiated by
their action, expect when dividing by zero. But dividing by zero is not
defined in the affinely extended reals. Thus, unless I am missing
something, the IEEE floating point is a fine model for the affinely
extended reals.

You are. IEEE 754 also has a sign test function, and that means
that -(x-y) is distinguishable from y-x, whereas -(x-y) = y-x for
in that form of mathematics.


Regards,
Nick Maclaren.
 
J

James Kuyper

The IEEE 754 model is incompatible with most language's arithmetic
models,

That claim would be more useful if you would at least hint at what the
typical incompatibilities are. I doubt that the writers of that standard
intended it to be incompatible with those languages, and I doubt that
the designers of all of those languages went out of their way to be
incompatible with that standard, which suggests that any such
incompatibility is likely to be subtle. If so, reading the IEEE 754
standard and comparing it with the language standards is not likely to
be fruitful without at least a hint of what incompatibilities to look for.

....
You are. IEEE 754 also has a sign test function, and that means
that -(x-y) is distinguishable from y-x, whereas -(x-y) = y-x for
in that form of mathematics.

That doesn't matter unless a sign test function, with conflicting
semantics, is part of the definition of affinely extended reals.
 
R

Robert Myers

That claim would be more useful if you would at least hint at what the
typical incompatibilities are. I doubt that the writers of that standard
intended it to be incompatible with those languages, and I doubt that
the designers of all of those languages went out of their way to be
incompatible with that standard, which suggests that any such
incompatibility is likely to be subtle. If so, reading the IEEE 754
standard and comparing it with the language standards is not likely to
be fruitful without at least a hint of what incompatibilities to look for.

...

That doesn't matter unless a sign test function, with conflicting
semantics, is part of the definition of affinely extended reals.

Thank you for introducing me to the affinely extended reals.

I struggled vainly to come to grips with many odd objects in theoretical
physics, until I finally grasped that, for someone with a pedestrian
mind like mine, these discussions make sense only if you are willing to
dig into the implied limiting processes in detail.

Appealing to arbitrary standards is well past silly. If you can't
define the limiting processes you are assuming in pedestrian terms, you
are either a genius or you don't know what you are talking about.

Robert.
 
N

nmm1

...

That claim would be more useful if you would at least hint at what the
typical incompatibilities are. I doubt that the writers of that standard
intended it to be incompatible with those languages, and I doubt that
the designers of all of those languages went out of their way to be
incompatible with that standard, which suggests that any such
incompatibility is likely to be subtle. If so, reading the IEEE 754
standard and comparing it with the language standards is not likely to
be fruitful without at least a hint of what incompatibilities to look for.

Aargh! You have got the whole thing arsey-versey. If there isn't
any match between the basic concepts, what on earth is the point
in looking for detailed incompatibilities? I said that the MODELS
were incompatible and not that the DETAILS were.

The clearest standard in this respect is Fortran: look at 7.1.8.3
in Fortran 2003 "Once the interpretation has been established in
accordance with those rules, the processor may evaluate any
mathematically equivalent expression, provided that the integrity of
parentheses is not violated." But that is NOT the only relevant
specification of the model, even in Fortran.

Look, when I raised this on the IEEE 754R mailing list, and in
personal contact, I was told that the languages would simply have
to change their arithmetic model to fit. I told them "no chance"
but said that I would raise it in some ISO working groups - which,
of course, said "no chance". Why ON EARTH do you think that there
is no full support for IEEE 754 in any language whatsoever after
27 years?

And, no, I am NOT going to describe what C99 really specifies,
even though I could in all its gory detail (as I think you know).


Regards,
Nick Maclaren.
 
J

James Kuyper

Aargh! You have got the whole thing arsey-versey. If there isn't
any match between the basic concepts, what on earth is the point
in looking for detailed incompatibilities? I said that the MODELS
were incompatible and not that the DETAILS were.

Then please explain the incompatibility you see in the models. Are the
problematic features of the IEEE 754 standard shared by the IEEE 854?
I've got a copy of that standard, and am somewhat familiar with it (I
wouldn't claim to be an expert, by any means). I do consider myself a
fair expert on the C99 standard, and I haven't noticed any
incompatibilities of the very fundamental nature that you're implying.
Your citation from the Fortran standard didn't do anything to clarify
the issue for me.

I'm not saying you're wrong. As it stands, I have no idea what you're
talking about, so I can't judge whether or not you're right. If you have
any inclination to be less cryptic, please let me know.
 
N

Nobody

* All comparisons (<, >, =, !=, <=, >=) with a NaN yield false.

(x != NaN) and (Nan != x) are true for all x (including NaN), so
(x != y) is equivalent to !(x == y) even when x or y are NaN.

The other 5 comparisons are false whenever an operand is NaN.
 
N

nmm1

Then please explain the incompatibility you see in the models. Are the
problematic features of the IEEE 754 standard shared by the IEEE 854?
Yes.

I've got a copy of that standard, and am somewhat familiar with it (I
wouldn't claim to be an expert, by any means). I do consider myself a
fair expert on the C99 standard, and I haven't noticed any
incompatibilities of the very fundamental nature that you're implying.
Your citation from the Fortran standard didn't do anything to clarify
the issue for me.

I'm not saying you're wrong. As it stands, I have no idea what you're
talking about, so I can't judge whether or not you're right. If you have
any inclination to be less cryptic, please let me know.

Sorry - things have been a little stressful.

IEEE 754 is based on a serial assembler model, where arithmetic
is a sequence of basic operations. And both aspects are critical.

Fortran is based on an evaluation of mathematical expressions,
and is not in terms of basic operations, nor even necessarily serial.
There just isn't any match between the models.

Most languages are like Fortran, though usually less explicit, and
with less implied freedom for the implementor. If I recall from
my time on WG2, Pascal is one such. Python definitely is. I can't
remember about Ada, but I vaguely recall it being, too. As are
most of the other hundreds of languages I have looked at in my time.

The original intent of WG14 was similar (I was involved - remember
the unary plus proposal?) and the standards was deliberately left
ambiguous (NOT my choice). Later revisionists claimed that C had
always specified the execution order implied by one reading of the
syntax, but that is completely false, and is contradicted by other
wording, anyway (try 6.5#3, for a start). As I said, I am NOT going
to go into the complete mess that is FLT_EVAL_METHOD, the pragmas,
Annex F and all that - I tried to get some sanity injected during
C99's standardisation, and failed, which is the main reason I voted
against it.

C++ is similar, but different. I raised this there and WG21 kicked
it into the long grass. As I understand it, the intent is that the
order is unconstrained, but serial execution is assumed.

For Java, see Kahan's paper. Its value semantics match; its flag
ones don't.



Regards,
Nick Maclaren.
 
K

Kaba

William said:
It's only a desperate illusion that those who know programming,
know something about mathematics. On the contrary, it appears
knowing programming is a mathematical handicap.

A branch of programming known as generic programming is surprisingly
close to mathematical thinking. With the least amount of assumptions,
you wish to create data structures and algorithms capable of handling
the greatest amount of cases.

For example: you can create a concept named semigroup (corresponding to
the mathematical concept) by requiring that each type conforming to a
semigroup have a binary addition operator +, and that operation be
associative. If you can create an algorithm which only relies on that
operation, then that algorithm works for all types conforming to the
semigroup concept (and not just for integers, say).
 
S

Skybuck Flying

I am not so sure if dividing by zero leads to exceptions.

For integers this seems to be the case but for floating point it could be
different.

When one thinks about it: dividing a number by a very small number gives a
very big number.

So dividing a number by zero would lead to infinity, so in a way it makes
sense to define the result of divizion by zero for floating point numbers to
either
be negative infinity or positive infinity this would save the need to use
branches to catch zero cases and assign infinity.

Example:

Nasty situation:

if Delta <> 0 then
begin
Result := Number / Delta;
end else
begin
if Number < 0 then
begin
Result := NegativeInfinity;
end else
begin
Result := PositiveInfinity;
end;
end;

Nice situation:

Result := Number / Delta;

^ It would be nice if the processor would automatically fill result with the
appriorate infinity so the possibly expensive branches up there can be
avoided.

I have at least seen one programmer claim that current X86/X64 processors
can already do this ? I am not sure and have not tried yet, seems a bit
risky to leave these branches out.

It could also be as you say and it could be compiler specific.

I think Delphi probably has a compiler directive to make the "nice"
behaviour work, if it doesn't then it should get one ! ;)

Bye,
Skybuck :)
 
A

Al Grant

The original intent of WG14 was similar (I was involved - remember
the unary plus proposal?) and the standards was deliberately left
ambiguous (NOT my choice).  Later revisionists claimed that C had
always specified the execution order implied by one reading of the
syntax, but that is completely false, and is contradicted by other
wording, anyway (try 6.5#3, for a start).

So in what respect is that incompatible with IEEE 754? C specifies
not only that in (a+b)+c, a+b happens first, but that in a+b+c,
a+b happens first, so it's more prescriptive than Fortran.
It says things are otherwise unsequenced, but how can IEEE 754
require more than that? If IEEE 754 required a total order on all
floating-point operations in a program it would have been
unimplementable on any SIMD computer from ILLIAC IV onwards.

C _allows_ implementations that are incompatible with IEEE 754
(e.g. ones that use a different format, or flush denormals to zero)
but that's a long way from _being_ incompatible with IEEE 754.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top