Hi Damian -
I really want mod(x,y) for integers x,y to return a positive value
whenever y is positive (since I frequently use mod to bucket values
into an array). I also want mod(x,y) for reals to do the same
thing when both arguments are integral. That gives the 'floor' behavior
here.
Since the IEEE/IEC standards can't possibly say anything about
what Chapel names these functions - why would you expect 'mod' to
work the same as C's 'fmod'? Is it just that it has a similar name?
Likewise, I don't understand why one could claim that Julia does
not follow the standard. The Julia function 'rem' just does not
correspond to a 'rem' operation in the standard (e.g.).
Is it important to you that the Chapel Math library include a
function with the equivalent behavior to C 'fmod' ?
I don't understand why we would need to create any functions
to do more floating point rounding. We already have
(for rounding to integers):
- rint = round-using-current-rounding-mode-checked-for-IEEE854-exactness
- round = round-to-nearest-half-tied-away-from-zero
- nearbyint = round-using-current-rounding-mode
- floor = round--towards-negative-infinity
- ceil = round--towards-positive-infinity
- trunc = round-towards-zero
That leaves (from your list):
- round-to-nearest-half-tied-to-even, which you get by with nearbyint
if you haven't changed the rounding mode.
Is it important to have a separate function that does that?
Wouldn't you rather have support for setting the current rounding mode?
I don't understand what a rounding function would do if it wasn't
rounding to an integer... and since rounding occurs in every floating
point operation, it seems better to me to work with the idea of
a 'current rounding mode' than to enumerate all the possibilities.
So, given that we have functions to round floating point numbers to
integers in various rounding modes, why do we also need 'mod' functions
with all of those possibilities? Or, put another way, why couldn't we
have a 'mod' function that implements one particular rounding mode?
My feeling is that we need to:
1) supply functions that enable specific rounding (which we do,
except that we might need to support setting the current
rounding mode)
and
2) leave 'mod' as it is, since it's consistent with the integer
version, and either create a separate 'fmod' or expect
users to implement their own (using the explicit rounding functions)
if they need something different.
Thanks,
-michael
On 5/26/15, 10:19 PM, "Damian McGuckin" <[email protected]> wrote:
>
>Basically the standard defines 6 roundings
>
>Rounding To Nearest either
>1) (Half) Tied away from Zero
>2) (Half) Tied to Even
>
>Rounding Towards (Directional Rounding)
>3) +Infinity
>4) -Infinity
>5) Zero
>
>The IEEE854 2008 standard (well IEC 60559 which is part of ISO)
>
>a) mandates 'rem' by (2). Almost everybody obeys it because it was
> a relivatively recent addition. Julia does not.
>
>b) says nothing about and 'mod' but
> - C99 and D and Fortran chose (5) (trunc)
> - Chapel and Julia chose (4) (floor)
>
>Interesting that Chapel and Julia made the same choice.
>
>Maybe we need a way to do Modulus ALL five different ways?
>
>Executive/Consensus Decisions?
>
>Regards - Damian
>
>P.S. That Reference for Julia is (by the way) is
>
>http://docs.julialang.org/en/release-0.1-0/manual/mathematical-operations/
>
>At least Julia has 2 totally orthogonal methods.
>
>Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW
>2037
>Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted
>here
>Views & opinions here are mine and not those of any past or present
>employer
>
>--------------------------------------------------------------------------
>----
>_______________________________________________
>Chapel-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/chapel-users
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
