[Issue 3171] % not implemented correctly for floats
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Tue Jul 14 04:03:20 PDT 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3171
--- Comment #4 from Don <clugdbug at yahoo.com.au> 2009-07-14 04:03:19 PDT ---
(In reply to comment #3)
> Thanks for the explanation. At least I know why that happens, now. What do you
> suggest, then? Staying with FPREM or going with FPREM1 ?
It's hard to justify including a primitive built-in operator that differs from
IEEE. But it may be justifiable when it's the only way to avoid a major break
from C and intuition.
int x = 15 % 10;
int y = cast(int)((cast(float)15) % 10);
// Are we really comfortable with these being completely different?
You know, all this time I was thinking that the behaviour of % for negative
integers was because it needed to be consistent with floating-point modulus...
Now it just seems to be wrong.
But I think I have the answer. In IEEE, the preferred conversion from float to
int uses round-to-nearest. IEEE remainder makes sense in that context. Since in
cast(int), D has inherited 'chop' rounding from C, D needs to also inherit C's
fmod behaviour.
So D should stay with FPREM. But we need to document it properly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list