<div><div dir="auto">Personally I don’t have senders of div:, mod:, quo: or rem:. And don’t think I could just call #residue: from my code, I just meant that I’m using centered remainders but I’m not actually computing it as a remainder, I compute it from an element of Z/mZ that is internally represented with an integer between 0 and m-1, I don’t make a division. And anyway it’s just one line of code, I don’t have a strong opinion about including it or not in the base image, I don’t mind either way.</div></div><div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 May 2020 at 4:41 AM, Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi, > In Squeak trunk we still have cos defined as ^ (self + Halfpi) sin, a > proof that we value simplicity more than correctness. I'd like to believe there was a good reason for such an approach, I just can't imagine what that might be. Right now, all I can see is that it's slow, it gets the wrong results, and it also makes porting serious numerical analysis algorithms impossible. Also, it's clever :/. > Couldn't we ask the same question about div:/mod: ? The thing about div: and mod: is that, since the remainder is never negative, it facilitates doing many commonplace things. For example, back in 2015, there used to be a sender of rem: (I believe) that would essentially give you the HSV hue given a number of radians. Except of course when the receiver was negative, you'd get a negative hue, and that would break stuff because HSV hues are not negative. It's much better to use mod:, rather than... you know... rem:, < 0 ifTrue: [2 pi - rem]... blah... this was an actual bug that was fixed with mod:, see Color>>hue:. I think it could have been fixed by \\ too, but now you have to remember that \\ will give you the right sign of the remainder when the receiver's sign... blah blah... and all that intellectual overhead goes away using mod:, the one with non-negative remainders no matter what. Also, in that method, the code really means mod:, not \\ or rem:. In number theory, the mod: operation with its never-negative remainders is the most natural for many applications (but not all, of course, finite calculus is much better with // and \\ because they lead to stable behavior of floor and ceiling). Now it doesn't matter which integer you divide by: you always get positive remainders, which feed naturally into equivalence classes with non-negative representatives, as well as histograms that do not have to account for signs. > The integer division makes sense for specialized applications. > I used it 30 years back for polynomial factorization, if I remember, > because it leads to smaller LargeIntegers in p-adic methods. Do you know much about Dixon's factorization method? > Does it make sense in some Core/Kernel image? I think it makes at least some sense there, seeing how it's used helps developing an opinion. Apparently Luciano is already using the idea, why have it twice. However... > The float remainder might have less applications, I haven't one myself, > apart for some numerical analysis... ... so, let's take a closer look then. Maybe we can find better names, kind of along the lines of what Luciano says? > I even asked the question here: > <a href="https://cs.stackexchange.com/questions/24362/why-does-floating-point-modulus-exactness-matters" rel="noreferrer" target="_blank">https://cs.stackexchange.com/questions/24362/why-does-floating-point-modulus-exactness-matters</a> > Extending IEC 60559 compliancy could be a goal per se for a generalist > language, but that's a mixture of engineering/marketing decisions. > The kind of little decisions which might make a difference in the end, > if you read recent post from Gilad, > <a href="https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-advice.htm" rel="noreferrer" target="_blank">https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-advice.htm</a> What you don't learn by comprehension, you will learn by suffering. Andres. -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div></div>