I found the following paragraph

"Apart from the 𝑟𝑛𝑒 rounding mode, there are four other rounding modes in the IEEE-754 standard. When existing correctly rounded libraries are used to generate results with other rounding modes or with other precision configurations, it can produce wrong results due to double rounding. For
example, let us say we use a correctly rounded double precision library such as CR-LIBM with the 𝑟𝑛𝑒 rounding mode to produce results for a 32-bit float type with the same 𝑟𝑛𝑒 mode. Here, we round the result of CR-LIBM to a 32-bit float value to produce the final result. If the real value of 𝑓 (𝑥) is extremely close to the rounding boundary of two adjacent float values, then the error caused by rounding 𝑓 (𝑥) to double using the 𝑟𝑛𝑒 mode can be significant enough to produce the wrong result for a 32-bit float. We empirically show that this approach of using a correctly rounded math library for double precision produces wrong float results in Section 6."

in https://arxiv.org/pdf/2108.06756.pdf

A while back, some people on this NG told me that computing in double and then rounding to single did not produce double rounding errors. Something about 2n+3 fraction bits being sufficient.

Here is the evidence against that position.

MitchAlsup wrote:
> I found the following paragraph
>
> "Apart from the 𝑟𝑛𝑒 rounding mode, there are four other rounding modes in the IEEE-754 standard. When existing correctly rounded libraries are used to generate results with other rounding modes or with other precision configurations, it can produce wrong results due to double rounding. For
> example, let us say we use a correctly rounded double precision library such as CR-LIBM with the 𝑟𝑛𝑒 rounding mode to produce results for a 32-bit float type with the same 𝑟𝑛𝑒 mode. Here, we round the result of CR-LIBM to a 32-bit float value to produce the final result. If the real value of 𝑓 (𝑥) is extremely close to the rounding boundary of two adjacent float values, then the error caused by rounding 𝑓 (𝑥) to double using the 𝑟𝑛𝑒 mode can be significant enough to produce the wrong result for a 32-bit float. We empirically show that this approach of using a correctly rounded math library for double precision produces wrong float results in Section 6."
>
> in https://arxiv.org/pdf/2108.06756.pdf
>
> A while back, some people on this NG told me that computing in double and then rounding to single did not produce double rounding errors. Something about 2n+3 fraction bits being sufficient.
>
> Here is the evidence against that position.
>
Without reading the linked paper, I would guess that they cannot get
this "extremely close to the rounding boundary" result from a single
operation. If you do multiple ops, all in double, then you can indeed
get results that will be different after double rounding.

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

On Friday, October 8, 2021 at 10:34:31 PM UTC+3, MitchAlsup wrote:
> I found the following paragraph
>
> "Apart from the 𝑟𝑛𝑒 rounding mode, there are four other rounding modes in the IEEE-754 standard. When existing correctly rounded libraries are used to generate results with other rounding modes or with other precision configurations, it can produce wrong results due to double rounding. For
> example, let us say we use a correctly rounded double precision library such as CR-LIBM with the 𝑟𝑛𝑒 rounding mode to produce results for a 32-bit float type with the same 𝑟𝑛𝑒 mode. Here, we round the result of CR-LIBM to a 32-bit float value to produce the final result. If the real value of 𝑓 (𝑥) is extremely close to the rounding boundary of two adjacent float values, then the error caused by rounding 𝑓 (𝑥) to double using the 𝑟𝑛𝑒 mode can be significant enough to produce the wrong result for a 32-bit float. We empirically show that this approach of using a correctly rounded math library for double precision produces wrong float results in Section 6."
>
> in https://arxiv.org/pdf/2108.06756.pdf
>
> A while back, some people on this NG told me that computing in double and then rounding to single did not produce double rounding errors. Something about 2n+3 fraction bits being sufficient.
>
> Here is the evidence against that position.

They say that it can happen when you do calculation in binary64 under RNE and then round result to binary32 under non-RNE.
The claim in NG was about the case when final step is also done under RNE.

BTW, even original claim was made only +,-,*,/ and sqrt(). Nobody said that it is correct to any imaginable transcendental.
I think (didn't check) that correctness of the claim is proven by exhausting for all transcendental functions of single argument that are present in clib. But for arbitrary "smooth" transcendental functions it's just should be consider very likely until proven.

On Friday, 8 October 2021 at 21:34:31 UTC+2, MitchAlsup wrote:
> I found the following paragraph
>
> "Apart from the 𝑟𝑛𝑒 rounding mode, there are four other rounding modes in the IEEE-754 standard. When existing correctly rounded libraries are used to generate results with other rounding modes or with other precision configurations, it can produce wrong results due to double rounding.
>
> For
> example, let us say we use a correctly rounded double precision library such as CR-LIBM with the 𝑟𝑛𝑒 rounding mode to produce results for a 32-bit float type with the same 𝑟𝑛𝑒 mode. Here, we round the result of CR-LIBM to a 32-bit float value to produce the final result. If the real value of 𝑓 (𝑥) is extremely close to the rounding boundary of two adjacent float values, then the error caused by rounding 𝑓 (𝑥) to double using the 𝑟𝑛𝑒 mode can be significant enough to produce the wrong result for a 32-bit float. We empirically show that this approach of using a correctly rounded math library for double precision produces wrong float results in Section 6."
>
> in https://arxiv.org/pdf/2108.06756.pdf

That is completely a misunderstanding: rounding modes are set against the FPU, so just assuming default rounding is rather a naive mistake on the part of the developer.

There is *no such thing* as an a priori "correctly rounded library", and there are just no such problems as the authors here elucubrate.

HTH,

Julio

> A while back, some people on this NG told me that computing in double and then rounding to single did not produce double rounding errors. Something about 2n+3 fraction bits being sufficient.
>
> Here is the evidence against that position.

Michael S <already5chosen@yahoo.com> wrote:
> On Friday, October 8, 2021 at 10:34:31 PM UTC+3, MitchAlsup wrote:
> > I found the following paragraph
> >
> > "Apart from the ??? rounding mode, there are four other rounding modes in the IEEE-754 standard. When existing correctly rounded libraries are used to generate results with other rounding modes or with other precision configurations, it can produce wrong results due to double rounding. For
> > example, let us say we use a correctly rounded double precision library such as CR-LIBM with the ??? rounding mode to produce results for a 32-bit float type with the same ??? mode. Here, we round the result of CR-LIBM to a 32-bit float value to produce the final result. If the real value of ? (?) is extremely close to the rounding boundary of two adjacent float values, then the error caused by rounding ? (?) to double using the ??? mode can be significant enough to produce the wrong result for a 32-bit float. We empirically show that this approach of using a correctly rounded math library for double precision produces wrong float results in Section 6."
> >
> > in https://arxiv.org/pdf/2108.06756.pdf
> >
> > A while back, some people on this NG told me that computing in double and then rounding to single did not produce double rounding errors. Something about 2n+3 fraction bits being sufficient.
> >
> > Here is the evidence against that position.
>
> They say that it can happen when you do calculation in binary64 under RNE and then round result to binary32 under non-RNE.
> The claim in NG was about the case when final step is also done under RNE.
>
> BTW, even original claim was made only +,-,*,/ and sqrt(). Nobody said that it is correct to any imaginable transcendental.
> I think (didn't check) that correctness of the claim is proven by exhausting for all transcendental functions of single argument that are present in clib. But for arbitrary "smooth" transcendental functions it's just should be consider very likely until proven.

Original claim was about single arithemtic operation. It is not valid
for sequence of operations (I you want to emulate seqence of single
precision operations you need to insert rounding to single after
each step). Proof for arithmetic is easy: when arguments have
single precision in most cases result can be represented exactly
in double precision. Remaining cases are special enough
to handle by slightly different argment. Such reasoning breaks
down for transcendental functions and even sqrt. Of couse,
result could be valid due to more subtle reasons, but for
resonably general transcendental functions this is highly
unlikely. So I would say: very unlikely unless proven.

--
Waldek Hebisch

On Wednesday, October 13, 2021 at 4:10:24 PM UTC+3, anti...@math.uni.wroc.pl wrote:
> Michael S <already...@yahoo.com> wrote:
> > On Friday, October 8, 2021 at 10:34:31 PM UTC+3, MitchAlsup wrote:
> > > I found the following paragraph
> > >
> > > "Apart from the ??? rounding mode, there are four other rounding modes in the IEEE-754 standard. When existing correctly rounded libraries are used to generate results with other rounding modes or with other precision configurations, it can produce wrong results due to double rounding. For
> > > example, let us say we use a correctly rounded double precision library such as CR-LIBM with the ??? rounding mode to produce results for a 32-bit float type with the same ??? mode. Here, we round the result of CR-LIBM to a 32-bit float value to produce the final result. If the real value of ? (?) is extremely close to the rounding boundary of two adjacent float values, then the error caused by rounding ? (?) to double using the ??? mode can be significant enough to produce the wrong result for a 32-bit float. We empirically show that this approach of using a correctly rounded math library for double precision produces wrong float results in Section 6."
> > >
> > > in https://arxiv.org/pdf/2108.06756.pdf
> > >
> > > A while back, some people on this NG told me that computing in double and then rounding to single did not produce double rounding errors. Something about 2n+3 fraction bits being sufficient.
> > >
> > > Here is the evidence against that position.
> >
> > They say that it can happen when you do calculation in binary64 under RNE and then round result to binary32 under non-RNE.
> > The claim in NG was about the case when final step is also done under RNE.
> >
> > BTW, even original claim was made only +,-,*,/ and sqrt(). Nobody said that it is correct to any imaginable transcendental.
> > I think (didn't check) that correctness of the claim is proven by exhausting for all transcendental functions of single argument that are present in clib. But for arbitrary "smooth" transcendental functions it's just should be consider very likely until proven.
> Original claim was about single arithemtic operation. It is not valid
> for sequence of operations (I you want to emulate seqence of single
> precision operations you need to insert rounding to single after
> each step). Proof for arithmetic is easy: when arguments have
> single precision in most cases result can be represented exactly
> in double precision. Remaining cases are special enough
> to handle by slightly different argment. Such reasoning breaks
> down for transcendental functions and even sqrt. Of couse,
> result could be valid due to more subtle reasons, but for
> resonably general transcendental functions this is highly
> unlikely. So I would say: very unlikely unless proven.
>
> --
> Waldek Hebisch

Yes, for general case I miscalculated.
For general "smooth" transcendental function that takes input in the full binary32 range
and produces output in the same range it could be assumed that for any particular input value
a probability of double rounding mistake = 2**(24-53).
Strictly speaking, the formula applies only to results in "normal" binary32 range, for subnormal the formula is different,
but let's ignore subnormals for sake of brevity.
Using formula above we can estimate a probability that none of the possible binary32 inputs
will suffer from double rounding mistake as (1-2**(24-53))**(2**32) ~= exp(-8)=3.35e-4.
I other words, you are right.

Of course, as you said, for specific transcendental there can be reasons why probability differs.
For example, if the function is even or odd then the number of different inputs is twice smaller
and then probability of absence of mistake ~= exp(-4) = 1.83e-2. Still pretty small number.

Or, for example, for sin(x) we know that there are no mistakes as long as x*x/3 < ULP(x).
That cuts off almost half of possible inputs.
Etc...