It's understandable to have a different interpretation of the modulo operator: different languages implement it differently, and Perl's implementation is not the most straightforward. If you come from the spreadsheet world, Excel's MOD() and VBA's Mod both work with floating point. C's % works purely with integers, or fmod() for floating point. Perl's %, OTOH, has a bunch of conditionals to determine integer vs. floating-point context. I'll expound on them slightly, in case it might help JBCookin:

• Binary "%" is the modulo operator, which computes the division remainder of its first argument with respect to its second argument.:
  ⇒ if someone just read the first line of the paragraph, there is no mention of integer vs float.
• Given integer operands $m and $n: If $n is positive, then $m % $n is $m minus the largest multiple of $n less than or equal to $m . If $n is negative, then $m % $n is $m minus the smallest multiple of $n that is not less than $m (that is, the result will be less than or equal to zero). :
  ⇒ explicitly integer condition
• If the operands $m and $n are floating point values and the absolute value of $n (that is abs($n)) is less than (UV_MAX + 1) , only the integer portion of $m and $n will be used in the operation (Note: here UV_MAX means the maximum of the unsigned integer type).:
  ⇒ so when the divisor happens to fit under some maximum integer, then both $m and $n are truncated to integers. (I believe that perl -V:intsize, which shows the number of bytes in an integer, will also be the number of bytes in an unsigned integer... but it might use perl -V:ivsize instead... someone with more perlguts knowledge than me can clarify)
• If the absolute value of the right operand (abs($n)) is greater than or equal to (UV_MAX + 1) , "%" computes the floating-point remainder $r in the equation ($r = $m - $i*$n) where $i is a certain integer that makes $r have the same sign as the right operand $n (not as the left operand $m like C function fmod() ) and the absolute value less than that of $n .:
  ⇒ so only with a very large divisor $n would use full floating point modulo.

JBCookin, I hope this helps you understand better... And hippo's solution should give you the fractional component you need.

update: strike the invalid interpretation; thanks syphilis++ for confirmation of the alternate

... but it might use perl -V:ivsize instead...

Yes, "ivsize" is what you need to look at. That tells you how many bytes there are in the signed and unsigned perl integers (IV and UV).
"intsize" merely tells you the number of bytes in the C "int" for the compiler that built perl, and that is commonly less than the number of bytes in the perl integer.

Cheers,
Rob

Yea I know what it does. My point is wouldn't it be more useful if m%n worked the way it does now for all n where n≠1, but when n=1 it returns the fractional part, since right now it only returns 0.

I understand why it only returns 0, I just think that it would be more useful if for the specific case m%1 the return value is the fractional part of m.

This kind of DWIM magic edge cases is actually causing much trouble in Perl.

Better define your own custom function.

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

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.