Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #121694 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2025-02-24 11:48 +0100 |
| Last post | 2025-03-09 14:56 +0200 |
| Articles | 14 on this page of 134 — 8 participants |
Back to article view | Back to comp.lang.c++
a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-24 11:48 +0100
Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-24 12:00 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-24 13:48 +0100
Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-24 13:09 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-24 14:22 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-24 17:13 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-24 16:19 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-24 17:52 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 09:09 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 16:17 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-25 17:26 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 16:45 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 16:57 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-25 19:17 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 18:58 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-26 00:36 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-26 04:15 +0100
Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-26 08:16 +0000
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-26 14:27 +0200
Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-26 14:39 +0000
FP_CONTRACT was : a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-28 16:28 +0200
Re: FP_CONTRACT was : a MSVC and glibc-compatible fmod() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-01 08:35 -0800
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-24 16:22 +0200
Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-24 15:10 +0000
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-24 17:33 +0200
Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-24 16:48 +0000
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-24 22:21 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 07:37 +0100
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-25 23:03 +0000
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-26 02:00 +0200
Re: a MSVC and glibc-compatible fmod() Wuns Haerst <Wuns.Haerst@wurstfabrik.at> - 2025-02-26 04:01 +0100
Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-25 08:24 +0000
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-27 21:16 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-28 07:59 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-28 12:35 +0200
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-28 18:12 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-28 19:23 +0100
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-28 18:30 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-28 19:31 +0100
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-28 19:47 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-28 20:49 +0100
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-01 14:37 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-01 16:58 +0100
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-01 17:11 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-01 21:02 +0100
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-01 20:32 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-01 21:37 +0100
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-01 20:45 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 09:40 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-01 22:55 +0200
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 18:54 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 17:59 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 15:41 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 17:10 +0100
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-02 16:22 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 17:26 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 19:07 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 18:09 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 18:11 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 19:52 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 18:55 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 20:09 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 19:14 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 19:57 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 22:58 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 12:52 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 18:10 +0200
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 23:55 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-07 09:51 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 18:20 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 17:30 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 19:27 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 18:39 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 02:01 +0200
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 19:37 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 18:41 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 20:00 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 19:01 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 01:31 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 07:41 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 11:08 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 10:31 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 11:46 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 10:54 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 12:09 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 11:21 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 14:09 +0200
Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-09 15:26 +0000
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 17:02 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 19:55 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 19:10 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 19:27 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 17:23 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 20:04 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 19:11 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 20:11 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 07:24 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 10:46 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 14:26 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 13:45 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 16:33 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 15:46 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 16:59 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 16:11 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 17:43 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 17:13 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 19:51 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 19:00 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 20:38 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 22:34 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 22:36 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 12:47 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 23:52 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 23:57 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-11 09:34 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 12:29 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-11 12:12 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 13:34 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-11 13:10 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 14:55 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-11 14:08 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 15:46 +0200
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 13:51 +0200
Re: a MSVC and glibc-compatible fmod() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-11 14:21 -0400
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 20:28 +0200
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-16 13:48 +0200
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 13:17 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 12:53 +0100
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 12:54 +0100
Re: a MSVC and glibc-compatible fmod() wij <wyniijj5@gmail.com> - 2025-03-09 18:51 +0800
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 12:56 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 14:23 +0200
Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 13:39 +0100
Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 14:56 +0200
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-03-11 14:08 +0100 |
| Message-ID | <vqpcjk$1vvbf$1@raubtier-asyl.eternal-september.org> |
| In reply to | #121954 |
Am 11.03.2025 um 13:55 schrieb Michael S: > But not when library routine does not use FPU. Or uses FPU only for > comparison ops. Then the library routine shout use fesetexcept() as you do it yourself. > The point is, it does not sound right if SNAN is *silently* converted > to QNAN. That type of conversion has to be loud i.e. accompanied by > setting of FE_INVALID. Interestingly even conversion-operations from double to float do that. That's not what I epected. And there a some operations that should do that but actually keep the signalling bit zeroed like a sign-change since this is usually done with a XOR-operation.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-11 15:46 +0200 |
| Message-ID | <20250311154647.00005d55@yahoo.com> |
| In reply to | #121954 |
On Tue, 11 Mar 2025 14:55:43 +0200
Michael S <already5chosen@yahoo.com> wrote:
> On Tue, 11 Mar 2025 13:10:31 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
> > Am 11.03.2025 um 12:34 schrieb Michael S:
> >
> > > Exactly. Both options are legal. MS's decision to not set
> > > FE_INVALID is as good as glibc decision to set it.
> >
> > If I do a SSE-/AVX-operation where either operand is a signalling
> > NaN I get a FE_INVALID; since the FPU behaves this way the MSVC
> > runtime should do that also.
> >
> > > BTW, what is the output of MS library in that case? SNAN or QNAN?
> > >
> >
> > Results with SNaN parameters are always QNaN, that shoud be common
> > with any FPU.
> >
>
> But not when library routine does not use FPU. Or uses FPU only for
> comparison ops.
> The point is, it does not sound right if SNAN is *silently* converted
> to QNAN. That type of conversion has to be loud i.e. accompanied by
> setting of FE_INVALID.
>
>
I tested. It appears that MSVC implementation made a mistake in
cases of fmod(snan, qnan):
MSVC gcc
x y result FE_INVALID) result FE_INVALID
snan 1 snan 0 qnan 1
snan 0 snan 0 qnan 1
snan inf snan 0 qnan 1
snan qnan qnan 0 !!! qnan 1
1 snan snan 0 qnan 1
0 snan snan 0 qnan 1
inf snan snan 0 qnan 1
qnan snan snan 0 qnan 1
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-11 13:51 +0200 |
| Message-ID | <20250311135127.000058b8@yahoo.com> |
| In reply to | #121950 |
On Tue, 11 Mar 2025 12:12:31 +0100 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 11.03.2025 um 11:29 schrieb Michael S: > > > Pay attention that fmod() has no requirements w.r.t. to such > > exceptions as FE_INEXACT, FE_UNDERFLOW and non-standard > > FE_DENORMAL. > > Yes, that's while I evaluate FE_INVALID only. I think that testing that FE_DIVEDEBYZERO is not set is also a good idea.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-03-11 14:21 -0400 |
| Message-ID | <vqpuue$23p62$1@dont-email.me> |
| In reply to | #121948 |
On 3/11/25 06:29, Michael S wrote:
...
> Pay attention that fmod() has no requirements w.r.t. to such exceptions
> as FE_INEXACT, FE_UNDERFLOW and non-standard FE_DENORMAL.
> Strictly speaking, even raising FE_OVERFLOW is not illegal, but doing
> so would be bad quality of implementation.
> Also spec does not say what happens to FE_INVALID when one of the
> inputs is signalling NAN.
I've got Bonita killfiled, so the oldest message I can see on this
thread is one posted by you that indicated you were interested in IEEE
754 (==IOS/IEC 60559) conformance.
The C++ standard cross-references the C standard for such issues. The C
standard specifies that, for an implementation which pre#defines
__STDC__IEC_60559__BFP__, floating point exception handling is very
tightly specified for conformance with ISO/IEC 60559:
"The double version of fmod behaves as though implemented by
#include <math.h>
#include <fenv.h>
#pragma STDC FENV_ACCESS ON
double fmod(double x, double y)
{
double result;
result = remainder(fabs(x), (y = fabs(y)));
if (signbit(result)) result += y;
return copysign(result, x);
}
" (F10.7.1)
"Operations defined in 6.5 and functions and macros defined for the
standard libraries change floating-point status flags and control modes
just as indicated by their specifications (including conformance to IEC
60559). They do not change flags or modes (so as to be detectable by the
user) in any other cases." (F8.6)
"... signbit ... raise[s] no floating-point exceptions, even if an
argument is a signaling NaN." (F3p6)
"fabs(x) raises no floating-point exceptions, even if x is a signaling
NaN." (F10.4.3)
"— remainder(x, y) returns a NaN and raises the "invalid" floating-point
exception for x infinite or y zero (and neither is a NaN)." (F.10.7.2)
"copysign(x, y) raises no floating-point exceptions, even if x or y is a
signaling NaN." (F10.8.1)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-11 20:28 +0200 |
| Message-ID | <20250311202812.00005429@yahoo.com> |
| In reply to | #121940 |
On Mon, 10 Mar 2025 20:38:18 +0200
Michael S <already5chosen@yahoo.com> wrote:
> On Mon, 10 Mar 2025 19:00:06 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>
> > Your idea is really elegant
>
> I'd rather call it "simple" or "straightforward". "Elegant" in my book
> is something else. For example, the code above is closer to what I
> consider elegant.
> May be, later today or tomorrow, I'll show you solution that I
> consider bright. Bright, but impractical.
>
Here, here!
A bright part is in lines 18 to 29. The rest are hopefully competent
technicalities.
#include <string.h>
#include <stdint.h>
#include <math.h>
#include <fenv.h>
static uint64_t
umulrem(uint64_t x, uint64_t y, uint64_t den) {
#ifdef _MSC_VER
uint64_t hi, lo = _umul128(x, y, &hi);
uint64_t rem;
_udiv128(hi, lo, den, &rem);
return rem;
#else
return ((unsigned __int128)x * y) % den;
#endif
}
// Calculate mod(2**e, y) where y < 2**53
static uint64_t pow2_mod(uint64_t y, unsigned e) {
if (e < 64) {
uint64_t x = (uint64_t)1 << e;
if (x < y)
return x;
return x % y;
}
uint64_t x1 = pow2_mod(y, e/2);
uint64_t x2 = x1 << (e & 1);
return umulrem(x1, x2, y);
}
static double u2d(uint64_t u) {
double d;
memcpy(&d, &u, sizeof(d));
return d;
}
static uint64_t d2u(double d) {
uint64_t u;
memcpy(&u, &d, sizeof(u));
return u;
}
// raise FE_INVALID and return nan
static double raise_fe_invalid_ret_nan(double x)
{
const uint64_t SNAN_BITS = ~(1ull << 51);
double snan = u2d(SNAN_BITS);
#ifndef __clang__
return snan + x;
#else
volatile double v_snan = snan;
return v_snan + x;
#endif
}
double my_fmod(double x, double y)
{
const uint64_t INF_EXP = 2047;
const uint64_t INF2 = INF_EXP << 53;
const uint64_t HIDDEN_BIT = (uint64_t)1 << 52;
const uint64_t MANT_MASK = HIDDEN_BIT - 1;
const uint64_t SIGN_BIT = (uint64_t)1 << 63;
uint64_t ux = d2u(x);
uint64_t uy = d2u(y);
uint64_t ux2 = ux*2;
uint64_t uy2 = uy*2;
uint64_t sx = ux & SIGN_BIT;
// process non-finite x
if (ux2 >= INF2) { // x is inf or nan
if (ux2 > INF2) // x is nan
return x + y; // raises FE_INVALID when either x or y is sNAN
// x is inf
if (uy2 > INF2) // y is nan
return x + y;
// y is finite or inf
return raise_fe_invalid_ret_nan(x);
}
// x is finite
// process non-finite and zero y
if (uy2-1 >= INF2-1) { // y is inf or nan or 0
if (uy2 > INF2) // y is nan
return y;
// x is inf
if (uy2 == INF2) // y is inf
return x;
// y is 0
return raise_fe_invalid_ret_nan(x);
}
// y is finite non-zero
if (ux2 < uy2)
return x; // abs(x) < abs(y)
// extract mantissa and exponent
uint64_t mantX = (ux2 >> 1) & MANT_MASK;
uint64_t mantY = (uy2 >> 1) & MANT_MASK;
int expX = ux2 >> 53;
if (expX == 0) { // X subnormal
// Y is also subnormal, so we can use simple integer reduction
return u2d((mantX % mantY) | sx);
}
int expY = uy2 >> 53;
if (expY == 0) { // Y subnormal
mantY |= HIDDEN_BIT; // removed below
expY = 1;
}
mantY ^= HIDDEN_BIT;
mantX ^= HIDDEN_BIT;
if (mantX >= mantY) {
mantX -= mantY;
if (mantX >= mantY) // can happen when y is subnormal
mantX %= mantY;
}
int dExp = expX - expY;
uint64_t f = (dExp <= 63) ?
(uint64_t)1 << dExp : // quick path
pow2_mod(mantY, dExp); // slow path
mantX = umulrem(mantX, f, mantY);
// apply exponent of Y to mantX
uint64_t ures0 = ((uint64_t)expY << 52) | sx;
uint64_t ures = ures0 | (mantX & MANT_MASK);
if (mantX & HIDDEN_BIT)
ures0 = 0;
return u2d(ures) - u2d(ures0);
}
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-16 13:48 +0200 |
| Message-ID | <20250316134803.00005061@yahoo.com> |
| In reply to | #121958 |
On Tue, 11 Mar 2025 20:28:12 +0200
Michael S <already5chosen@yahoo.com> wrote:
> On Mon, 10 Mar 2025 20:38:18 +0200
> Michael S <already5chosen@yahoo.com> wrote:
>
> > On Mon, 10 Mar 2025 19:00:06 +0100
> > Bonita Montero <Bonita.Montero@gmail.com> wrote:
> >
> >
> > > Your idea is really elegant
> >
> > I'd rather call it "simple" or "straightforward". "Elegant" in my
> > book is something else. For example, the code above is closer to
> > what I consider elegant.
> > May be, later today or tomorrow, I'll show you solution that I
> > consider bright. Bright, but impractical.
> >
>
> Here, here!
> A bright part is in lines 18 to 29. The rest are hopefully competent
> technicalities.
>
And here is non-recursive implementation of the same algorithm that has
following potentially useful properties:
1. It does not use compiler-specific extensions, only standard C.
2. It does not use FMA, so gives correct results on implementations
with broken fam(), like MSVC on pre-AVX computers.
#include <string.h>
#include <stdint.h>
#include <math.h>
static double u2d(uint64_t u) {
double d;
memcpy(&d, &u, sizeof(d));
return d;
}
static uint64_t d2u(double d) {
uint64_t u;
memcpy(&u, &d, sizeof(u));
return u;
}
// raise FE_INVALID and return nan
static double raise_fe_invalid_ret_nan(double x)
{
const uint64_t SNAN_BITS = ~(1ull << 51);
double snan = u2d(SNAN_BITS);
#ifndef __clang__
return snan + x;
#else
volatile double v_snan = snan;
return v_snan + x;
#endif
}
double my_fmod(double x, double y)
{
const uint64_t INF_EXP = 2047;
const uint64_t INF2 = INF_EXP << 53;
const uint64_t HIDDEN_BIT = (uint64_t)1 << 52;
const uint64_t MANT_MASK = HIDDEN_BIT - 1;
const uint64_t SIGN_BIT = (uint64_t)1 << 63;
uint64_t ux = d2u(x);
uint64_t uy = d2u(y);
uint64_t ux2 = ux*2;
uint64_t uy2 = uy*2;
uint64_t sx = ux & SIGN_BIT;
// process non-finite x
if (ux2 >= INF2) { // x is inf or nan
if (ux2 > INF2) // x is nan
return x + y; // raises FE_INVALID when either x or y is sNAN
// x is inf
if (uy2 > INF2) // y is nan
return x + y;
// y is finite or inf
return raise_fe_invalid_ret_nan(x);
}
// x is finite
// process non-finite and zero y
if (uy2-1 >= INF2-1) { // y is inf or nan or 0
if (uy2 > INF2) // y is nan
return y;
// x is inf
if (uy2 == INF2) // y is inf
return x;
// y is 0
return raise_fe_invalid_ret_nan(x);
}
// y is finite non-zero
if (ux2 < uy2)
return x; // abs(x) < abs(y)
// extract mantissa and exponent
int64_t mantX = ((ux2 >> 1) & MANT_MASK)+HIDDEN_BIT;
int64_t mantY = ((uy2 >> 1) & MANT_MASK)+HIDDEN_BIT;
int expX = ux2 >> 53;
int expY = uy2 >> 53;
unsigned dExp = expX - expY;
double ax = fabs(x);
double ay = fabs(y);
if (ax*0x1p-53 <= ay) {
// Quick path
int64_t d = (int64_t)(ax/ay);
if (expY == 0) { // Y subnormal
// don't normalize
mantY -= HIDDEN_BIT;
expY = 1;
if (expX == 0) { // X subnormal
mantX -= HIDDEN_BIT;
expX = 1;
}
dExp = expX - expY;
}
mantX = (mantX << dExp) - mantY*(uint64_t)d;
} else {
if (expY == 0) { // Y subnormal
// Normalize
uy = d2u(y*0x1p52);
mantY = (uy & MANT_MASK) | HIDDEN_BIT;
expY = ((int)(uy >> 52) & 2047) - 52;
dExp = expX - expY;
}
if (mantY == (int64_t)HIDDEN_BIT)
return u2d(sx); // Y is power of 2
// Calculate rem(2**dExp, mantY)
unsigned e0, n_steps;
for (n_steps = 0, e0 = dExp; e0 > 105; ++n_steps)
e0 /= 2;
double ry = 1.0/mantY;
uint64_t mantRy = (d2u(ry) & MANT_MASK) | HIDDEN_BIT;
uint64_t d = mantRy >> (105-e0);
int64_t f = (((uint64_t)1 << 52) << (e0-52)) - mantY*d;
// f = rem(2**e0, mantY) + a*mantY where -1 <= a <= 1
if (n_steps > 0) {
int next_bit = n_steps-1;
const uint64_t F_MAX = (uint64_t)3 << 54;
do {
double df = (double)f;
d = (int64_t)(df*df*ry);
f = (uint64_t)f*(uint64_t)f - mantY*d;
f <<= (dExp >> next_bit) & 1;
if (f+F_MAX > F_MAX*2)
f -= (int64_t)(f*ry)*mantY;
--next_bit;
} while (next_bit >= 0);
}
if (mantX >= mantY)
mantX -= mantY;
d = (int64_t)((double)f*(int64_t)mantX*ry);
mantX = (uint64_t)f*(uint64_t)mantX - mantY*(uint64_t)d;
}
while ((uint64_t)mantX >= (uint64_t)mantY) {
if (mantX < 0)
mantX += mantY;
else
mantX -= mantY;
}
if (expY <= 1) { // Y subnormal
mantX >>= 1 - expY;
return u2d(mantX | sx);
}
// Apply exponent of Y to mantX
uint64_t ures0 = ((uint64_t)expY << 52) | sx;
uint64_t ures = ures0 | (mantX & MANT_MASK);
if (mantX & HIDDEN_BIT)
ures0 = 0;
return u2d(ures) - u2d(ures0);
}
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-10 13:17 +0200 |
| Message-ID | <20250310131727.00001445@yahoo.com> |
| In reply to | #121924 |
On Mon, 10 Mar 2025 07:24:18 +0100 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 09.03.2025 um 19:04 schrieb Michael S: > > > I already said that I don't approve non-portable constructs like > > _mm_getcsr()/_mm_setcsr() except when they help important cases and > > help ALOT. Neither applies here. > > I dropped getting and setting the MSCSR-register to set the roun- > ding mode. Now I set the rounding mode directly with the intrinsics > _mm_div_round_sd and and _mm_fmadd_round_sd. Now this more manual > code does help "ALOT", i.e. the solution is 2/3 faster than your > initial solution with clang++-18 under Linux. I can't check your claim about speed, because the code does not compile. Compiler has no idea WTF is xtrunc. But considering that so far all your claims about speed were false, I can safely assume that this one is false as well. > But there's still a problem with the denormals. > On y or on x? Subnormal values of x can be nicely handled by quick path with 0 additional characters of code. BTW, for last 20-25 years IEEE-754 prefers to call binary floating point numbers in range (0:DBL_MIN) 'subnormal' rather than 'denormal'. I'd guess that it is because the term 'denormal' has wider meaning.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-03-10 12:53 +0100 |
| Message-ID | <vqmjrg$1b12u$1@raubtier-asyl.eternal-september.org> |
| In reply to | #121926 |
Am 10.03.2025 um 12:17 schrieb Michael S: > I can't check your claim about speed, because the code does not compile. > Compiler has no idea WTF is xtrunc. But considering that so far all > your claims about speed were false, I can safely assume that this one > is false as well. Well, if that makes my statements easier for you. > On y or on x? I haven't checked that. But I've dropped the SSE-FMA-solution because with unsigned __int128 / uint64_t divisions my initial solution even faster, nearly one quarter than yours with clang++-18 under WSL2 for close exponents. With nearly arbitrary exponent combinations your solution is slightly faste (3%). > BTW, for last 20-25 years IEEE-754 prefers to call binary floating > point numbers in range (0:DBL_MIN) 'subnormal' rather than 'denormal'. > I'd guess that it is because the term 'denormal' has wider meaning. I don't insist so compulsively on standardized terms.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-03-10 12:54 +0100 |
| Message-ID | <vqmju6$1b12u$2@raubtier-asyl.eternal-september.org> |
| In reply to | #121926 |
Am 10.03.2025 um 12:17 schrieb Michael S: > I can't check your claim about speed, because the code does not compile. Test my latest code of my initial idea parallel to this posting in this thread.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-03-09 18:51 +0800 |
| Message-ID | <43425311f550aafa927441c22392027c6e6ef797.camel@gmail.com> |
| In reply to | #121904 |
On Sun, 2025-03-09 at 10:31 +0100, Bonita Montero wrote:
> This prints the same result (0.0) under Windows and Linux:
>
> double myFmod( double x, double y )
> {
> constexpr uint64_t
> SIGN = 1ull << 63,
> IMPLICIT = 1ull << 52,
> MANT = IMPLICIT - 1,
> QBIT = 1ull << 51;
> uint64_t const
> binX = bit_cast<uint64_t>( x ),
> binY = bit_cast<uint64_t>( y );
> static auto abs = []( uint64_t m ) { return m & ~SIGN; };
> auto isNaN = []( uint64_t m ) { return abs( m ) >= 0x7FF0000000000001u; };
> auto isSig = []( uint64_t m ) { return !(m & QBIT); };
> if( isNaN( binX ) ) [[unlikely]] // x == NaN
> #if defined(_MSC_VER)
> return bit_cast<double>( isNaN( binY ) ? binY | binX & binY & QBIT :
> binX );
> #else
> {
> if( isSig( binX ) || isNaN( binY ) && isSig( binY ) ) [[unlikely]]
> feraiseexcept( FE_INVALID );
> return bit_cast<double>( binX | QBIT );
> }
> #endif
> if( isNaN( binY ) ) [[unlikely]] // x != NaN || y == NaN
> #if defined(_MSC_VER)
> return y;
> #else
> {
> if( isSig( binY ) ) [[unlikely]]
> feraiseexcept( FE_INVALID );
> return bit_cast<double>( binY | QBIT );
> }
> #endif
> auto isInf = []( uint64_t m ) { return abs( m ) == 0x7FF0000000000000u; };
> if( isInf( binX ) ) // x == Inf
> {
> feraiseexcept( FE_INVALID );
> #if defined(_MSC_VER)
> return bit_cast<double>( binX & ~MANT | QBIT );
> #else
> return -numeric_limits<double>::quiet_NaN();
> #endif
> }
> if( !abs( binY ) ) [[unlikely]] // y == 0
> {
> feraiseexcept( FE_INVALID );
> #if defined(_MSC_VER)
> return numeric_limits<double>::quiet_NaN();
> #else
> return -numeric_limits<double>::quiet_NaN();
> #endif
> }
> if( !abs( binX ) || isInf( binY ) ) [[unlikely]] // x == 0 || y == Inf
> return x;
> auto exp = []( uint64_t b ) -> int { return b >> 52 & 0x7FF; };
> int
> expX = exp( binX ),
> expY = exp( binY );
> auto mant = []( uint64_t b ) { return b & MANT; };
> uint64_t
> mantX = mant( binX ),
> mantY = mant( binY );
> int headBits = 11;
> static auto normalize = [&]( int &exp, uint64_t &mant )
> {
> unsigned shift = countl_zero( mant ) - headBits;
> mant <<= shift;
> exp -= shift;
> };
> auto build = []( int &exp, uint64_t &mant )
> {
> if( exp ) [[likely]]
> mant |= IMPLICIT;
> else
> {
> exp = 1;
> normalize( exp, mant );
> }
> };
> build( expX, mantX );
> build( expY, mantY );
> int
> tailX = countr_zero( mantX ),
> tailY = countr_zero( mantY ),
> tailBits = tailX <= tailY ? tailX : tailY;
> mantX >>= tailBits;
> mantY >>= tailBits;
> headBits += tailBits;
> uint64_t signX = binX & SIGN;
> int expDiff;
> #if defined(_MSC_VER) && !defined(__llvm__) && defined(_M_X64)
> while( (expDiff = expX - expY) > 0 )
> {
> unsigned bits = expDiff <= 63 ? expDiff : 63;
> unsigned long long hi = mantX >> 64 - bits, lo = mantX << bits, remainder;
> (void)_udiv128( hi, lo, mantY, &remainder );
> if( !remainder ) [[unlikely]]
> return bit_cast<double>( signX );
> mantX = remainder;
> expX -= bits;
> normalize( expX, mantX );
> }
> #else
> while( (expDiff = expX - expY) > 0 )
> {
> unsigned bits = expDiff <= headBits ? expDiff : headBits;
> if( !(mantX = (mantX << bits) % mantY) ) [[unlikely]]
> return bit_cast<double>( signX );
> expX -= bits;
> normalize( expX, mantX );
> }
> #endif
> if( !expDiff && mantX >= mantY ) [[unlikely]]
> if( (mantX -= mantY) ) [[likely]]
> normalize( expX, mantX );
> else
> return bit_cast<double>( signX );
> mantX <<= tailBits;
> mantY <<= tailBits;
> if( expX <= 0 ) [[unlikely]]
> {
> assert(expX >= -51);
> mantX = mantX >> (unsigned)(-expX + 1);
> expX = 0;
> }
> return bit_cast<double>( signX | (uint64_t)expX << 52 | mantX & MANT );
> }
>
The basic problem is what the purpose of myFmod(double,double)? (maybe I missed something)
From the view of implementing myFmod, I think using C-like coding style would be better,
but all depending on what you want to achieve.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-03-09 12:56 +0100 |
| Message-ID | <vqjvm3$n81a$1@raubtier-asyl.eternal-september.org> |
| In reply to | #121909 |
Am 09.03.2025 um 11:51 schrieb wij: > From the view of implementing myFmod, I think using C-like coding style would be better, > but all depending on what you want to achieve. A C coding style would result in about two times the code.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-09 14:23 +0200 |
| Message-ID | <20250309142303.00007b67@yahoo.com> |
| In reply to | #121910 |
On Sun, 9 Mar 2025 12:56:55 +0100 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 09.03.2025 um 11:51 schrieb wij: > > > From the view of implementing myFmod, I think using C-like coding > > style would be better, but all depending on what you want to > > achieve. > > A C coding style would result in about two times the code. So far all we had see from you is 2-3 times longer than C code (real C, not C-style C++) that I posted here few days ago. And my code had more comments than yours, so difference in code itself is even bigger. Yes, part of it is because my algorithm is simpler. But that is only part.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-03-09 13:39 +0100 |
| Message-ID | <vqk268$npv0$1@raubtier-asyl.eternal-september.org> |
| In reply to | #121912 |
Am 09.03.2025 um 13:23 schrieb Michael S: > So far all we had see from you is 2-3 times longer than C code (real C, > not C-style C++) ... Not true since I save a lot of redundant-code with [&]-lambdas.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-09 14:56 +0200 |
| Message-ID | <20250309145625.0000349c@yahoo.com> |
| In reply to | #121913 |
On Sun, 9 Mar 2025 13:39:40 +0100 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 09.03.2025 um 13:23 schrieb Michael S: > > > So far all we had see from you is 2-3 times longer than C code > > (real C, not C-style C++) ... > > Not true since I save a lot of redundant-code with [&]-lambdas. Every heard of wc? It does not lie.
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.c++
csiph-web