World: r3wp

I also tested, that it takes equal amount of cpu time to do this 
in C, where a and b are of type double:

fmod (a, b)

or

a - floor (a / b) * b

Same can be said for integers, where we would use % in C.

I conclude, it makes sense to drop MOD and MODULO, and then use the 
calculation using floor for both integers and decimals. It will give 
the mathematically best result, and it will perform as good as using 
% and fmod in C.

MOD and MODULO are supposed to be different from // for *negative* 
numbers.

If you look at the source for those functions, you will see that 
MOD calls // internally, and MODULO calls MOD.

Neither call floor (unless // calls it internally).

And if you look in HELP MODULO, it looks like a hack to fix some 
problem:


Wrapper for MOD that handles errors like REMAINDER. Negligible values 
(compared to A and B) are rounded to zero.

Yup. Which is where my math knowledge left off. I can see the math 
they use, but not why it is necessary.

I get MOD, I think: It's that negative values thing. MODULO seems 
to deal with the epsilon, afaict.

Ladislav wrote them, iirc. If he thinks they're necessary I'll take 
his word for it :)

Ops, I said something wrong, when saying, the division can be on 
either side of zero. The division is of course close to a whole number, 
but can be on either side of that number, so the rounding can be 
that number (if the result lie above) or one below that number (if 
the result is below). Using ROUND instead of ROUND/FLOOR solves it.

Use the SOURCE, Luke. ROUND isn't used at all.

I just say Ladislav popping in. Ladislav, if you don't wanna read 
all, my question simple is, if we need all of REMAINDER, MOD and 
MODULO?

Although perhaps it should be. MOD and MODULO were written when ROUND 
was mezzanine. Now that ROUND is native, perhaps MOD and MODULO could 
be optimized by someone who understands the math (not me).

(And maybe you're not the one to answer this question.) :)

When implementing Round as mezzanine, I needed MOD to do it, and 
Gregg thought it might have been useful to make it available;

Good enough :)

Remaninder (//) is handling operands as "exact", MOD uses some "rounding", 
MODULO is more "standard" and uses even more rounding

the difference is as follows:

>> mod 0.3 0.1
== -2.77555756156289e-17

>> remainder 0.3 0.1
== 0.1

>> modulo 0.3 0.1
== 0.0

The fact is, that MOD was necessary for positive values of B only, 
so there is no provision for the negative ones

So the difference is only, when the division give a remainder close 
to zero. Example of same results:

>> mod 0.3 0.2
== 0.1
>> remainder 0.3 0.2
== 0.1
>> modulo 0.3 0.2
== 0.1


And then there are some differences, when dealing with negative numbers.

Should there be? And is more optimization possible?

Should there be? -> Should there be provision for the negative ones, 
Ladislav?

It is even possible to axe the MOD function, ask Gregg, what he thinks 
about it

(or make it "hidden", if the MODULO function remains)

With the MOD function inlined in MODULO, more optimization may be 
possible.

So the difference is only, when the division give a remainder close 
to zero.

 - actually not, the difference is visible, if the Remainder function 
 gives a result close to the B value

(called Value2 in case of the Remainder function)

Yes, more precise formulation.

thanks

If we get rid of MOD and just go with MODULO, should we rename MODULO 
to MOD ?

The disadvantage is that MOD might be a less-specific name.

I do not mind, as far as I remember, I really used it only in the 
mezzanine implementation of Round, although, some stand-alone use 
might make sense

My suggestion is to get rid of moth MOD and MODULO, and then deside 
on a way, REMAINDER should work. People can always make some function 
in special cases. And remember rule no. 1!
K.I.S.S.

moth = both

aha, so you would suggest to change the Remainder behaviour?

If functions like MOD and MODULO is needed, then the real problem 
might be with remainder?

Well, Remainder does not do *any* rounding, which may be what is 
desired, or not.

I'm studying Lua these days, and they just have one function, that 
do:
a - floor (a / b) * b
Simple to understand.

What would be the consequences of such a change? I remember you going 
on about IEEE754 predictability, and this would seem to reduce precision 
- all that rounding...

I saw that implementation before I read about modulus on wikipedia 
and wolfram.

I would keep MODULO (maybe make it native) and let MOD be defined 
as an operator that redirects to it.

operator? - do you mean infix?

Yes. It is intended that R3 op! functions be allowed to be defined 
on other types of functions than action! type. Even user-defined.

So, Geomol, what is the result of a - floor (a / b) * b, if a = 0.3 
and b = 0.1?

It might be a good idea to split the problem between integer and 
decimal behaviour. In the case of integer, there should be one way 
to do it. Today we have two different outcome:

>> -8 // 3
== -2
>> mod -8 3
== 1

(MODULO give same result as MOD.)

See, that is what I was talking about: Different behavior with negative 
numbers.

Ladislav, the result is 0.1, and we know why. The programmer should 
know too and find some way to figure out, that 0.1 almost divide 
up in 0.3. One way is to divide 0.3 by 0.1 and see if the result 
is close to an integer.

the result 0.1 is OK with me, but not with Gregg, neither with Carl, 
AFAIK

Modulus isn't defined for negative numbers, so different programming 
langages behave differently in that case. Some behave like //, some 
like MOD, some (correctly, but not usefully) error out.