Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Wed, Apr 4, 2012 at 12:11, Tobias Burnus
<tobias.burnus@physik.fu-berlin.de> wrote:
> Janne Blomqvist wrote:
>> the attached patch implements a few fixes and cleanups for the MOD and
>> MODULO intrinsics.
>
>> The patch adds notes to the documentation about the usage of fmod, so
>> users interested in corner-case behavior can look up how that function
>> is supposed to behave on their target.
>
>> +@item @emph{Note}:
>> +The obvious algorithm as specified above is unstable for large real
>> +inputs. Hence, for real inputs the result is calculated by using the
>> +@code{fmod} function in the C math library.
>
> I wonder whether one should extend the note, stating that that using
> "fmod" might lead to a `wrongly' signed 0. Something like: "; depending
> on its implementation, this might lead to a diffent sign for 0 results
> - compared to the result of the obvious algorithm."

Yes, but if one describes the behavior for one special case, IMHO one
should also specify it for other special cases. E.g. from the glibc
fmod manpage:

...the returned value has the same sign as x and a magnitude less than
the magnitude of y.

       If x or y is a NaN, a NaN is returned.

       If x is an infinity, a domain error occurs, and a NaN is returned.

       If y is zero, a domain error occurs, and a NaN is returned.

       If x is +0 (-0), and y is not zero, +0 (-0) is returned.

For compile-time evaluation, MPFR fmod conforms to the specification
for fmod in C99 Annex F, and for runtime so does glibc fmod (see
above). But for other targets, runtime might be different. But I
couldn't come up with a formulation that I was happy with; not that
I'm happy about my text in the patch either. Suggestions welcome..

> Since you modify intrinsic.texi, could you also do:
> - Add a cross @ref between mod and modulo.

Ok.

> - Show in the example (as comments) also the result of the mod/module
> Âoperations. As many confuse mod (=remainder) and modulo, it makes
> Âsense to help them by showing the result of examples.*

Well, Fortran mod != C99 remainder().

So for a general remainder operation the result is "x-n*y" (evaluated
with infinite precision), where n is x/y rounded to an integer in some
way. Then we have at least the following cases

- C fmod and Fortran MOD: n is rounded towards zero

- Fortran MODULO: n is rounded towards -Infinity

- C99 and IEEE754 remainder: n is rounded to the nearest integer.
Incidentally, this has the nice property that abs(result) <= abs(y/2).

> Please also update the Copyright year for simplify.c.

Ok.

> Otherwise, the patch looks OK.
>
> (Except for the mode change of libgcc/configure - which requires a build
> maintainer approval. If you want to make it executable, do the same also
> for libitm/configure - and do so in a separate patch.)

Ah, that was some autogenerated stuff that was accidentally included
in the patch. Please disregard it.


-- 
Janne Blomqvist