| [reply] [Watch: Dir/Any] |
I agree that making an edge case for 1, specifically, would be DWIMmery. But I think that the current implementation of truncate floating points to integers before applying an integer modulo, unless the divisor happens to be bigger than UV_MAX+1; oh, and by the way, we're going to require you to study perlguts to know that UV_MAX is the same number of bits as IV_MAX, but unsigned, and that UV_MAX+1 can thus be calculated from $UV_MAX_PLUS_ONE = 256**$Config{ivsize}. Personally, I think it should only use the integer moduluo if both operands are integers that fit within ivsize; otherwise, if either operand is recognizably floating point (ie, has a fractional component, or is too big for IV), then use floating-point modulo. Or, be like C and never make exceptions: have separate operators for integer modulo and floating modulo. The Perl implementation has too many DWIM DWTPM-isms for my tastes.
But yes, since it's so easy to define the custom function as hippo did, that's the best choice for Perl at this stage in the game.
| [reply] [Watch: Dir/Any] [d/l] |
I don't know much about the other flaws*, but we agree that we shouldn't add more.
> otherwise, if either operand is recognizably floating point (ie, has a fractional component, or is too big for IV), then use floating-point modulo.
Perl is unlike Python or JS an operator language.
If you want an operator where modulo returns a fraction, write a patch to introduce something like %% (hopefully this doesn't clash with a special variable)°
*) I suppose they are related to integers being represented as floats if they become to big to be stored as integers.
°) hnngnggnn ...
$FORMAT_PAGE_NUMBER
$%
The current page number of the currently selected output channel.
Mnemonic: % is page number in nroff.
| [reply] [Watch: Dir/Any] [d/l] [select] |