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

[Nicolas Cellier]

Le lun. 25 mai 2020 à 16:29, Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> a écrit :

> Hi,
>
>
Hi Andres,


> On 5/24/20 23:20, Nicolas Cellier via Cuis-dev wrote:
> >
> >
> > Le lun. 25 mai 2020 à 07:55, Andres Valloud via Cuis-dev
> > <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> a écrit :
> >
> >     Why would you want to add division with floating point properties to
> >     the
> >     integers?  The reference you mention,
> >
> >     https://www.cplusplus.com/reference/cmath/remainder/
> >
> >     does not mention the integers, and instead seems entirely concerned
> >     with
> >     floating point arithmetic (where, presumably, a division with
> floating
> >     point properties would be relevant).  Surely we already have (several
> >     flavors of) exact quotients for the integers.  Is there a reason why
> >     this has been pending since 2015?
> >
> >
> > Waouh, very negative reaction!
>
> No, you brought this up to my attention, and this is news to me.  From
> the information I was provided, I have questions.  I haven't formed an
> opinion yet, literally because I have not heard any answers to the
> questions.  No information, no opinion :).
>
> > ratio: and residue: perfectly works with Integer/Fraction
> > receiver/arguments as we would expect: they delivered a "centered"
> > modulo and rounded quotient and don't mess with Float at all.
>
> Ok --- just keep in mind, I did not question this.
>
> > In addition, ratio: and residue: do the correct thing they should when
> > invoked with Float.
>
> Ok --- note, I did not question this either.
>
> > Why is it still pending?
> > Because no one cares of floating point standards in the Smalltalk
> community?
>
> Well, come on, who's being negative now?... I didn't say a word about
> that.  In fact, I asked you questions because I was interested --- look
> at the reaction I got :).
>
> Sure, it was kind of joke, but not so much given the number of
uncareful/arbitrary approximations that still makes cross dialect
reproducibility almost impossible whatever my efforts (a pity since our
execution model never suffered from extended precision register
optimizations or operation reordering)...
In Squeak trunk we still have cos defined as ^ (self + Halfpi) sin, a proof
that we value simplicity more than correctness.
Such simplicity has a great price in term of ulps...
If I want to simulate a wave with cos(w*t), that gonna make a huge
difference after a few hundred cycles.
This is certainly the worst implementation I ever seen with this regard.

I'd say that sometimes it's very tough to get some traction on these
> things.  I suppose in part it's because of the difference in perspective
> between (for lack of better terms) numerical analysts for which an
> intimate understanding of IEEE-754 is required and taken for granted,
> and people who develop applications that happen to use floating point
> numbers pragmatically in ways such that e.g. 17 / 20 = 0.85 is useful.
>
> It's going to be very difficult to get some common ground between these
> two very different perspectives.  And it doesn't even matter who's right
> and who's wrong.  I'd venture it's not even clear there is an absolute
> right or wrong, either.
>
> Nevertheless, with these questions that I asked, I am trying to find
> some common ground.  Let me rephrase the questions, as I think there are
> still things to consider.
>
> I can see that ratio: / residue: could make sense in the integers.  What
> I am asking is whether there is motivation other than "it makes sense"
> to add such a division there.  Or, put in a different way, what do you
> see is the use case of replicating the floating point division rounding
> behavior in the integers?  That is, why would you add that
> functionality?  You must have had some utility in mind, and you thought
> about this code much longer than I did.  So, what did you see?
>
> Couldn't we ask the same question about div:/mod: ?
This thread excited my curiosity, so I wanted to let Cuis people know about
yet another variant, especially because you and Luciano are not so much
afraid by maths, Juan neither I guess ;)

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.
Does it make sense in some Core/Kernel image?
I don't want to decide that kind of thing alone.
I restrained from adding those extensions in Squeak, because two different
divisions is already a lot.
I propose in inbox, if people find them interesting, good, if no one
reacts, then it'll be a small extension module of mine.

The float remainder might have less applications, I haven't one myself,
apart for some numerical analysis...
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.html

Not sure that Cuis really targets such exhaustivity. Minimalism is a
virtue. But again, that raise the question for div:/mod:. Just curious...

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/20200525/f27c516e/attachment.htm>