Topic: floating point issues
Author: Pete Becker <pete@versatilecoding.com>
Date: Sat, 31 Jan 2009 21:44:44 CST Raw View
On 2009-01-31 09:39:38 -0500, marc.glisse@gmail.com said:
> On Jan 30, 8:29 am, Pete Becker <p...@versatilecoding.com> wrote:
>>
>> On 2009-01-28 21:10:38 -0500, Jiang <goo.mai...@yahoo.com> said:
>>>
>>> As we know in C99, quite a few specifications on floating point
>>> arithmetic were added, notably :
>>
>>> 1. The limitation for floating point expressions rearrangement.
>>> (in 5.1.2.3, p14)
>>
>>> 2. Floating point arithmetic was specified in Annex F
>>> (normative, 20+ pages), and details for types,
>>> operators, conversions and floating point environment
>>> and optimization. Global and expression transformation
>>> behaviors are specified for optimization.
>>
>>> 3. Floating point environment. Rounding, exception
>>> and pragma for floating point are specified.
>>
>>> 4. Quite a few new types, functions, macros added.
>>> ( for example, isnan() ... )
>>
>>> So what is the current situation for C++ language? Will these
>>> improvements be added in the future, say standard C++1x ?
>>
>> 1 and 2 are not being added. 3 and 4 have been added.
>
> 3 is only partially added. For instance, it is missing the fenv_access
> pragma I think. Don't know about the others.
Good point. It's the library stuff that was added.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Jiang <goo.mail01@yahoo.com>
Date: Sun, 1 Feb 2009 11:43:06 CST Raw View
On Jan 31, 1:29 am, Pete Becker <p...@versatilecoding.com> wrote:
> On 2009-01-28 21:10:38 -0500, Jiang <goo.mai...@yahoo.com> said:
>
>
>
> > As we know in C99, quite a few specifications on floating point
> > arithmetic were added, notably :
>
> > 1. The limitation for floating point expressions rearrangement.
> > (in 5.1.2.3, p14)
>
> > 2. Floating point arithmetic was specified in Annex F
> > (normative, 20+ pages), and details for types,
> > operators, conversions and floating point environment
> > and optimization. Global and expression transformation
> > behaviors are specified for optimization.
>
> > 3. Floating point environment. Rounding, exception
> > and pragma for floating point are specified.
>
> > 4. Quite a few new types, functions, macros added.
> > ( for example, isnan() ... )
>
> > So what is the current situation for C++ language? Will these
> > improvements be added in the future, say standard C++1x ?
>
> 1 and 2 are not being added. 3 and 4 have been added.
>
Sorry here is another question, only the library stuffs (3 and 4,
well, not all of them) are enough for constructing a reliable
floating point arithmetic environment ?
I ask because several months ago, in clc++m, there was a
discussion about the possible [unreasonable] transformation
for floating point arithmetic (at that time, comp.std.c++ was
still not available),
http://preview.tinyurl.com/avngb9
and there was an example, for the following transformation,
code 1: x = a - (a - b)
->
code 2: x = b
, sure it is not valid at all according to the general floating
point arithmetic rule, however IMHO the current C++
language specification does not disallow it explicitly.
The behavior is undefined and the result is depended on
the quality of the implementation.
Also there were quite a few questions concerned with
floating point arithmetic and floating point environment.
However, without a clear specification for these issues,
it is quite difficult to give a correct/useful answer.
Thanks for the hard working of the C++ standard
committee, now we do have several constructs added
to the holly standard. But from the view point of the
core language, may I say currently the floating point
issues are still in the undefined or unspecified stage?
Will we have a true/solid specification on it, just like
D language or even C99? If this is not possible in the
recent future, so what is the main problem here ?
Regards,
Jiang
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Jiang <goo.mail01@yahoo.com>
Date: Sun, 1 Feb 2009 11:43:44 CST Raw View
On Jan 31, 2:25 am, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 29, 9:10 am, Jiang <goo.mai...@yahoo.com> wrote:
>
> > As we know in C99, quite a few specifications on floating
> > point arithmetic were added, notably :
> > 1. The limitation for floating point expressions rearrangement.
> > (in 5.1.2.3, p14)
>
> That was already present in C90, and is present in C++98 and
> C++03.
Hey James, I failed to find it in the current C++ standard and
the latest draft. Would you please give me a pointer for it?
BTW, the rule I quoted is (C99, 5.1.2.3, p14):
Rearrangement for floating-point expressions is often
restricted because of limitations in precision as well as
range. The implementation cannot generally apply the
mathematical associative rules for addition or multiplication,
nor the distributive rule, because of roundoff error, even in
the absence of overflow and underflow. Likewise,
implementations cannot generally replace decimal
constants in order to rearrange expressions. In the
following fragment, rearrangements suggested by
mathematical rules for real numbers are often not
valid (see F.8).
double x, y, z;
/* ... */
x = (x * y) * z; // not equivalent tox *= y * z;
z = (x - y) + y ; // not equivalent toz = x;
z = x + x * y; // not equivalent toz = x * (1.0 + y);
y = x / 5.0; // not equivalent toy = x * 0.2;
Also we see this rule further quotes Annex F of C99,
which is not available in C++ language standard in
my mind.
Regards,
Jiang
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kanze <james.kanze@gmail.com>
Date: Mon, 2 Feb 2009 09:49:29 CST Raw View
On Feb 1, 6:43 pm, Jiang <goo.mai...@yahoo.com> wrote:
> On Jan 31, 1:29 am, Pete Becker <p...@versatilecoding.com> wrote:
[...]
> and there was an example, for the following transformation,
> code 1: x = a - (a - b)
> ->
> code 2: x = b
> , sure it is not valid at all according to the general
> floating point arithmetic rule, however IMHO the current C++
> language specification does not disallow it explicitly.
The current C++ language specification defines the expression
"a - (a - b)" to be just that, "a - (a - b)". And
implementation is only allowed to generate something different
if it can prove that the observable behavior of the program will
not be changed.
> The behavior is undefined and the result is depended on the
> quality of the implementation.
Certain aspects of the behavior are unspecified: the precision
of the floating point operations, to begin with, and whether the
intermediate values are representable in the type (float or
double) or not. As far as I know, this is the case in C as
well. Unless the compiler knows something about the possible
values of a and b (e.g. if it can prove that a or b is 0.0, or
that b is much less than a), it must subtract b from a, then
subtract the results from a.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kanze <james.kanze@gmail.com>
Date: Mon, 2 Feb 2009 09:48:24 CST Raw View
On Feb 1, 6:43 pm, Jiang <goo.mai...@yahoo.com> wrote:
> On Jan 31, 2:25 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Jan 29, 9:10 am, Jiang <goo.mai...@yahoo.com> wrote:
> > > As we know in C99, quite a few specifications on floating
> > > point arithmetic were added, notably :
> > > 1. The limitation for floating point expressions rearrangement.
> > > (in 5.1.2.3, p14)
> > That was already present in C90, and is present in C++98 and
> > C++03.
> Hey James, I failed to find it in the current C++ standard and
> the latest draft. Would you please give me a pointer for it?
Pretty much all of 1.9. The standard precisely specifies the
semantics of the abstract machine (which do not involve any
rearrangement), and then gives the implementation the right to
do anything it wants (including rearrange), as long as the
"observable behavior" is not changed.
> BTW, the rule I quoted is (C99, 5.1.2.3, p14):
> Rearrangement for floating-point expressions is often
> restricted because of limitations in precision as well as
> range. The implementation cannot generally apply the
> mathematical associative rules for addition or
> multiplication, nor the distributive rule, because of
> roundoff error, even in the absence of overflow and
> underflow. Likewise, implementations cannot generally
> replace decimal constants in order to rearrange
> expressions. In the following fragment, rearrangements
> suggested by mathematical rules for real numbers are often
> not valid (see F.8).
> double x, y, z;
> /* ... */
> x = (x * y) * z; // not equivalent tox *= y * z;
> z = (x - y) + y ; // not equivalent toz = x;
> z = x + x * y; // not equivalent toz = x * (1.0 + y);
> y = x / 5.0; // not equivalent toy = x * 0.2;
Note that the part you're actually quoting is not normative;
it's just an example of the effects of rules which were
specified above. The example in the C++ standard is in
paragraph 15 of 1.9, and uses integral arithmetic, rather than
floating point, but the effect is the same.
And of course, this isn't something that was added to C99. It
was already present, in exactly the same form, in C90.
> Also we see this rule further quotes Annex F of C99, which is
> not available in C++ language standard in my mind.
Annex F doesn't apply to all implementations of C90, only those
supporting IEC 60559. I've not actually verified the details,
but I would expect that most of what in C depends on the macro
__STDC_IEC_559__ is covered by std::numeric_limits< float
>::is_iec559 in C++; I'd check what exactly the fact that this
>value is true implies in C++, and whether there is any real
>semantic difference with regards to what is guaranteed in Annex
>F of C99.
FWIW: I would like to see C++ adopt the macro __STDC_IEC_559__
as well, more for compatibility reasons than anything else.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Pavel Minaev <int19h@gmail.com>
Date: Wed, 4 Feb 2009 09:38:49 CST Raw View
On Feb 2, 7:49 am, James Kanze <james.ka...@gmail.com> wrote:
> The current C++ language specification defines the expression
> "a - (a - b)" to be just that, "a - (a - b)". And
> implementation is only allowed to generate something different
> if it can prove that the observable behavior of the program will
> not be changed.
>
> Certain aspects of the behavior are unspecified: the precision
> of the floating point operations, to begin with, and whether the
> intermediate values are representable in the type (float or
> double) or not. As far as I know, this is the case in C as
> well. Unless the compiler knows something about the possible
> values of a and b (e.g. if it can prove that a or b is 0.0, or
> that b is much less than a), it must subtract b from a, then
> subtract the results from a.
Wouldn't an implementation be fully within its right to declare that,
for this particular expression, the precision of floating point
operations is just "large enough", in which case the optimization as
described in the original post is entirely legitimate by present
rules? I believe that, the Standard doesn't require the precision to
be the same for all expressions within the program, or even for
different evaluations of the same expression.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kanze <james.kanze@gmail.com>
Date: Fri, 6 Feb 2009 03:38:46 CST Raw View
On Feb 4, 4:38 pm, Pavel Minaev <int...@gmail.com> wrote:
> On Feb 2, 7:49 am, James Kanze <james.ka...@gmail.com> wrote:
> > The current C++ language specification defines the
> > expression "a - (a - b)" to be just that, "a - (a - b)".
> > And implementation is only allowed to generate something
> > different if it can prove that the observable behavior of
> > the program will not be changed.
> > Certain aspects of the behavior are unspecified: the
> > precision of the floating point operations, to begin with,
> > and whether the intermediate values are representable in the
> > type (float or double) or not. As far as I know, this is
> > the case in C as well. Unless the compiler knows something
> > about the possible values of a and b (e.g. if it can prove
> > that a or b is 0.0, or that b is much less than a), it must
> > subtract b from a, then subtract the results from a.
> Wouldn't an implementation be fully within its right to
> declare that, for this particular expression, the precision of
> floating point operations is just "large enough", in which
> case the optimization as described in the original post is
> entirely legitimate by present rules? I believe that, the
> Standard doesn't require the precision to be the same for all
> expressions within the program, or even for different
> evaluations of the same expression.
It requires that the precision be documented. What precision
could you document which was "just large enough"? And who would
buy a compiler whose precision is documented as 0 bits? (The
precision isn't required to always be the same, for the simple
reason that it isn't on some common architectures, like the IBM
z architecture. But it is within documentable bounds.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Jiang <goo.mail01@yahoo.com>
Date: Fri, 6 Feb 2009 03:38:04 CST Raw View
On Feb 3, 12:48 am, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 1, 6:43 pm, Jiang <goo.mai...@yahoo.com> wrote:
>
> > On Jan 31, 2:25 am, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jan 29, 9:10 am, Jiang <goo.mai...@yahoo.com> wrote:
> > > > As we know in C99, quite a few specifications on floating
> > > > point arithmetic were added, notably :
> > > > 1. The limitation for floating point expressions rearrangement.
> > > > (in 5.1.2.3, p14)
> > > That was already present in C90, and is present in C++98 and
> > > C++03.
> > Hey James, I failed to find it in the current C++ standard and
> > the latest draft. Would you please give me a pointer for it?
>
> Pretty much all of 1.9. The standard precisely specifies the
> semantics of the abstract machine (which do not involve any
> rearrangement), and then gives the implementation the right to
> do anything it wants (including rearrange), as long as the
> "observable behavior" is not changed.
>
I showed my point for "observable behavior" in another post.
>
>
> > BTW, the rule I quoted is (C99, 5.1.2.3, p14):
> > Rearrangement for floating-point expressions is often
> > restricted because of limitations in precision as well as
> > range. The implementation cannot generally apply the
> > mathematical associative rules for addition or
> > multiplication, nor the distributive rule, because of
> > roundoff error, even in the absence of overflow and
> > underflow. Likewise, implementations cannot generally
> > replace decimal constants in order to rearrange
> > expressions. In the following fragment, rearrangements
> > suggested by mathematical rules for real numbers are often
> > not valid (see F.8).
> > double x, y, z;
> > /* ... */
> > x = (x * y) * z; // not equivalent tox *= y * z;
> > z = (x - y) + y ; // not equivalent toz = x;
> > z = x + x * y; // not equivalent toz = x * (1.0 + y);
> > y = x / 5.0; // not equivalent toy = x * 0.2;
>
> Note that the part you're actually quoting is not normative;
> it's just an example of the effects of rules which were
> specified above. The example in the C++ standard is in
> paragraph 15 of 1.9, and uses integral arithmetic, rather than
> floating point, but the effect is the same.
Sorry here I beg to disagree.
The rule I quoted is normative in my mind. This rule is not
available in C90 and was added in C99. Just as the other
rule for integer rearrange limitation (overflow issue), this
rule precisely defined the "observable behavior" for
floating point expressions. And, several key points for
floating point issue, such as precision, roundoff error,
are clearly emphasized by this rule.
> > Also we see this rule further quotes Annex F of C99, which is
> > not available in C++ language standard in my mind.
>
> Annex F doesn't apply to all implementations of C90, only those
> supporting IEC 60559. I've not actually verified the details,
> but I would expect that most of what in C depends on the macro
> __STDC_IEC_559__ is covered by std::numeric_limits< float
>
> >::is_iec559 in C++; I'd check what exactly the fact that this
> >value is true implies in C++, and whether there is any real
> >semantic difference with regards to what is guaranteed in Annex
> >F of C99.
>
> FWIW: I would like to see C++ adopt the macro __STDC_IEC_559__
> as well, more for compatibility reasons than anything else.
Even we can define it in C++ language, I doubt how useful it is.
Currently most of the C++ compiler explicitly specify is_iec559
as true for both float and double type, however as shown in
clc++m, this is not always true (especially for NaN issue).
Regards,
Jiang
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kuyper <jameskuyper@verizon.net>
Date: Fri, 6 Feb 2009 03:40:52 CST Raw View
James Kanze wrote:
....
>
> Certain aspects of the behavior are unspecified: the precision
> of the floating point operations, to begin with, and whether the
> intermediate values are representable in the type (float or
> double) or not. As far as I know, this is the case in C as
> well.
In C99, the FLT_EVAL_METHOD macro defined in <float.h> provides
information about how intermediate values are represented. Also, if
__STDC_IEC_559__ is pre-defined by an implementation, it is required
to provide an implementation of floating point operations that
conforms to the specification in annex F, which specified C99 language
support for IEC 60559 (previously designated as IEC 559:1989 ==
ANSI/IEEE 754-1985). IEC 60559 provides very tight specifications of
the precision of floating point operations.
The C++ standard is much more direct about this issue; if
std::numeric_limits<T>::is_iec559 != false, then T must adhere to IEC
559 (IEEE 754).
I'm not sure when it was added, but n2723.pdf indicates that <cfloat>
must also define FLT_EVAL_METHOD, just like C99's <float.h>.
Thus, while neither standard imposes precision requirements of it's
own, both standards provide ways of determining whether the rather
tight precision specifications of IEC 559 apply.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Jiang <goo.mail01@yahoo.com>
Date: Fri, 6 Feb 2009 03:49:32 CST Raw View
On Feb 3, 12:49 am, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 1, 6:43 pm, Jiang <goo.mai...@yahoo.com> wrote:
>
> > On Jan 31, 1:29 am, Pete Becker <p...@versatilecoding.com> wrote:
>
> [...]
>
> > and there was an example, for the following transformation,
> > code 1: x = a - (a - b)
> > ->
> > code 2: x = b
> > , sure it is not valid at all according to the general
> > floating point arithmetic rule, however IMHO the current C++
> > language specification does not disallow it explicitly.
>
> The current C++ language specification defines the expression
> "a - (a - b)" to be just that, "a - (a - b)". And
> implementation is only allowed to generate something different
> if it can prove that the observable behavior of the program will
> not be changed.
The problem is, how can we prove the "observable behavior"
will not be changed, well, without first making the behavior
specification available?
IMHO, without the specification it is quite difficult, if possible,
to do the verification, which totally depends on the
implementor's understanding for floating point related
arithmetic.
An extreme example, as I posted in the original thread,
why implementors can not use rules for *real number*
to prove "observable behavior" ?
>
> > The behavior is undefined and the result is depended on the
> > quality of the implementation.
>
> Certain aspects of the behavior are unspecified: the precision
> of the floating point operations, to begin with, and whether the
> intermediate values are representable in the type (float or
> double) or not. As far as I know, this is the case in C as
> well. Unless the compiler knows something about the possible
> values of a and b (e.g. if it can prove that a or b is 0.0, or
> that b is much less than a), it must subtract b from a, then
> subtract the results from a.
>
I doubt any compilers will actually do this kinds of range checking.
And IMHO user specified grouping should always be respected
and rearrangement for floating point arithmetic should simply
be banned in the language specification.
Forgive me if this is off-topic, but as we know hardware supports
for IEEE floating point arithmetic was available quite long time
ago, and unfortunately most of the *software* can not fully make
a good use of them. So what is the main problems here ?
Regards,
Jiang
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kanze <james.kanze@gmail.com>
Date: Sat, 7 Feb 2009 11:12:22 CST Raw View
On Feb 6, 10:38 am, Jiang <goo.mai...@yahoo.com> wrote:
> On Feb 3, 12:48 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Feb 1, 6:43 pm, Jiang <goo.mai...@yahoo.com> wrote:
> > > On Jan 31, 2:25 am, James Kanze <james.ka...@gmail.com> wrote:
> > > > On Jan 29, 9:10 am, Jiang <goo.mai...@yahoo.com> wrote:
> > > > > As we know in C99, quite a few specifications on floating
> > > > > point arithmetic were added, notably :
> > > > > 1. The limitation for floating point expressions rearrangement.
> > > > > (in 5.1.2.3, p14)
> > > > That was already present in C90, and is present in C++98 and
> > > > C++03.
> > > Hey James, I failed to find it in the current C++ standard and
> > > the latest draft. Would you please give me a pointer for it?
> > Pretty much all of 1.9. The standard precisely specifies
> > the semantics of the abstract machine (which do not involve
> > any rearrangement), and then gives the implementation the
> > right to do anything it wants (including rearrange), as long
> > as the "observable behavior" is not changed.
> I showed my point for "observable behavior" in another post.
> > > BTW, the rule I quoted is (C99, 5.1.2.3, p14):
> > > Rearrangement for floating-point expressions is often
> > > restricted because of limitations in precision as well as
> > > range. The implementation cannot generally apply the
> > > mathematical associative rules for addition or
> > > multiplication, nor the distributive rule, because of
> > > roundoff error, even in the absence of overflow and
> > > underflow. Likewise, implementations cannot generally
> > > replace decimal constants in order to rearrange
> > > expressions. In the following fragment, rearrangements
> > > suggested by mathematical rules for real numbers are often
> > > not valid (see F.8).
> > > double x, y, z;
> > > /* ... */
> > > x = (x * y) * z; // not equivalent tox *= y * z;
> > > z = (x - y) + y ; // not equivalent toz = x;
> > > z = x + x * y; // not equivalent toz = x * (1.0 + y);
> > > y = x / 5.0; // not equivalent toy = x * 0.2;
> > Note that the part you're actually quoting is not normative;
> > it's just an example of the effects of rules which were
> > specified above. The example in the C++ standard is in
> > paragraph 15 of 1.9, and uses integral arithmetic, rather
> > than floating point, but the effect is the same.
> Sorry here I beg to disagree.
> The rule I quoted is normative in my mind.
But not in the standard. Notes and examples are not normative,
according to ISO.
> This rule is not available in C90 and was added in C99.
The rules concerning the right to reorder expressions have not
changed since C90. The way they are expressed isn't always the
same, but any changes are just clarifications.
> Just as the other rule for integer rearrange limitation
> (overflow issue), this rule precisely defined the "observable
> behavior" for floating point expressions. And, several key
> points for floating point issue, such as precision, roundoff
> error, are clearly emphasized by this rule.
The example emphasized the consequences of the rule.
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Jiang <goo.mail01@yahoo.com>
Date: Thu, 29 Jan 2009 02:10:38 CST Raw View
As we know in C99, quite a few specifications on floating point
arithmetic were added, notably :
1. The limitation for floating point expressions rearrangement.
(in 5.1.2.3, p14)
2. Floating point arithmetic was specified in Annex F
(normative, 20+ pages), and details for types,
operators, conversions and floating point environment
and optimization. Global and expression transformation
behaviors are specified for optimization.
3. Floating point environment. Rounding, exception
and pragma for floating point are specified.
4. Quite a few new types, functions, macros added.
( for example, isnan() ... )
So what is the current situation for C++ language? Will these
improvements be added in the future, say standard C++1x ?
Regards,
Jiang
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Pete Becker <pete@versatilecoding.com>
Date: Fri, 30 Jan 2009 10:29:15 CST Raw View
On 2009-01-28 21:10:38 -0500, Jiang <goo.mail01@yahoo.com> said:
> As we know in C99, quite a few specifications on floating point
> arithmetic were added, notably :
>
> 1. The limitation for floating point expressions rearrangement.
> (in 5.1.2.3, p14)
>
> 2. Floating point arithmetic was specified in Annex F
> (normative, 20+ pages), and details for types,
> operators, conversions and floating point environment
> and optimization. Global and expression transformation
> behaviors are specified for optimization.
>
> 3. Floating point environment. Rounding, exception
> and pragma for floating point are specified.
>
> 4. Quite a few new types, functions, macros added.
> ( for example, isnan() ... )
>
> So what is the current situation for C++ language? Will these
> improvements be added in the future, say standard C++1x ?
>
1 and 2 are not being added. 3 and 4 have been added.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kanze <james.kanze@gmail.com>
Date: Fri, 30 Jan 2009 11:25:01 CST Raw View
On Jan 29, 9:10 am, Jiang <goo.mai...@yahoo.com> wrote:
> As we know in C99, quite a few specifications on floating
> point arithmetic were added, notably :
> 1. The limitation for floating point expressions rearrangement.
> (in 5.1.2.3, p14)
That was already present in C90, and is present in C++98 and
C++03.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: marc.glisse@gmail.com
Date: Sat, 31 Jan 2009 14:39:38 CST Raw View
On Jan 30, 8:29 am, Pete Becker <p...@versatilecoding.com> wrote:
> On 2009-01-28 21:10:38 -0500, Jiang <goo.mai...@yahoo.com> said:
> > As we know in C99, quite a few specifications on floating point
> > arithmetic were added, notably :
>
> > 1. The limitation for floating point expressions rearrangement.
> > (in 5.1.2.3, p14)
>
> > 2. Floating point arithmetic was specified in Annex F
> > (normative, 20+ pages), and details for types,
> > operators, conversions and floating point environment
> > and optimization. Global and expression transformation
> > behaviors are specified for optimization.
>
> > 3. Floating point environment. Rounding, exception
> > and pragma for floating point are specified.
>
> > 4. Quite a few new types, functions, macros added.
> > ( for example, isnan() ... )
>
> > So what is the current situation for C++ language? Will these
> > improvements be added in the future, say standard C++1x ?
>
> 1 and 2 are not being added. 3 and 4 have been added.
3 is only partially added. For instance, it is missing the fenv_access
pragma I think. Don't know about the others.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]