[Cuis-dev] Documentation for the different kinds of divisions

[Luciano Notarfrancesco]

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.

On Tue, 26 May 2020 at 4:41 AM, Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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:
> >
> https://cs.stackexchange.com/questions/24362/why-does-floating-point-modulus-exactness-matters
> > 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,
> > https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-advice.htm
> What you don't learn by comprehension, you will learn by suffering.
>
> Andres.
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200526/8032fb8b/attachment-0001.htm>