Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #11373 > unrolled thread

Infinity + Infinity (or NegInfinity - NegInfinity)

Back to article view | Back to comp.lang.c

Contents

  Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-08 02:54 +0200
    Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-07 18:40 -0700
      Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-07 22:39 -0400
    Re: Infinity + Infinity (or NegInfinity - NegInfinity) William Elliot <marsh@rdrop.com> - 2011-10-07 19:56 -0700
      Re: Infinity + Infinity (or NegInfinity - NegInfinity) Jasen Betts <jasen@xnet.co.nz> - 2011-10-08 06:45 +0000
        Re: Infinity + Infinity (or NegInfinity - NegInfinity) gordonb.eug6r@burditt.org (Gordon Burditt) - 2011-10-08 02:37 -0500
          Re: Infinity + Infinity (or NegInfinity - NegInfinity) William Elliot <marsh@rdrop.com> - 2011-10-08 21:40 -0700
            Re: Infinity + Infinity (or NegInfinity - NegInfinity) Kaba <kaba@nowhere.com> - 2011-10-09 12:17 +0300
    Re: Infinity + Infinity (or NegInfinity - NegInfinity) Jasen Betts <jasen@xnet.co.nz> - 2011-10-08 06:33 +0000
    Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-08 16:41 +0200
      Re: Infinity + Infinity (or NegInfinity - NegInfinity) kenney@cix.compulink.co.uk - 2011-10-09 04:01 -0500
    Re: Infinity + Infinity (or NegInfinity - NegInfinity) Kaba <kaba@nowhere.com> - 2011-10-08 17:43 +0300
      Re: Infinity + Infinity (or NegInfinity - NegInfinity) "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-10-08 10:20 -0700
        Re: Infinity + Infinity (or NegInfinity - NegInfinity) Kaba <kaba@nowhere.com> - 2011-10-08 22:35 +0300
      Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-08 18:55 +0100
        Re: Infinity + Infinity (or NegInfinity - NegInfinity) Kaba <kaba@nowhere.com> - 2011-10-08 23:03 +0300
          Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-08 21:27 +0100
            Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-08 17:28 -0400
              Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-08 18:15 -0400
              Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-08 23:23 +0100
                Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-08 21:29 -0400
                  Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-09 10:01 +0100
                    Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-12 06:14 -0700
                      Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-12 15:25 +0100
                        Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-12 12:10 -0400
                          Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-12 18:41 +0100
                            Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-12 15:32 -0400
                              Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-12 20:44 +0100
                                Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-12 18:11 -0700
                                  Re: Infinity + Infinity (or NegInfinity - NegInfinity) Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-13 03:48 +0000
                                    Re: Infinity + Infinity (or NegInfinity - NegInfinity) nmm1@cam.ac.uk - 2011-10-13 09:07 +0100
                                    Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-13 07:00 -0700
                                    Re: Infinity + Infinity (or NegInfinity - NegInfinity) Robert Myers <rbmyersusa@gmail.com> - 2011-10-14 10:54 -0700
                                      Re: Infinity + Infinity (or NegInfinity - NegInfinity) Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-14 22:36 +0000
                                        Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-15 09:26 +0200
                                          Re: Infinity + Infinity (or NegInfinity - NegInfinity) Jasen Betts <jasen@xnet.co.nz> - 2011-10-24 02:40 +0000
                                            Re: Infinity + Infinity (or NegInfinity - NegInfinity) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-27 00:32 +0300
                                              Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-27 10:41 +0200
                                                Re: Infinity + Infinity (or NegInfinity - NegInfinity) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-27 13:10 +0300
                                                  Re: Infinity + Infinity (or NegInfinity - NegInfinity) Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-27 13:53 +0200
                          Re: Infinity + Infinity (or NegInfinity - NegInfinity) Keith Thompson <kst-u@mib.org> - 2011-10-12 12:34 -0700
                          Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-13 06:39 -0700
                            Re: Infinity + Infinity (or NegInfinity - NegInfinity) James Kuyper <jameskuyper@verizon.net> - 2011-10-13 10:34 -0400
                              Re: Infinity + Infinity (or NegInfinity - NegInfinity) Al Grant <algrant@myrealbox.com> - 2011-10-14 00:54 -0700
                        Re: Infinity + Infinity (or NegInfinity - NegInfinity) Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:25 -0800
              Re: Infinity + Infinity (or NegInfinity - NegInfinity) Larry Hewitt <larryhwtt@comporium.net> - 2011-10-09 21:35 -0400
                Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-10 04:37 +0200
                  Re: Infinity + Infinity (or NegInfinity - NegInfinity) Larry Hewitt <larryhwtt@comporium.net> - 2011-10-10 13:58 -0400
                    Re: Infinity + Infinity (or NegInfinity - NegInfinity) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-13 20:17 +0200
          Re: Infinity + Infinity (or NegInfinity - NegInfinity) Arivald <arivald_@AT_interia_DOT_.pl> - 2011-10-13 12:10 +0200
      Re: Infinity + Infinity (or NegInfinity - NegInfinity) Nobody <nobody@nowhere.com> - 2011-10-09 05:05 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#11597

James Kuyper <jameskuyper@verizon.net> writes:
> On 10/12/2011 10:25 AM, nmm1@cam.ac.uk wrote:
> ...
>> There is no such statement in the C standard, and I can tell you
>> (from personal recollection) that requiring it was NOT WG14's intent
>> during the standardisation of C90.  The BNF was intended to specify
>> ONLY the precedence of operators and NOT the evaluation order; that
>> was specified by the side-effect rules.
>> 
>> If you had looked up the section of the standard I pointed you to,
>> you would have seen both that the word used is "grouping", which
>> is clearly intended to distinguish it from execution order, and a
>> clear statement that the order of evaluation is unspecified.  And
>> THAT was the intent of WG14 during the standardisation of C90.
>> 
>> I am fully aware that a lot of people are now claiming that the
>> BNF has always been meant to define  the execution order, but that
>> flatly contradicts large chunks of other wording (especially the
>> side-effect rules).  Whether it is now what compilers do, I don't
>> know (and don't much care, either).
>
> The freedom of C implementations to rearrange the order of evaluation is
> great, but it's not completely unconstrained.
> While there are people who have misinterpreted the BNF as fully
> specifying the execution order, I don't consider that to be a common
> position among those most familiar with the standard. A more common
> position, and IMO fully defensible, is that the BNF implies constraints
> on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be
> executed before or after the (c+d), but both must be executed before the
> final addition can be performed, because that addition requires the
> results of those execution. The standard does not say anything
> explicitly about that fact, because it doesn't need to - it's implicit
> in what the standard does explicitly say about the dependency of the
> final value on the values of the sub-expressions.

And C201X, or at least the N1570 draft, makes this explicit.  6.5p1:

    An _expression_ is a sequence of operators and operands that
    specifies computation of a value, or that designates an object
    or a function, or that generates side effects, or that performs
    a combination thereof. The value computations of the operands
    of an operator are sequenced before the value computation of
    the result of the operator.

The phrase "sequenced before" is new; it's defined in 5.1.2.3.
If there's a sequence point after x and before y, then x is
"sequenced before" y.  But the reverse is not necessarily true; x can
be sequenced before y even if there's no sequence point between them.

In the example "a + b + c", the grammar says that the first "+"
applies to "a" and "b", and the second applies to the result of the
first and to "c"; in other words, "a + b + c" means "(a + b) + c",
*not* "a + (b + c)".

The order of evaluation of the operands of a given operator is
unspecified, and I don't believe anyone here has suggested otherwise.
"a + b" could evaluate "a" and then "b", or "b" and then "a"; it could
even evaluate them in parallel as long as the result is as if they were
evaluated sequentially.

But an operator cannot be applied until after its operands have
been evaluated.  This is implicit in C90 and C99, and explicit (see
above) in C201X.  The result of "a + b" *must* be computed before
the result of "a + b + c" can be computed.  There's no sequence
point between the two additions, but their order is constrained by
the simple fact that you can't perform an operation without first
evaluating the operands.  (The lack of a sequence point means that
the "value computation" of "a" is sequenced before the computation of
"a + b", but any side effects of evaluating "a" are not.)

[...]

(Followups to comp.lang.c only.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#11618

On Oct 12, 5:10 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> The freedom of C implementations to rearrange the order of evaluation is
> great, but it's not completely unconstrained.
> While there are people who have misinterpreted the BNF as fully
> specifying the execution order, I don't consider that to be a common
> position among those most familiar with the standard. A more common
> position, and IMO fully defensible, is that the BNF implies constraints
> on the execution order. For instance, in ((a+b) + (c+d)), the a+b can be
> executed before or after the (c+d), but both must be executed before the
> final addition can be performed

That was what I was saying, with the further provision that
a + b + (c + d)   is equivalent to  ((a+b) + (c+d)).  I.e. in C,
parentheses are a lexical feature and don't act as a further
constraint on the parse.  The compiler has no more leeway
to reassociate a+b+c than it does to reassociate (a+b)+c.

[toc] | [prev] | [next] | [standalone]

#11624

On 10/13/2011 09:39 AM, Al Grant wrote:
...
> That was what I was saying, with the further provision that
> a + b + (c + d)   is equivalent to  ((a+b) + (c+d)).  I.e. in C,
> parentheses are a lexical feature and don't act as a further
> constraint on the parse.

I'm not sure exactly what you mean by the statement that they "don't act
as a further constraint on the parse". To clarify, do you agree that
each of the following expressions is parsed into a different evaluation
tree?

	a +  b +  c  + d
	a + (b +  c) + d
	a +  b + (c  + d)
	a + (b + (c  + d)

In particular, the conditions that make each of those expressions
produce an overflow may be quite different.

> ...  The compiler has no more leeway
> to reassociate a+b+c than it does to reassociate (a+b)+c.

I'll agree with that

[toc] | [prev] | [next] | [standalone]

#11651

On Oct 13, 3:34 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> I'm not sure exactly what you mean by the statement that they "don't act
> as a further constraint on the parse". To clarify, do you agree that
> each of the following expressions is parsed into a different evaluation
> tree?
>
>         a +  b +  c  + d
>         a + (b +  c) + d
>         a +  b + (c  + d)
>         a + (b + (c  + d)

Yes.  Also, the third one is the only "balanced" tree where
two of the adds can happen at the same time.

> In particular, the conditions that make each of those expressions
> produce an overflow may be quite different.

And in floating-point the result may be numerically different...

[toc] | [prev] | [next] | [standalone]

#16146

nmm1@cam.ac.uk writes:

> In article <88cbbc8b-1fab-4dde-96b0-4dd0cd7c183d@b6g2000vbz.googlegroups.com>,
> Al Grant  <algrant@myrealbox.com> wrote:
>>
>>> 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). =A0Later 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.
>
> You are clearly a revisionist, as well as being unfamiliar with the
> ISO/ANSI C standards and their implementations!
>
> There is no such statement in the C standard, and I can tell you
> (from personal recollection) that requiring it was NOT WG14's intent
> during the standardisation of C90.  The BNF was intended to specify
> ONLY the precedence of operators and NOT the evaluation order;  [snip]

The BNF does specify the order of evaluation (for values)
for any two subexpressions where one is contained in the
other, just not for subexpressions neither of which contains
the other.  (Of course with the understanding that side
effects are a whole other story.)

[toc] | [prev] | [next] | [standalone]

#11457

On 10/8/2011 5:28 PM, James Kuyper wrote:
> On 10/08/2011 04:27 PM, nmm1@cam.ac.uk wrote:
>> In article<MPG.28fad914bc1e280d9899d5@news.cc.tut.fi>,
>> Kaba<kaba@nowhere.com>  wrote:
> ...
>> 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.
>


Implementation of IEEE 754 is dependent on the compiler and the hardware.

IEEE 754 defines 5 exceptions, but how these are triggered and then 
handled is up to  the compiler.
     Invalid operation (e.g., square root of a negative number)
     Division by zero
     Overflow (a result is too large to be represented correctly)
     Underflow (a result is very small outside the normal range)
     Inexact.

Divide by zero is a defined exception, so 1.0/0.0 will trigger an 
exception. But how the compiler triggers that exception may vary.
inf + inf is an exception, but the compiler can trigger either an 
inexact exception or an overflow exception.

Some compilers will allow exceptions to be ignored, resulting in 
unpredictable results based on the random content of memory that may be 
misinterpreted as a valid result.

Larry

> ...
>>> 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.
>
> That doesn't matter unless a sign test function, with conflicting
> semantics, is part of the definition of affinely extended reals.

[toc] | [prev] | [next] | [standalone]

#11458

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 :)

[toc] | [prev] | [next] | [standalone]

#11470

On 10/9/2011 10:37 PM, Skybuck Flying wrote:
> I am not so sure if dividing by zero leads to exceptions.
>

The IEE 754 defines divide by zero to be an exception. It does not 
differentiate between integer and floating point.

Mathematically the result is undefined.

> 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.

Except when that "very small: number is zero, then the result is 
undefined, by definition .

>
> 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.
>

No.

The result is undefined.

To be a  defined result the inverse operation must generate the original 
values and be unique.

so, if :

1.0/0.0 = inf, then inf * 0.0 = 1.0
and

2.0/0.0 = inf, then inf*0.0 = 2.0

That is why division by zero and calculations in the reals with inf are 
undefined.

> 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.
>

Hardware does not understand numbers, software as produced by a compiler 
does. A number or a letter is no more than a series of bits in a 
register to hardware that is described by the software.

I have used languages where, if you are careless, you can add the ascii 
value of letters.
\Larry

> 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 :)
>

[toc] | [prev] | [next] | [standalone]

#11636

"
To be a  defined result the inverse operation must generate the original 
values and be unique.

so, if :

1.0/0.0 = inf, then inf * 0.0 = 1.0
and

2.0/0.0 = inf, then inf*0.0 = 2.0

That is why division by zero and calculations in the reals with inf are 
undefined.
"

Feels as if math has a little short coming here.

Here is an idea:

How about:

Infinity * 0.0 = Anything 

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#11614

W dniu 2011-10-08 22:03, Kaba pisze:
>   wrote:
>> In article<MPG.28fa8e225336ca499899d3@news.cc.tut.fi>,
>> Kaba<kaba@nowhere.com>  wrote:
>>>
>>> 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.
>
> 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.
>
>>>    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.
>
> I disagree. Mathematics has one zero, the IEEE floating point has two.

Start thinking about IEEE floating point number as a probable number - 
number You can't measure exactly, there is always some immeasurable error.
In this case -0 means: number so small so we can assume it is zero, but 
we certain it is negative. +0 is same, but positive.

So You never can say it is zero, because You never can be certain it is. 
You can only compare to zero up to some precision.

-- 
Arivald

[toc] | [prev] | [next] | [standalone]

#11426

On Sat, 08 Oct 2011 17:43:50 +0300, Kaba wrote:

> * 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.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web