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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#11421

On 10/08/2011 06:23 PM, nmm1@cam.ac.uk wrote:
> In article <j6qf8u$hji$1@dont-email.me>,
> James Kuyper  <jameskuyper@verizon.net> 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.
> 
> 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.
-- 
James Kuyper

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

#11438

In article <j6qte6$pd$1@dont-email.me>,
James Kuyper  <jameskuyper@verizon.net> wrote:
>
>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.

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

#11577

On Oct 9, 10:01 am, n...@cam.ac.uk 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).  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.

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

#11580

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


Regards,
Nick Maclaren.

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

#11587

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.

I've seen claims, (possibly from you?), that it's possible for a
conforming implementation to generate code for a+b+c which calculates
the result of a+b after (sic!) the result of that very calculation has
already been added to c. However, when I asked for details of how that
was supposed to work, I learned that the supposedly-conforming code
calculated a+b twice - once for adding to c, and the second time for the
sole purpose (as far as I could tell) of "proving" that it's permissible
to compute it afterward.

I'll concede that the as-if rule allows spurious extra computations to
be inserted at any time, so long as they don't affect the final result.
However, for an implementation that pre-#defines __STDC_IEC_559__, it
seems to me that the "final result" necessarily includes the values of
testable floating point environment flags; at least, if it occurs within
code that actual performs such tests.

You know this, but for the benefit of those who don't: C99 added
<fenv.h>, providing portable C support for such flags.
I remember a long discussion we had (partly off-line) in which you
claimed that C99's provision of such support, in that form, made the
situation worse than it would have been without it. You presented a very
real list of weaknesses in the specifications, primarily consisting of
things that are optional which, if I understood your arguments, could
only be considered useful if mandatory. It seems to me that if a feature
is optional, but I have a portable way of testing whether it's
supported, and a portable way of making use of it if it is supported,
that's unambiguously more useful than having nothing portably specified
about that feature - I never understood your claims to the contrary.

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

#11595

In article <4E95BBEE.3000005@verizon.net>,
James Kuyper  <jameskuyper@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.

Nor do I.

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

Well, yes, but I never said it wasn't!  What I said was that there
were lots of OTHER interpretations, which were ALSO defensible.

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

Unfortunately, it then contradicts that in all of its statements
about side-effect ordering, and there is nothing in the standard
that distinguishes the evaluation of an assignment operator from
the evaluation of any other operator!

I could respond to the rest of your points in detail, but I am
afraid that I don't have the time, so will select just one.

>However, for an implementation that pre-#defines __STDC_IEC_559__, it
>seems to me that the "final result" necessarily includes the values of
>testable floating point environment flags; at least, if it occurs within
>code that actual performs such tests.

I can tell you that most of the proponents of that agree with you;
unfortunately a lot of WG14 didn't, and so it was left up in the air.

>You know this, but for the benefit of those who don't: C99 added
><fenv.h>, providing portable C support for such flags.

I know damn well it didn't!

Firstly, any ambiguous specification does NOT enable portability,
because the programmer assumes one thing and the implementor another.
In my experience, that is the cause of something like 85% of the
nasty bugs in C code written by experienced programmers!

Secondly, the problem is NOT solely optionality (as you claimed
that I showed) - it's serious ambiguity and even inconsistency.
Here is one example of the problem.

5.1.2.3 Program execution footnote 11:

    ...  Floating-point operations implicitly set the status flags; ....
    Implementations that support such floating-point state are required
    to regard changes to it as side effects  ....

6.5 Expressions para. 5:

    If an exceptional condition occurs during the evaluation of an
    expression (that is, if the result is not mathematically defined or
    not in the range of representable values for its type), the behavior
    is undefined.

7.6 Floating-point environment para. 1:

    ...  A floating-point status flag is a system variable whose value
    is set (but never cleared) when a floating-point exception is
    raised, which occurs as a side effect of exceptional floating-point
    arithmetic to provide auxiliary information.  ...

Now, 6.5 states unequivocally that exceptional conditions lead to
undefined behaviour, which is assuredly sometimes the case.  But
Annex F states they are not if __STDC_IEC_559__ is defined.  Why
do you claim that the latter overrides the former, and not the
former the latter?

That would have been trivial to fix, but there are a zillion other
such inconsistencies, all of which give scope to implementors to
do something that the programmer doesn't expect, and where the
implementation can still claim to be conforming.  That's NOT a
recipe for portability!


Regards,
Nick Maclaren.

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

#11596

On 10/12/2011 01:41 PM, nmm1@cam.ac.uk wrote:
> In article <4E95BBEE.3000005@verizon.net>,
> James Kuyper  <jameskuyper@verizon.net> wrote:
...
>> 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.
> 
> Well, yes, but I never said it wasn't!  What I said was that there
> were lots of OTHER interpretations, which were ALSO defensible.

I'm sure that there are alternative interpretations, many of them
defensible. The relevant thing would be a defensible interpretation that
differs from the one I gave in ways that would be problematic. Every
problematic interpretation I could come up with was indefensible for
reasons directly connected to the fact that was problematic. Could you
give an example?

...
>> However, for an implementation that pre-#defines __STDC_IEC_559__, it
>> seems to me that the "final result" necessarily includes the values of
>> testable floating point environment flags; at least, if it occurs within
>> code that actual performs such tests.
> 
> I can tell you that most of the proponents of that agree with you;
> unfortunately a lot of WG14 didn't, and so it was left up in the air.

An argument against that interpretation would be more relevant than an
assertion that there are people who believe in the validity of that
argument.

>> You know this, but for the benefit of those who don't: C99 added
>> <fenv.h>, providing portable C support for such flags.
> 
> I know damn well it didn't!

It might not have done it as well as you might have liked - but it did
do it. :-)

...
> Secondly, the problem is NOT solely optionality (as you claimed
> that I showed) ...

That's the main thing I remembered you arguing; I didn't mean to imply
that the arguments I remembered were the only ones you actually made -
my memory's not that good.

> ... - it's serious ambiguity and even inconsistency.
> Here is one example of the problem.
> 
> 5.1.2.3 Program execution footnote 11:
> 
>     ...  Floating-point operations implicitly set the status flags; ....
>     Implementations that support such floating-point state are required
>     to regard changes to it as side effects  ....
> 
> 6.5 Expressions para. 5:
> 
>     If an exceptional condition occurs during the evaluation of an
>     expression (that is, if the result is not mathematically defined or
>     not in the range of representable values for its type), the behavior
>     is undefined.
> 
> 7.6 Floating-point environment para. 1:
> 
>     ...  A floating-point status flag is a system variable whose value
>     is set (but never cleared) when a floating-point exception is
>     raised, which occurs as a side effect of exceptional floating-point
>     arithmetic to provide auxiliary information.  ...
> 
> Now, 6.5 states unequivocally that exceptional conditions lead to
> undefined behaviour, which is assuredly sometimes the case.  But
> Annex F states they are not if __STDC_IEC_559__ is defined.  Why
> do you claim that the latter overrides the former, and not the
> former the latter?

Specifications for particular cases are routinely considered to override
any conflicting specification covering more the general cases; the
standard would require a lot of complicated re-wording if that weren't
true. #ifdef __STDC_IEC_559__ is more specific than #ifndef.


> That would have been trivial to fix,

What fix do you think would be needed?
"An implementation that defines __STDC_IEC_559_ _ shall conform to the
specifications in this annex." (F1.1). Should they add the words "even
in circumstances where the rest of the standard says that the behavior
is undefined."? That would seem redundant with the simple word "shall"
to me. What does the "shall" mean in this context if it doesn't already
imply that?

4p1: "‘‘shall’’ is to be interpreted as a requirement on an
implementation or on a program;" This is clearly a requirement imposed
on the implementation.

3.4.3p1: undefined behavior
"behavior, ... for which this International Standard imposes no
requirements."

Annex F is a part of "this International Standard", is labeled as
normative, and imposes requirements for the behavior when an
implementation chooses to pre-#define __STDC_IEC_559__. That doesn't
seem to meet the standard's definition of "undefined behavior".

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

#11600

In article <4E95EB4F.20903@verizon.net>,
James Kuyper  <jameskuyper@verizon.net> wrote:
>
>>> 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.
>> 
>> Well, yes, but I never said it wasn't!  What I said was that there
>> were lots of OTHER interpretations, which were ALSO defensible.
>
>I'm sure that there are alternative interpretations, many of them
>defensible. The relevant thing would be a defensible interpretation that
>differs from the one I gave in ways that would be problematic. Every
>problematic interpretation I could come up with was indefensible for
>reasons directly connected to the fact that was problematic. Could you
>give an example?

Dammit, you have JUST seen TWO!!!

One is that the BNF defines the execution order, except where
explicitly varied.

The other is that the grouping defines only the operator precedence
and not how the expression is evaluated.  AS I SAID, I was active
in WG14 at the time, and I understood that to be the nearest it
got to a consensus.

>>> You know this, but for the benefit of those who don't: C99 added
>>> <fenv.h>, providing portable C support for such flags.
>> 
>> I know damn well it didn't!
>
>It might not have done it as well as you might have liked - but it did
>do it. :-)

No, it didn't, BECAUSE IT'S NOT PORTABLE.  That isn't just theory,
but the experience of being in WG14, interaction with vendors and
actually running tests.

>Specifications for particular cases are routinely considered to override
>any conflicting specification covering more the general cases; the
>standard would require a lot of complicated re-wording if that weren't
>true. #ifdef __STDC_IEC_559__ is more specific than #ifndef.

Well, that's NOT how they have been normally interpreted on the WG14
mailing list - I don't have the time to try to remember specific
examples now.  It IS the case for implicit undefined behaviour, but
this is EXPLICIT.

>> That would have been trivial to fix,
>
>What fix do you think would be needed?
>"An implementation that defines __STDC_IEC_559_ _ shall conform to the
>specifications in this annex." (F1.1). Should they add the words "even
>in circumstances where the rest of the standard says that the behavior
>is undefined."? That would seem redundant with the simple word "shall"
>to me. What does the "shall" mean in this context if it doesn't already
>imply that?

Please do think beyond black and white.

Does it apply when pragma FENV_ACCESS is not set and, if so, exactly
how?  Yes, there is an 'obvious' best choice there.

What does it mean together with FP_CONTRACT or CX_LIMITED_RANGE on?
I can tell you that the BSI never got an answer out of WG14 on that
one!

Does it apply to the large amount of the C language and library NOT
mentioned in Annex F and, if so, exactly how?

Under what conditions does it apply if any function from an external
library is linked in?  And, if you think there is a simple answer
to that, I recommend a year or two in an ISO standards committee.


Anyway, I don't have time for more.


Regards,
Nick Maclaren.

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

#11604

On Oct 12, 3:44 pm, n...@cam.ac.uk wrote:

>
> No, it didn't, BECAUSE IT'S NOT PORTABLE.  


You scare me, Nick.

That's only fair, because, to the extent that you pay attention to
anything I say, I probably scare you.

What you are really saying is that, in a code where mysterious and
unreliable things are happening, you can't blindly transfer the code
from one ad hoc hardware and software standard to another.  Listen
very carefully:

THAT'S A GOOD THING.

It may be the last thing standing between us and careerists who don't
have a clue "validating" their results by transferring a meaningless
calculation from one machine to another with no clue that something
totally crazy is going on.

The idea that the universe would be a safer place if only people would
listen to you doesn't even pass the laugh test.

Robert.

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

#11607

On Wed, 12 Oct 2011 18:11:12 -0700, Robert Myers wrote:
> It may be the last thing standing between us and careerists who don't
> have a clue "validating" their results by transferring a meaningless
> calculation from one machine to another with no clue that something
> totally crazy is going on.

Nick does have a good point though, notwithstanding the last couple of 
posts in which the authors asserted that C (at least) now *does* specify 
a total order of operations within expressions (even ones that appear 
ambiguous because of expectations of associativity).  I didn't realize 
that, and I'm still not sure that I believe them.

Nick's point (I believe) is that floating point arithmetic is fraught, 
because it is fairly fundamentally unlike the mathematics that expression-
based languages appear to be offering.  In maths and exact computer 
arithmetic (eg integer), addition is associative and a bunch of other 
nice rules for "simplification" apply.  In floating point they don't, 
because every floating point multiply (a * b), for example, is really 
something like round(_g_current_FPU_rounding_mode, multiply(a,b)), and 
every addition or subtraction is even more complicated, with a bunch of 
normalizations thrown in for good measure.  Round is, naturally, a lossy 
operation.  Throw in exceptions that can be raised in a bunch of ways and 
you wind up with something that can only really be reasoned about as a 
discrete sequence of assembly-language-like operations that both produce 
results and mutate and depend on the "system state" in obscure and 
platform-dependent ways.  I haven't even mentioned an IEEE standard here: 
it ought to be possible to define a stateless floating point method, 
where rounding modes were explicit in the instructions and exceptions 
were either defined away as in-band values or made of precice exceptions, 
but I've never heard of it being done.

Clearly you can still have parallelism between independent operations, 
but you can't manipulate floating point expressions that look like maths 
as though they were maths, at least not without giving up being able to 
reason about the answer.

Which I think just emphasises your point, too: people doing floating 
point need to have a clue...

Cheers,

-- 
Andrew

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

#11611

In article <9fn5cjFsr4U1@mid.individual.net>,
Andrew Reilly  <areilly---@bigpond.net.au> wrote:
>
>Nick's point (I believe) is that floating point arithmetic is fraught, 
>because it is fairly fundamentally unlike the mathematics that expression-
>based languages appear to be offering.  ... 

Actually, no.  It's tricky, but not THAT tricky.  My real point is
that the C99 and other modern 'improvements' make it appear to the
naive as if it is more portable and reliable, but actually introduce
ten times as many portability and reliability problems as they solve.

Almost everyone who has actually tried it has discovered that, but
most people code for one system, run a couple of sets of well-behaved
data, and then claim that their program is portable and robust and
any failures must be the fault of the compiler!

>Clearly you can still have parallelism between independent operations, 
>but you can't manipulate floating point expressions that look like maths 
>as though they were maths, at least not without giving up being able to 
>reason about the answer.

Yes, you can.  Look at most of the classic numerical analysis books.
You have to do it rather differently, and very, very few modern
'computer scientists' would know how to start.  Wilkinson and Reinsch
"The Algebraic Eigenvalue Problem" is one example of such reasoning
that I have used in the past.

>Which I think just emphasises your point, too: people doing floating 
>point need to have a clue...

Oh, THERE, I am in 100% agreement.  When I teach it, I tell people
that the key is to think floating-point, not mathematical real,
but that 50+ years of Fortran experience shows that it's not as
hard as all that.  Inter alia, we used to write code that was both
reliable and portable across a range of arithmetics that most
people nowadays cannot imagine :-)

There ARE some books on how to write robust, portable floating-point
code, but all are very old-fashioned.  And there were a large number
of experiments showing both that the exact details of the arithmetic
didn't matter much (though directed versus nearest rounding did),
and that relying on the the exact details led to the code being LESS
robust, rather than more.

Of courses, that's now all regarded as heresy ....


Regards,
Nick Maclaren.

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

#11619

On Oct 13, 4:48 am, Andrew Reilly <areilly...@bigpond.net.au> wrote:
> Nick does have a good point though, notwithstanding the last couple of
> posts in which the authors asserted that C (at least) now *does* specify
> a total order of operations within expressions (even ones that appear
> ambiguous because of expectations of associativity).  I didn't realize
> that, and I'm still not sure that I believe them.

The point is that there is no difference in C between a+b+c
and (a+b)+c.  Any order implied by the latter is also implied
by the former.  The point is that operator precedence in C
uniquely defines the "evaluation tree".  I don't believe anyone
has asserted that there is a total order of all computations
within the tree, i.e. between the LHS and RHS of a binary
operator.

> Nick's point (I believe) is that floating point arithmetic is fraught

We all know it that floating-point arithmetic is not the same as
real arithmetic.  Nick appears to be making an abstruse point,
about the relationship between ISO C and IEEE 754, without
being able to explain what that point is.

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

#11682

On Oct 12, 11:48 pm, Andrew Reilly <areilly...@bigpond.net.au> wrote:
>
> Nick does have a good point though, notwithstanding the last couple of
> posts in which the authors asserted that C (at least) now *does* specify
> a total order of operations within expressions (even ones that appear
> ambiguous because of expectations of associativity).  I didn't realize
> that, and I'm still not sure that I believe them.
>
> Nick's point (I believe) is that floating point arithmetic is fraught,
> because it is fairly fundamentally unlike the mathematics that expression-
> based languages appear to be offering.

<snip>  

> I haven't even mentioned an IEEE standard here:
> it ought to be possible to define a stateless floating point method,
> where rounding modes were explicit in the instructions and exceptions
> were either defined away as in-band values or made of precice exceptions,
> but I've never heard of it being done.
>

<snip>

> Which I think just emphasises your point, too: people doing floating
> point need to have a clue...
>

You make some good points that are worth remembering.

I'm not sure, though, that a stateless and platform-independent
definition of floating point arithmetic is either necessary or
desirable or even possible within the bounds of practical utility.

If the floating point details that people spend so much time on here
make all that much difference, there is probably something flaky about
either the algorithm or the code or both.  Given that at least some of
the people who spend so much time talking about this issue here
probably already understand the claim I just made, I don't understand
why this alchemist's pursuit of turning lead into gold continues.

Given the choice between hammering it into people that floating point
arithmetic is not for the naive or even necessarily replicable from
one situation to another, and inventing an arbitrary standard that
makes it at least make the same mistake every time, I'd prefer the
current chaos to artificial predictability.

I could and would and do make the same objection about the
correspondence to mathematics that you make for floating point
arithmetic to every code that purports to represent mathematics where
a differential operator appears in the calculation.  I know how to
make that correspondence precise and completely unarbitrary, but I am
repeatedly told that doing so is simply too expensive.

I conclude, as I believe I have said before, that this continuing
discussion is an instance of Nazrudin's lost key: looking where there
is light.  Given that many if not most codes that use floating point
arithmetic rely on absurd mathematics (repeatedly differentiating
derivatives that are piecewise continuous even only in theory), I just
can't understand all the fuss about the last bit (rounding), which
idealized properties floating point arithmetic does or does not
possess, or what arbitrary thing the hardware does when the algorithm
leads to a nonsensical or ambiguous result.

Robert.

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

#11698

On Fri, 14 Oct 2011 10:54:06 -0700, Robert Myers wrote:

> If the floating point details that people spend so much time on here
> make all that much difference, there is probably something flaky about
> either the algorithm or the code or both.

Well, yes.  I'm afraid that I have that particular rant on speed-dial, 
because I often find myself having to hose down the desire to produce bit-
exact test-suites for inherently unstable (or at least somewhat 
arbitrary) algorithms that just happen to behave in a particular way in 
floating point with a particular version of a compiler, with a particular 
set of command-line options.  Believe me, it happens a lot.

Cheers,

-- 
Andrew

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

#11726

Andrew Reilly wrote:
> On Fri, 14 Oct 2011 10:54:06 -0700, Robert Myers wrote:
>
>> If the floating point details that people spend so much time on here
>> make all that much difference, there is probably something flaky about
>> either the algorithm or the code or both.
>
> Well, yes.  I'm afraid that I have that particular rant on speed-dial,
> because I often find myself having to hose down the desire to produce bit-
> exact test-suites for inherently unstable (or at least somewhat
> arbitrary) algorithms that just happen to behave in a particular way in
> floating point with a particular version of a compiler, with a particular
> set of command-line options.  Believe me, it happens a lot.

I would in fact be much _more_ useful to have a mode where rounding was 
arbitrary/random, and could even impact one or more extra low bits.

I.e. if your code doesn't produce effectively the same results under 
such a regime, your algorithms are almost certainly broken.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

#12102

On 2011-10-15, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:

> I would in fact be much _more_ useful to have a mode where rounding was 
> arbitrary/random, and could even impact one or more extra low bits.

Intel tried something like that in the 90s :^)

-- 
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#12129

Jasen Betts <jasen@xnet.co.nz> writes:
> On 2011-10-15, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> > I would in fact be much _more_ useful to have a mode where rounding was 
> > arbitrary/random, and could even impact one or more extra low bits.
> 
> Intel tried something like that in the 90s :^)

Until Terje himself broke the feature!

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

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

#12142

Phil Carmody wrote:
> Jasen Betts<jasen@xnet.co.nz>  writes:
>> On 2011-10-15, Terje Mathisen<"terje.mathisen at tmsw.no">  wrote:
>>> I would in fact be much _more_ useful to have a mode where rounding was
>>> arbitrary/random, and could even impact one or more extra low bits.
>>
>> Intel tried something like that in the 90s :^)
>
> Until Terje himself broke the feature!

Rather fixed it again:

I did write most of the sw workaround for the FDIV (and FPATAN) bug on 
the Pentium.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

#12145

Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
> Phil Carmody wrote:
> > Jasen Betts<jasen@xnet.co.nz>  writes:
> >> On 2011-10-15, Terje Mathisen<"terje.mathisen at tmsw.no">  wrote:
> >>> I would in fact be much _more_ useful to have a mode where rounding was
> >>> arbitrary/random, and could even impact one or more extra low bits.
> >>
> >> Intel tried something like that in the 90s :^)
> >
> > Until Terje himself broke the feature!
> 
> Rather fixed it again:
> 
> I did write most of the sw workaround for the FDIV (and FPATAN) bug on
> the Pentium.

That's what I was trying to imply. If we're pretending the bug was 
feature, then your fix 'broke' it. (I was assuming FDIV was what was
being refered to.)

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

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

#12147

Phil Carmody wrote:
> Terje Mathisen<"terje.mathisen at tmsw.no">  writes:
>> I did write most of the sw workaround for the FDIV (and FPATAN) bug on
>> the Pentium.
>
> That's what I was trying to imply. If we're pretending the bug was
> feature, then your fix 'broke' it. (I was assuming FDIV was what was
> being refered to.)

OK, sorry for being particularly dense today.

FDIV did provide one sample point that was relevant though: It showed 
that pretty close to zero applications and their users noticed anything 
wrong even though divisions would drop 0 to 45 bits when the divisor hit 
one of those 5 in 1024 leading mantissa bit patterns.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

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

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

csiph-web