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.

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)°

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

*) 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.
[download]