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

Groups > comp.lang.c++ > #121740 > unrolled thread

There is no "correct" result for std::fmod across all IEEE 754 representations

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

Contents

  There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-01 19:27 +0000
    Re: There is no "correct" result for std::fmod across all IEEE 754 representations Michael S <already5chosen@yahoo.com> - 2025-03-01 23:03 +0200
      Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-01 21:57 +0000
        Re: There is no "correct" result for std::fmod across all IEEE 754 representations Michael S <already5chosen@yahoo.com> - 2025-03-02 11:07 +0200
          Re: There is no "correct" result for std::fmod across all IEEE 754 Muttley@DastardlyHQ.org - 2025-03-02 09:17 +0000
            Re: There is no "correct" result for std::fmod across all IEEE 754 Michael S <already5chosen@yahoo.com> - 2025-03-02 16:03 +0200
              Re: There is no "correct" result for std::fmod across all IEEE 754 Muttley@dastardlyhq.com - 2025-03-02 16:56 +0000
          Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-02 15:24 +0000
          Re: There is no "correct" result for std::fmod across all IEEE 754 representations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-02 17:37 -0500
            Re: There is no "correct" result for std::fmod across all IEEE 754 representations Michael S <already5chosen@yahoo.com> - 2025-03-03 13:20 +0200
    Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 16:25 +0100
      Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 16:30 +0100
        Re: There is no "correct" result for std::fmod across all IEEE 754 representations Michael S <already5chosen@yahoo.com> - 2025-03-03 18:54 +0200
      Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 17:11 +0000
        Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 18:26 +0100
          Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 18:20 +0000
            Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 19:26 +0100
              Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 18:33 +0000
                Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 19:37 +0100
                  Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 18:46 +0000
                    Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 19:48 +0100
                      Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 18:50 +0000
                        Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 19:53 +0100
                          Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 18:58 +0000
                            Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 20:05 +0100
                              Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 19:09 +0000
                                Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 20:14 +0100
                                  Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 20:27 +0100
                                  Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 19:33 +0000
                                    Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 20:36 +0100
                                      Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-03 19:37 +0000
                                        Re: There is no "correct" result for std::fmod across all IEEE 754 representations Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-04 10:42 +0100
                                          Re: There is no "correct" result for std::fmod across all IEEE 754 representations Mr Flibble <leigh@i42.co.uk> - 2025-03-04 18:24 +0000
                            Re: There is no "correct" result for std::fmod across all IEEE 754 representations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-03 12:25 -0800

Page 1 of 2  [1] 2  Next page →

#121740 — There is no "correct" result for std::fmod across all IEEE 754 representations

Hi!

There is no "correct" result for std::fmod across all IEEE 754
representations.

Why?

#include <cmath>
#include <iostream>
 
int main()
{
    std::cout << "Result of std::fmod(1.0e42, 1000.0): " <<
std::fmod(1.0e42, 1000.0);
}

Result of std::fmod(1.0e42, 1000.0): 312

The correct answer mathematically is 0 not 312 but as IEEE 754 has a
fixed width mantissa, x is inprecise so there is no correct "precise"
result for std::fmod(x, y) for all x & y as Bonita Montero claims
rendering her test case utter bollocks.

Given these FACTS please present actual problems with:

double my_fmod(double x, double y) 
{
    if (y == 0.0)
	return x / y;
    return x - std::trunc(x / y) * y;
}

/Flibble

[toc] | [next] | [standalone]

#121746

On Sat, 01 Mar 2025 19:27:46 +0000
Mr Flibble <leigh@i42.co.uk> wrote:

> Hi!
> 
> There is no "correct" result for std::fmod across all IEEE 754
> representations.
> 
> Why?
> 
> #include <cmath>
> #include <iostream>
>  
> int main()
> {
>     std::cout << "Result of std::fmod(1.0e42, 1000.0): " <<
> std::fmod(1.0e42, 1000.0);
> }
> 
> Result of std::fmod(1.0e42, 1000.0): 312
> 
> The correct answer mathematically is 0 not 312 but as IEEE 754 has a
> fixed width mantissa, x is inprecise so there is no correct "precise"
> result for std::fmod(x, y) for all x & y as Bonita Montero claims
> rendering her test case utter bollocks.
> 
> Given these FACTS please present actual problems with:
> 
> double my_fmod(double x, double y) 
> {
>     if (y == 0.0)
> 	return x / y;
>     return x - std::trunc(x / y) * y;
> }
> 
> /Flibble


For x that is a closest IEEE-754 binary64 approximation of 1e42, i.e.
for 0x1.6f578c4e0a061p+139, 312 is an exact answer.

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

#121749

On Sat, 1 Mar 2025 23:03:20 +0200, Michael S
<already5chosen@yahoo.com> wrote:

>On Sat, 01 Mar 2025 19:27:46 +0000
>Mr Flibble <leigh@i42.co.uk> wrote:
>
>> Hi!
>> 
>> There is no "correct" result for std::fmod across all IEEE 754
>> representations.
>> 
>> Why?
>> 
>> #include <cmath>
>> #include <iostream>
>>  
>> int main()
>> {
>>     std::cout << "Result of std::fmod(1.0e42, 1000.0): " <<
>> std::fmod(1.0e42, 1000.0);
>> }
>> 
>> Result of std::fmod(1.0e42, 1000.0): 312
>> 
>> The correct answer mathematically is 0 not 312 but as IEEE 754 has a
>> fixed width mantissa, x is inprecise so there is no correct "precise"
>> result for std::fmod(x, y) for all x & y as Bonita Montero claims
>> rendering her test case utter bollocks.
>> 
>> Given these FACTS please present actual problems with:
>> 
>> double my_fmod(double x, double y) 
>> {
>>     if (y == 0.0)
>> 	return x / y;
>>     return x - std::trunc(x / y) * y;
>> }
>> 
>> /Flibble
>
>
>For x that is a closest IEEE-754 binary64 approximation of 1e42, i.e.
>for 0x1.6f578c4e0a061p+139, 312 is an exact answer.

The 312 doesn't come directly from the mantissa though, if it did it
would be 0 not 312.  My point is std::fmod is almost useless
MATHEMATICALLY unless the arguments don't involve approximation, but
with IEEE 754 floating point you get what you pay for.

/Flibble

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

#121751

On Sat, 01 Mar 2025 21:57:13 +0000
Mr Flibble <leigh@i42.co.uk> wrote:

> On Sat, 1 Mar 2025 23:03:20 +0200, Michael S
> <already5chosen@yahoo.com> wrote:
> 
> >On Sat, 01 Mar 2025 19:27:46 +0000
> >Mr Flibble <leigh@i42.co.uk> wrote:
> >  
> >> Hi!
> >> 
> >> There is no "correct" result for std::fmod across all IEEE 754
> >> representations.
> >> 
> >> Why?
> >> 
> >> #include <cmath>
> >> #include <iostream>
> >>  
> >> int main()
> >> {
> >>     std::cout << "Result of std::fmod(1.0e42, 1000.0): " <<
> >> std::fmod(1.0e42, 1000.0);
> >> }
> >> 
> >> Result of std::fmod(1.0e42, 1000.0): 312
> >> 
> >> The correct answer mathematically is 0 not 312 but as IEEE 754 has
> >> a fixed width mantissa, x is inprecise so there is no correct
> >> "precise" result for std::fmod(x, y) for all x & y as Bonita
> >> Montero claims rendering her test case utter bollocks.
> >> 
> >> Given these FACTS please present actual problems with:
> >> 
> >> double my_fmod(double x, double y) 
> >> {
> >>     if (y == 0.0)
> >> 	return x / y;
> >>     return x - std::trunc(x / y) * y;
> >> }
> >> 
> >> /Flibble  
> >
> >
> >For x that is a closest IEEE-754 binary64 approximation of 1e42, i.e.
> >for 0x1.6f578c4e0a061p+139, 312 is an exact answer.  
> 
> The 312 doesn't come directly from the mantissa though, if it did it
> would be 0 not 312. 

I don't quite understand what you mean by that. That it does not come
from *decimal* mantissa that you wrote in the source code?
But how could it? IEEE-754 binary64 is, well, binary.

Python:
>>> x=1e42
>>> x
1e+42
>>> int(x)
1000000000000000044885712678075916785549312


> My point is std::fmod is almost useless
> MATHEMATICALLY unless the arguments don't involve approximation, but
> with IEEE 754 floating point you get what you pay for.
> 
> /Flibble

If you were saying that fmod(x/y) for big values of x/y is almost
useless physically / engineerially then I'd tend to agree.
When physicist or engineer says 'double x= bar;' where bar is a number
that can be represented exactly in binary64 then what he means (if he
cared at all to think about what he means, which is rare) is that he
believes that x is in range (bar-ULP:bar+ULP] and he hopes that
probability of x being within range [bar-ULP/2:bar+ULP/2] is much
higher that 0.5. So, obviously, as long as y is abs(y)<ULP(x) for
physicist fmod(x/y) is meaningless.

But the question of what is meaningful mathematically is different. The
answer depends on branch of mathematics we are interested in. Mostly I
tend to agree with you that it should depend on whether the argument
involves approximation or not. However, I know that I can not predict
what mathematician that specializes, for example, in numeric theory
could find meaningful or just interesting.

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

#121752 — Re: There is no "correct" result for std::fmod across all IEEE 754

On Sun, 2 Mar 2025 11:07:10 +0200
Michael S <already5chosen@yahoo.com> wibbled:
>On Sat, 01 Mar 2025 21:57:13 +0000
>Mr Flibble <leigh@i42.co.uk> wrote:
>> My point is std::fmod is almost useless
>> MATHEMATICALLY unless the arguments don't involve approximation, but
>> with IEEE 754 floating point you get what you pay for.
>> 
>> /Flibble
>
>If you were saying that fmod(x/y) for big values of x/y is almost
>useless physically / engineerially then I'd tend to agree.
>When physicist or engineer says 'double x= bar;' where bar is a number
>that can be represented exactly in binary64 then what he means (if he
>cared at all to think about what he means, which is rare) is that he
>believes that x is in range (bar-ULP:bar+ULP] and he hopes that
>probability of x being within range [bar-ULP/2:bar+ULP/2] is much
>higher that 0.5. So, obviously, as long as y is abs(y)<ULP(x) for
>physicist fmod(x/y) is meaningless.

The whole argument is somewhat moot anyway - for serious physics or engineering
calculations you simply don't use IEE754. These sort of applications either 
require everything to be done in integer (see also Fintec) or to use a number 
library such as GMP where the precision is only limited by memory and the
speed you require.

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

#121754 — Re: There is no "correct" result for std::fmod across all IEEE 754

On Sun, 2 Mar 2025 09:17:54 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

> On Sun, 2 Mar 2025 11:07:10 +0200
> Michael S <already5chosen@yahoo.com> wibbled:
> >On Sat, 01 Mar 2025 21:57:13 +0000
> >Mr Flibble <leigh@i42.co.uk> wrote:  
> >> My point is std::fmod is almost useless
> >> MATHEMATICALLY unless the arguments don't involve approximation,
> >> but with IEEE 754 floating point you get what you pay for.
> >> 
> >> /Flibble  
> >
> >If you were saying that fmod(x/y) for big values of x/y is almost
> >useless physically / engineerially then I'd tend to agree.
> >When physicist or engineer says 'double x= bar;' where bar is a
> >number that can be represented exactly in binary64 then what he
> >means (if he cared at all to think about what he means, which is
> >rare) is that he believes that x is in range (bar-ULP:bar+ULP] and
> >he hopes that probability of x being within range
> >[bar-ULP/2:bar+ULP/2] is much higher that 0.5. So, obviously, as
> >long as y is abs(y)<ULP(x) for physicist fmod(x/y) is meaningless.  
> 
> The whole argument is somewhat moot anyway - for serious physics or
> engineering calculations you simply don't use IEE754. These sort of
> applications either require everything to be done in integer (see
> also Fintec) or to use a number library such as GMP where the
> precision is only limited by memory and the speed you require.
> 

That's wrong.
Overwhelming majority of worlds scientific and engineering calculations
is performed with IEEE-754 binary64.
You can call all this people non-serious.
Me, personally, I don't think that Fintech people are not serious, but
at the same time I think that most of them are crooks.

In other field, like signal processing and graphics, the default is
IEEE-754 binary32.
In the modern turn of AI they use even lower precision, like IEEE-754
binary16 and so-called bfloat. And the trend (DeepSeek) is further down
in precision.

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

#121765 — Re: There is no "correct" result for std::fmod across all IEEE 754

On Sun, 2 Mar 2025 16:03:30 +0200
Michael S <already5chosen@yahoo.com> gabbled:
>On Sun, 2 Mar 2025 09:17:54 -0000 (UTC)
>Muttley@DastardlyHQ.org wrote:
>> The whole argument is somewhat moot anyway - for serious physics or
>> engineering calculations you simply don't use IEE754. These sort of
>> applications either require everything to be done in integer (see
>> also Fintec) or to use a number library such as GMP where the
>> precision is only limited by memory and the speed you require.
>> 
>
>That's wrong.
>Overwhelming majority of worlds scientific and engineering calculations
>is performed with IEEE-754 binary64.

I guess it depends how you define scientific and engineering. For cars sure,
who cares if the lane keep wanders by a few cm, deep space probes otoh could
end up millions of miles off course if there's some rounding error.

>You can call all this people non-serious.
>Me, personally, I don't think that Fintech people are not serious, but
>at the same time I think that most of them are crooks.

Feel free to close your bank accounts and keep bundles of cash under your 
mattress.

>In other field, like signal processing and graphics, the default is
>IEEE-754 binary32.

Why would graphics need very accurate precision? Quite the opposite especially 
if you want a good frame rate. No one cares if Lara Crofts hair is a few pixels
out of place. Signal processing would depend on what its used for.

>In the modern turn of AI they use even lower precision, like IEEE-754
>binary16 and so-called bfloat. And the trend (DeepSeek) is further down
>in precision.

Given the signal to noise ratio in AI input data it would probably make
little difference if they just used integer arithmetic frankly.

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

#121759

On Sun, 2 Mar 2025 11:07:10 +0200, Michael S
<already5chosen@yahoo.com> wrote:

>On Sat, 01 Mar 2025 21:57:13 +0000
>Mr Flibble <leigh@i42.co.uk> wrote:
>
>> On Sat, 1 Mar 2025 23:03:20 +0200, Michael S
>> <already5chosen@yahoo.com> wrote:
>> 
>> >On Sat, 01 Mar 2025 19:27:46 +0000
>> >Mr Flibble <leigh@i42.co.uk> wrote:
>> >  
>> >> Hi!
>> >> 
>> >> There is no "correct" result for std::fmod across all IEEE 754
>> >> representations.
>> >> 
>> >> Why?
>> >> 
>> >> #include <cmath>
>> >> #include <iostream>
>> >>  
>> >> int main()
>> >> {
>> >>     std::cout << "Result of std::fmod(1.0e42, 1000.0): " <<
>> >> std::fmod(1.0e42, 1000.0);
>> >> }
>> >> 
>> >> Result of std::fmod(1.0e42, 1000.0): 312
>> >> 
>> >> The correct answer mathematically is 0 not 312 but as IEEE 754 has
>> >> a fixed width mantissa, x is inprecise so there is no correct
>> >> "precise" result for std::fmod(x, y) for all x & y as Bonita
>> >> Montero claims rendering her test case utter bollocks.
>> >> 
>> >> Given these FACTS please present actual problems with:
>> >> 
>> >> double my_fmod(double x, double y) 
>> >> {
>> >>     if (y == 0.0)
>> >> 	return x / y;
>> >>     return x - std::trunc(x / y) * y;
>> >> }
>> >> 
>> >> /Flibble  
>> >
>> >
>> >For x that is a closest IEEE-754 binary64 approximation of 1e42, i.e.
>> >for 0x1.6f578c4e0a061p+139, 312 is an exact answer.  
>> 
>> The 312 doesn't come directly from the mantissa though, if it did it
>> would be 0 not 312. 
>
>I don't quite understand what you mean by that. That it does not come
>from *decimal* mantissa that you wrote in the source code?
>But how could it? IEEE-754 binary64 is, well, binary.

No, I mean does not come from the *binary* mantissa: the mantissa is
*effectively* bit shifted according to the value of the exponent
storing zeros in the exposed bits and it is these exposed zero bits
that contribute to the approximation I was referring to.

/Flibble

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

#121789

On 3/2/25 04:07, Michael S wrote:
> On Sat, 01 Mar 2025 21:57:13 +0000
> Mr Flibble <leigh@i42.co.uk> wrote:
...
>> My point is std::fmod is almost useless
>> MATHEMATICALLY unless the arguments don't involve approximation, but
>> with IEEE 754 floating point you get what you pay for.
>>
>> /Flibble
>
> If you were saying that fmod(x/y) for big values of x/y is almost

fmod(x,y)?

> useless physically / engineerially then I'd tend to agree.
> When physicist or engineer says 'double x= bar;' where bar is a number
> that can be represented exactly in binary64 then what he means (if he
> cared at all to think about what he means, which is rare) is that he
> believes that x is in range (bar-ULP:bar+ULP] and he hopes that
> probability of x being within range [bar-ULP/2:bar+ULP/2] is much
> higher that 0.5. So, obviously, as long as y is abs(y)<ULP(x) for
> physicist fmod(x/y) is meaningless.

Actually, most numbers of relevance to science and engineering have a
uncertainty which is determined by how the raw measurements were made
from which the number was calculated, which are usually much bigger than
1 ULP. The only exceptions are mathematical constants. Despite that
fact, it is in fact quite commonplace for the uncertainties to be small
enough to make the return value of fmod() meaningful. As a general rule,
if that weren't the case, there wouldn't be any desire to use fmod().

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

#121798

On Sun, 2 Mar 2025 17:37:48 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 3/2/25 04:07, Michael S wrote:
> > On Sat, 01 Mar 2025 21:57:13 +0000
> > Mr Flibble <leigh@i42.co.uk> wrote:  
> ...
> >> My point is std::fmod is almost useless
> >> MATHEMATICALLY unless the arguments don't involve approximation,
> >> but with IEEE 754 floating point you get what you pay for.
> >>
> >> /Flibble  
> >
> > If you were saying that fmod(x/y) for big values of x/y is almost  
> 
> fmod(x,y)?

Yes, sorry.

> 
> > useless physically / engineerially then I'd tend to agree.
> > When physicist or engineer says 'double x= bar;' where bar is a
> > number that can be represented exactly in binary64 then what he
> > means (if he cared at all to think about what he means, which is
> > rare) is that he believes that x is in range (bar-ULP:bar+ULP] and
> > he hopes that probability of x being within range
> > [bar-ULP/2:bar+ULP/2] is much higher that 0.5. So, obviously, as
> > long as y is abs(y)<ULP(x) for physicist fmod(x/y) is meaningless.  
> 
> Actually, most numbers of relevance to science and engineering have a
> uncertainty which is determined by how the raw measurements were made
> from which the number was calculated, which are usually much bigger
> than 1 ULP. The only exceptions are mathematical constants. Despite
> that fact, it is in fact quite commonplace for the uncertainties to
> be small enough to make the return value of fmod() meaningful. As a
> general rule, if that weren't the case, there wouldn't be any desire
> to use fmod().
> 

My point was that for physicist fmod(x,y) is meaningless as long as
abs(y)<ULP(x).
I never said that when abs(y)>ULP(x) then fmod(x,y) is always
meaningful, just that it is a necessary condition.

Bonita's test suit consists of 50% of trivial cases (abs(y) > abs(x)),
47.7 % of meaningless cases, and only 2.3% of the cases are
potentially meaningful.

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

#121805

Am 01.03.2025 um 20:27 schrieb Mr Flibble:

> The correct answer mathematically is 0 not 312 but as IEEE 754 has a
> fixed width mantissa, x is inprecise so there is no correct "precise"
> result for std::fmod(x, y) for all x & y as Bonita Montero claims
> rendering her test case utter bollocks.

fmod() is always exact because the calculations are the same as for
written division and the remainder in written division always has the
same or fewer digits than the divisor.
You fell into the trap when calculating the conversion between decimal
numbers and binary numbers, which is usually not exact for floating-
point values.

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

#121806

Am 03.03.2025 um 16:25 schrieb Bonita Montero:

>> The correct answer mathematically is 0 not 312 but as IEEE 754 has a
>> fixed width mantissa, x is inprecise so there is no correct "precise"
>> result for std::fmod(x, y) for all x & y as Bonita Montero claims
>> rendering her test case utter bollocks.

If you print 1e42 with cout and enough setprecision() digits you get:

	1.00000000000000004488571267808e+42

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

#121815

On Mon, 3 Mar 2025 16:30:26 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 03.03.2025 um 16:25 schrieb Bonita Montero:
> 
> >> The correct answer mathematically is 0 not 312 but as IEEE 754 has
> >> a fixed width mantissa, x is inprecise so there is no correct
> >> "precise" result for std::fmod(x, y) for all x & y as Bonita
> >> Montero claims rendering her test case utter bollocks.  
> 
> If you print 1e42 with cout and enough setprecision() digits you get:
> 
> 	1.00000000000000004488571267808e+42
> 
> 

Which is still not enlightening. The full answer is
1000000000000000044885712678075916785549312
Or, if you want
1.000000000000000044885712678075916785549312e42

Which, of course, is very easy to see if you use working formatting
library instead of misdesigned C++ crap.
  printf("%.42e\n", 1e42);

Both 5 times less code and 5 times better result.

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

#121817

On Mon, 3 Mar 2025 16:25:31 +0100, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 01.03.2025 um 20:27 schrieb Mr Flibble:
>
>> The correct answer mathematically is 0 not 312 but as IEEE 754 has a
>> fixed width mantissa, x is inprecise so there is no correct "precise"
>> result for std::fmod(x, y) for all x & y as Bonita Montero claims
>> rendering her test case utter bollocks.
>
>fmod() is always exact because the calculations are the same as for
>written division and the remainder in written division always has the
>same or fewer digits than the divisor.
>You fell into the trap when calculating the conversion between decimal
>numbers and binary numbers, which is usually not exact for floating-
>point values.

Not at all. It has nothing to do with conversion between decimal and
binary; it has everything to do with a fixed width mantissa which when
shifted based on an exponent becomes an approximation.

/Flibble

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

#121822

Am 03.03.2025 um 18:11 schrieb Mr Flibble:

> Not at all. It has nothing to do with conversion between decimal and
> binary; it has everything to do with a fixed width mantissa which when
> shifted based on an exponent becomes an approximation.

fmod() is always 100% precise since there are no intermediate results
with precision loss. Michael understands that, you don't. You're really
a n00b.

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

#121829

On Mon, 3 Mar 2025 18:26:21 +0100, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 03.03.2025 um 18:11 schrieb Mr Flibble:
>
>> Not at all. It has nothing to do with conversion between decimal and
>> binary; it has everything to do with a fixed width mantissa which when
>> shifted based on an exponent becomes an approximation.
>
>fmod() is always 100% precise since there are no intermediate results
>with precision loss. Michael understands that, you don't. You're really
>a n00b.

No, dear, I am not a n00b but you ARE unable to follow a technical
discussion. Is English not your first language?

/Flibble

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

#121830

Am 03.03.2025 um 19:20 schrieb Mr Flibble:
> On Mon, 3 Mar 2025 18:26:21 +0100, Bonita Montero
> <Bonita.Montero@gmail.com> wrote:
> 
>> Am 03.03.2025 um 18:11 schrieb Mr Flibble:
>>
>>> Not at all. It has nothing to do with conversion between decimal and
>>> binary; it has everything to do with a fixed width mantissa which when
>>> shifted based on an exponent becomes an approximation.
>>
>> fmod() is always 100% precise since there are no intermediate results
>> with precision loss. Michael understands that, you don't. You're really
>> a n00b.
> 
> No, dear, I am not a n00b but you ARE unable to follow a technical
> discussion. Is English not your first language?

You're a n00b because you dont't understand why fmod() is exact
for finite numbers. I've given the source so this could help you
to understand that.

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

#121832

On Mon, 3 Mar 2025 19:26:25 +0100, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 03.03.2025 um 19:20 schrieb Mr Flibble:
>> On Mon, 3 Mar 2025 18:26:21 +0100, Bonita Montero
>> <Bonita.Montero@gmail.com> wrote:
>> 
>>> Am 03.03.2025 um 18:11 schrieb Mr Flibble:
>>>
>>>> Not at all. It has nothing to do with conversion between decimal and
>>>> binary; it has everything to do with a fixed width mantissa which when
>>>> shifted based on an exponent becomes an approximation.
>>>
>>> fmod() is always 100% precise since there are no intermediate results
>>> with precision loss. Michael understands that, you don't. You're really
>>> a n00b.
>> 
>> No, dear, I am not a n00b but you ARE unable to follow a technical
>> discussion. Is English not your first language?
>
>You're a n00b because you dont't understand why fmod() is exact
>for finite numbers. I've given the source so this could help you
>to understand that.

Thanks for confirming that you are unable to follow a technical
discussion, n00b.

/Flibble

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

#121834

Am 03.03.2025 um 19:33 schrieb Mr Flibble:
> On Mon, 3 Mar 2025 19:26:25 +0100, Bonita Montero
> <Bonita.Montero@gmail.com> wrote:
> 
>> Am 03.03.2025 um 19:20 schrieb Mr Flibble:
>>> On Mon, 3 Mar 2025 18:26:21 +0100, Bonita Montero
>>> <Bonita.Montero@gmail.com> wrote:
>>>
>>>> Am 03.03.2025 um 18:11 schrieb Mr Flibble:
>>>>
>>>>> Not at all. It has nothing to do with conversion between decimal and
>>>>> binary; it has everything to do with a fixed width mantissa which when
>>>>> shifted based on an exponent becomes an approximation.
>>>>
>>>> fmod() is always 100% precise since there are no intermediate results
>>>> with precision loss. Michael understands that, you don't. You're really
>>>> a n00b.
>>>
>>> No, dear, I am not a n00b but you ARE unable to follow a technical
>>> discussion. Is English not your first language?
>>
>> You're a n00b because you dont't understand why fmod() is exact
>> for finite numbers. I've given the source so this could help you
>> to understand that.
> 
> Thanks for confirming that you are unable to follow a technical
> discussion, n00b.

If you were able to to that you would have inspected my code and you
would have come to the conclusion that there is no precision loss for
finite numbers. That's while the process is like a written division
where each intermediate result is smaller than the divisor; so that
there couldn't be any precision loss.
Your solution was silly.

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

#121835

On Mon, 3 Mar 2025 19:37:54 +0100, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 03.03.2025 um 19:33 schrieb Mr Flibble:
>> On Mon, 3 Mar 2025 19:26:25 +0100, Bonita Montero
>> <Bonita.Montero@gmail.com> wrote:
>> 
>>> Am 03.03.2025 um 19:20 schrieb Mr Flibble:
>>>> On Mon, 3 Mar 2025 18:26:21 +0100, Bonita Montero
>>>> <Bonita.Montero@gmail.com> wrote:
>>>>
>>>>> Am 03.03.2025 um 18:11 schrieb Mr Flibble:
>>>>>
>>>>>> Not at all. It has nothing to do with conversion between decimal and
>>>>>> binary; it has everything to do with a fixed width mantissa which when
>>>>>> shifted based on an exponent becomes an approximation.
>>>>>
>>>>> fmod() is always 100% precise since there are no intermediate results
>>>>> with precision loss. Michael understands that, you don't. You're really
>>>>> a n00b.
>>>>
>>>> No, dear, I am not a n00b but you ARE unable to follow a technical
>>>> discussion. Is English not your first language?
>>>
>>> You're a n00b because you dont't understand why fmod() is exact
>>> for finite numbers. I've given the source so this could help you
>>> to understand that.
>> 
>> Thanks for confirming that you are unable to follow a technical
>> discussion, n00b.
>
>If you were able to to that you would have inspected my code and you
>would have come to the conclusion that there is no precision loss for
>finite numbers. That's while the process is like a written division
>where each intermediate result is smaller than the divisor; so that
>there couldn't be any precision loss.
>Your solution was silly.

The problem is that you cannot follow a technical discussion on
Usenet: if you read further up this thread at my discussion with
Michael S you will see that I am not talking about precision loss
within fmod but with the arguments passed to fmod; you will also see
the problems with your test code.

/Flibble

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web