The machine epsilon

[Keith Thompson]

Re: The machine epsilon

jacob navia <jacob@jacob.re mcomp.frwrites:

CBFalconer wrote:

>jacob navia wrote:

>>Eric Sosman wrote:

>... snip ...

>>>I don't think so. The fraction of a normalized, non-zero, finite
>>>IEEE number has a value 0.5 <= f < 1, so unity is represented as
>>>two to the first times one-half: 2^1 * .100...000(2). The
>>>unbiased exponent value in the representation of unity is
>>>therefore one, not zero.
>>I think you forget the implicit bit Eric.

>In some systems. Not necessarily C. Do try to stay on topic.
>>

The C standard assumes IEEE 754 representation Chuck.

It most certainly does not, and it never has.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Re: The machine epsilon

Keith Thompson wrote:

jacob navia <jacob@jacob.re mcomp.frwrites:

>CBFalconer wrote:

>>jacob navia wrote:
>>>Eric Sosman wrote:
>>... snip ...
>>>>I don't think so. The fraction of a normalized, non-zero, finite
>>>>IEEE number has a value 0.5 <= f < 1, so unity is represented as
>>>>two to the first times one-half: 2^1 * .100...000(2). The
>>>>unbiased exponent value in the representation of unity is
>>>>therefore one, not zero.
>>>I think you forget the implicit bit Eric.
>>In some systems. Not necessarily C. Do try to stay on topic.
>>>

>The C standard assumes IEEE 754 representation Chuck.

>
It most certainly does not, and it never has.
>

In my copy of the standard there is a lengthy
Annex F (normative) IEC 60559 floating-point arithmetic

This annex specifies C language support for the IEC 60559 floating-point
standard. The
IEC 60559 floating-point standard is specifically Binary floating-point
arithmetic for
microprocessor systems, second edition (IEC 60559:1989), previously
designated
IEC 559:1989 and as IEEE Standard for Binary Floating-Point Arithmetic
(ANSI/IEEE 754−1985). IEEE Standard for Radix-Independent Floating-Point
Arithmetic (ANSI/IEEE 854−1987) generalizes the binary standard to remove
dependencies on radix and word length. IEC 60559 generally refers to the
floating-point
standard, as in IEC 60559 operation, IEC 60559 format, etc. An
implementation that
defines _ _STDC_IEC_559_ _ shall conform to the specifications in this
annex. Where
a binding between the C language and IEC 60559 is indicated, the IEC
60559-specified
behavior is adopted by reference, unless stated otherwise.

So, obviously in some systems no standard floating
point will be used, but that should be extremely rare.

[Army1987]

Re: The machine epsilon


"jacob navia" <jacob@jacob.re mcomp.frha scritto nel messaggio news:46855c82$0 $27407$ba4acef3 @news.orange.fr ...

Keith Thompson wrote:

>jacob navia <jacob@jacob.re mcomp.frwrites:

>>CBFalconer wrote:
>>>jacob navia wrote:
>>>>Eric Sosman wrote:
>>>... snip ...
>>>>>I don't think so. The fraction of a normalized, non-zero, finite
>>>>>IEEE number has a value 0.5 <= f < 1, so unity is represented as
>>>>>two to the first times one-half: 2^1 * .100...000(2). The
>>>>>unbiased exponent value in the representation of unity is
>>>>>therefor e one, not zero.
>>>>I think you forget the implicit bit Eric.
>>>In some systems. Not necessarily C. Do try to stay on topic.
>>>>
>>The C standard assumes IEEE 754 representation Chuck.

>>
>It most certainly does not, and it never has.
>>

>
In my copy of the standard there is a lengthy
Annex F (normative) IEC 60559 floating-point arithmetic
>
This annex specifies C language support for the IEC 60559 floating-point standard. The
IEC 60559 floating-point standard is specifically Binary floating-point arithmetic for
microprocessor systems, second edition (IEC 60559:1989), previously designated
IEC 559:1989 and as IEEE Standard for Binary Floating-Point Arithmetic
(ANSI/IEEE 754?1985). IEEE Standard for Radix-Independent Floating-Point
Arithmetic (ANSI/IEEE 854?1987) generalizes the binary standard to remove
dependencies on radix and word length. IEC 60559 generally refers to the floating-point
standard, as in IEC 60559 operation, IEC 60559 format, etc. An implementation that
defines _ _STDC_IEC_559_ _ shall conform to the specifications in this annex. Where
a binding between the C language and IEC 60559 is indicated, the IEC 60559-specified
behavior is adopted by reference, unless stated otherwise.
>
So, obviously in some systems no standard floating
point will be used, but that should be extremely rare.

Read the first words of the last sentence you copynpasted.
The standard explicitly allows FLT_RADIX to be even a power of 10.
Read 5.2.4.2.2 throughout.

[Walter Roberson]

Re: The machine epsilon

In article <468574bc$0$274 14$ba4acef3@new s.orange.fr>,
jacob navia <jacob@jacob.re mcomp.frwrote:

>Eric Sosman wrote:

> For IEEE double, there are about four and a half
>thousand million million distinct values strictly less
>than DBL_EPSILON which when added to 1 will produce the
>sum 1+DBL_EPSILON in "round to nearest" mode, which is
>the mode in effect when a C program starts.

>Great Eric, unnormalized numbers exist.

>What's your point?

Eric isn't talking about unnormalized numbers.

Consider DBL_EPSILON . It is noticably less than 1/2 so in IEEE
754 format, it will be normalized as some negative exponent
followed by a hidden 1 followed by some 53 bit binary fraction.
Take that 53 bit binary fraction as an integer and subtract 1 from
it, and construct a double with the same exponent as DBL_EPSILON
but the reduced fraction. Call the result, say, NEARLY_DBL_EPSI LON .
Now, take 1 + NEARLY_DBL_EPSI LON . What is the result?
Algebraicly, it isn't quite 1 + DBL_EPSILON, but floating point
arithmetic doesn't obey normal algebra, so the result depends upon
the IEEE rounding mode in effect. If "round to nearest" (or
perhaps some other modes) is in effect, the result is close enough to
1 + DBL_EPSILON that the processor will round the result to
1 + DBL_EPSILON . C only promises accuracy to at best 1 ULP
("Unit in the Last Place"), so this isn't "wrong" (and what
exactly is right or wrong in such a case is arguable.)
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

[Mark McIntyre]

Re: The machine epsilon

On Fri, 29 Jun 2007 10:40:58 +0000, in comp.lang.c , Richard
Heathfield <rjh@see.sig.in validwrote:

>Richard Tobin said:
>
><snip>
>

>You're not being reasonable.

>
>Shurely shome mishtake?

On your part, yes.

>He's writing a C tutorial

>
>The internal evidence of his articles suggests otherwise.

And now you're being gratuitous too. Give Jacob his due - he's trying
to write a C tutorial, he's very sensibly asking for a review here,
and is prepared to take in comments even from people who he has had
run-ins with before. Stop being so childish.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Re: The machine epsilon

jacob navia <jacob@jacob.re mcomp.frwrites:

Keith Thompson wrote:

>jacob navia <jacob@jacob.re mcomp.frwrites:

[...]

>>The C standard assumes IEEE 754 representation Chuck.

>It most certainly does not, and it never has.

>
In my copy of the standard there is a lengthy
Annex F (normative) IEC 60559 floating-point arithmetic
>
This annex specifies C language support for the IEC 60559
floating-point standard. The IEC 60559 floating-point standard is
specifically Binary floating-point arithmetic for microprocessor
systems, second edition (IEC 60559:1989), previously designated IEC
559:1989 and as IEEE Standard for Binary Floating-Point Arithmetic
(ANSI/IEEE 754−1985). IEEE Standard for Radix-Independent
Floating-Point Arithmetic (ANSI/IEEE 854−1987) generalizes the
binary standard to remove dependencies on radix and word length. IEC
60559 generally refers to the floating-point standard, as in IEC
60559 operation, IEC 60559 format, etc. An implementation that
defines _ _STDC_IEC_559_ _ shall conform to the specifications in
this annex. Where a binding between the C language and IEC 60559 is
indicated, the IEC 60559-specified behavior is adopted by reference,
unless stated otherwise.

Right. The relevant sentence is:

An implementation that defines __STDC_IEC_559_ _ shall conform to
the specifications in this annex.

See also C99 6.18.8p2, "Predefined macro names":

The following macro names are conditionally defined by the
implementation:

__STDC_IEC_559_ _ The integer constant 1, intended to indicate
conformance to the specifications in annex F (IEC 60559
floating-point arithmetic).

[...]

An implementation is not required to conform to annex F. It's merely
required to do so *if* it defines __STDC_IEC_559_ _.

So, obviously in some systems no standard floating
point will be used, but that should be extremely rare.

Why should they be rare? Most new systems these days do implement
IEEE floating-point, or at least use the formats, but there are still
systems that don't (VAX, some older Crays, IBM mainframes). Annex F
merely provides a framework for implementations that do support IEEE
FP, but it's explicitly optional.

I can also imagine an implementation that uses the IEEE floating-point
formats, but doesn't meet the requirements of Annex F; such an
implementation could not legally define __STDC_IEC_559_ _. (I have no
idea whether such implementations exist, or how common they are.)

And of course the __STDC_IEC_559_ _ and annex F are new in C99, so they
don't apply to the majority of implementations that don't conform to
the C99 standard.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: The machine epsilon

Here's *my* floating-point tutorial:

Read "What every computer scientist should know about floating-point
arithmetic", by David Goldberg.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Re: The machine epsilon

Army1987 wrote:

>I forgot about the rounding issue completely. The good "test" would be
>DBL_EPSILON* 1/4

>
NO! The rounding mode needn't be to nearest!
>

According to the C standard:
(Annex F.7.3)

At program startup the floating-point environment is initialized as
prescribed by IEC 60559:
— All floating-point exception status flags are cleared.

— The rounding direction mode is rounding to nearest. (!!!!!)

— The dynamic rounding precision mode (if supported) is set so that
results are not shortened.

[Harald van =?UTF-8?B?RMSzaw==?=]

Re: The machine epsilon

jacob navia wrote:

Army1987 wrote:

>>I forgot about the rounding issue completely. The good "test" would be
>>DBL_EPSILON *1/4

>>
>NO! The rounding mode needn't be to nearest!
>>

>
>
According to the C standard:
(Annex F.7.3)
>
At program startup the floating-point environment is initialized as
prescribed by IEC 60559:
— All floating-point exception status flags are cleared.
>
— The rounding direction mode is rounding to nearest. (!!!!!)
>
— The dynamic rounding precision mode (if supported) is set so that
results are not shortened.

As has been pointed out to you, annex F does not apply unless
__STDC_IEC_559_ _ is defined by the implementation.

[JT]

Re: The machine epsilon

Army1987 wrote:

NO! The rounding mode needn't be to nearest!

jacob navia <j...@jacob.rem comp.frwrote:

According to the C standard:
(Annex F.7.3)
>
At program startup the floating-point environment
is initialized as prescribed by IEC 60559:
- All floating-point exception status flags are cleared.
- The rounding direction mode is rounding to nearest. (!!!!!)

To Jacob: Eric Sosman already SAID THAT on June 29
that "rounding to nearest" is the start-up default.
But the program can change the default after start up.

So the FLAWED PARAPHRASE you keep insisting is not
a universal fact. You should use the OFFICIAL DEFINITION
of epsilon, rather than the FLAWED paraphrase
you KEEP insisting.


On Jun 29, 7:46 pm, Eric Sosman wrote:

Wrong again, Jacob. Twice.
First...
Second...
there are about four and a half
thousand million million distinct values
strictly less than DBL_EPSILON which
when added to 1 will produce the
sum 1+DBL_EPSILON in "round to nearest" mode,
which is the mode in effect when a C program starts.

^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^