World: r3wp

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.

as a side note, when would I ever use a modulus function with decimals? 
Maybe in special cases, where I need to write a special ROUND function 
myself or something? What is this use for else?

Proportional coordinates.

as I said, I was asked to make MOD available; and to even add the 
MODULO function, since Gregg felt, that they were useful on their 
own. YMMV

*used* for

Ladislav, I think, you and I agree much about many of these things. 
It's too bad, things get more complicated than necessary, because 
such functions become part of the language.

The difference in the handling of negative numbers is sufficient 
justification for me. The rounding difference is just a bonus.

Brian, what do you mean with proportional coordinates and the use 
of modulus?

regarding the "decimal arithmetic made easy" - this is not just the 
case of MODULO, it is also related to comparison, like EQUAL?, etc., 
I think, that it is Carl's design decision

When we are at it,

>> mold/all remainder 0.3 0.1
== "0.099999999999999978"


, i.e. remainder 0.3 0.1 astually isn't 0.1, otherwise it would be 
really wrong!

excuse my typo above "actually"

Would all those problems be solved, if the decimal! datatype actually 
was the money! datatype, and if we then had a real! datatype, that 
did it a fast way and giving results as we see in C and other languages?

As a practical example, if you are doing device-independent rendering 
you work in proportions (floating point ratios) and then convert 
to exact values (integer coordinates) on final rendering to the real 
device. Video games do this all the time - that is why GPUs need 
floating point hardware. Same with sub-pixel rendering. If you are 
working in proportions, your modulus functions will need to handle 
them. And modulus could be used for bounding box calculations on 
textured surfaces too.


In both those cases, the programmer will probably know enough about 
accumulated error to want to control it themselves. The non-rounding 
behavior of // would be a benefit to them then, so rounding can be 
minimized.

I feel, much confusion come from having a decimal! datatype, that 
isn't really that, decimal.

There are two reasons, why it it not feasible, IMO:


1) decimal! was used for IEEE754 as "the most common floating point 
datatype"


2) money! is not as "common", because it is slower, so maybe this 
should not change

Otherwise, I am pretty sure, that the name "decimal!" was unfortunate!

Also, think of the syntax. We have a sigil to denote the current 
money! type, which *was* added for financial calculations. If that 
type was the default, what would the floating-point sigil be?

...but, I guess, that Carl still thinks, that the majority of users 
may be formed by the people, for whom the name "64-bit binary floating 
point number" sounds like insult

I agree that float! would have been a better name than decimal! (not 
real! because they aren't). Too late now.

real! is not that bad either, actually, they are (subset of) real 
numbers, with "just a bit twiddled" arithmetic

That "subset of" is the kicker. Integers are also a subset of real 
numbers.

anyway, money! are implemented to have floating (really decimal in 
that case) point too

yes, but (Rebol) integers are subset of integers too

Brian, regarding graphics, wouldn't it be normal to convert the floats 
to integers before doing the modulus calculation? I may be wrong, 
but I'm not sure, I would need float modulus in such application.

so, integer! datatype comprises some integer numbers, therefore the 
real! datatype could comprise some real number IMO

In Python, they call them reals. In Lua, you just have numbers. Integers 
and floats are the same internally as far as I can see.