<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 25 mai 2020 à 16:29, Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br></blockquote><div> <div><br></div><div>Hi Andres,</div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> On 5/24/20 23:20, Nicolas Cellier via Cuis-dev wrote:<br> > <br> > <br> > Le lun. 25 mai 2020 à 07:55, Andres Valloud via Cuis-dev <br> > <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>>> a écrit :<br> > <br> > Why would you want to add division with floating point properties to<br> > the<br> > integers? The reference you mention,<br> > <br> > <a href="https://www.cplusplus.com/reference/cmath/remainder/" rel="noreferrer" target="_blank">https://www.cplusplus.com/reference/cmath/remainder/</a><br> > <br> > does not mention the integers, and instead seems entirely concerned<br> > with<br> > floating point arithmetic (where, presumably, a division with floating<br> > point properties would be relevant). Surely we already have (several<br> > flavors of) exact quotients for the integers. Is there a reason why<br> > this has been pending since 2015?<br> > <br> > <br> > Waouh, very negative reaction!<br> <br> No, you brought this up to my attention, and this is news to me. From <br> the information I was provided, I have questions. I haven't formed an <br> opinion yet, literally because I have not heard any answers to the <br> questions. No information, no opinion :).<br> <br> > ratio: and residue: perfectly works with Integer/Fraction <br> > receiver/arguments as we would expect: they delivered a "centered" <br> > modulo and rounded quotient and don't mess with Float at all.<br> <br> Ok --- just keep in mind, I did not question this.<br> <br> > In addition, ratio: and residue: do the correct thing they should when <br> > invoked with Float.<br> <br> Ok --- note, I did not question this either.<br> <br> > Why is it still pending?<br> > Because no one cares of floating point standards in the Smalltalk community?<br> <br> Well, come on, who's being negative now?... I didn't say a word about <br> that. In fact, I asked you questions because I was interested --- look <br> at the reaction I got :).<br> <br></blockquote><div>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)...</div><div>In Squeak trunk we still have cos defined as ^ (self + Halfpi) sin, a proof that we value simplicity more than correctness.</div><div>Such simplicity has a great price in term of ulps...</div><div>If I want to simulate a wave with cos(w*t), that gonna make a huge difference after a few hundred cycles.<br></div><div>This is certainly the worst implementation I ever seen with this regard.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I'd say that sometimes it's very tough to get some traction on these <br> things. I suppose in part it's because of the difference in perspective <br> between (for lack of better terms) numerical analysts for which an <br> intimate understanding of IEEE-754 is required and taken for granted, <br> and people who develop applications that happen to use floating point <br> numbers pragmatically in ways such that e.g. 17 / 20 = 0.85 is useful.<br> <br> It's going to be very difficult to get some common ground between these <br> two very different perspectives. And it doesn't even matter who's right <br> and who's wrong. I'd venture it's not even clear there is an absolute <br> right or wrong, either.<br> <br> Nevertheless, with these questions that I asked, I am trying to find <br> some common ground. Let me rephrase the questions, as I think there are <br> still things to consider.<br> <br> I can see that ratio: / residue: could make sense in the integers. What <br> I am asking is whether there is motivation other than "it makes sense" <br> to add such a division there. Or, put in a different way, what do you <br> see is the use case of replicating the floating point division rounding <br> behavior in the integers? That is, why would you add that <br> functionality? You must have had some utility in mind, and you thought <br> about this code much longer than I did. So, what did you see?<br> <br></blockquote><div>Couldn't we ask the same question about div:/mod: ?</div><div>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 ;)</div><div><br> </div><div> The integer division makes sense for specialized applications.</div><div>I used it 30 years back for polynomial factorization, if I remember, because it leads to smaller LargeIntegers in p-adic methods.<br></div><div>Does it make sense in some Core/Kernel image?</div><div>I don't want to decide that kind of thing alone. <div>I restrained from adding those extensions in Squeak, because two different divisions is already a lot.</div><div>I propose in inbox, if people find them interesting, good, if no one reacts, then it'll be a small extension module of mine.</div> </div><div><br></div><div>The float remainder might have less applications, I haven't one myself, apart for some numerical analysis...</div><div>I even asked the question here: <a href="https://cs.stackexchange.com/questions/24362/why-does-floating-point-modulus-exactness-matters">https://cs.stackexchange.com/questions/24362/why-does-floating-point-modulus-exactness-matters</a></div><div>Extending IEC 60559 compliancy could be a goal per se for a generalist language, but that's a mixture of engineering/marketing decisions.</div><div>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.html">https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-advice.html</a></div><div><br></div><div>Not sure that Cuis really targets such exhaustivity. Minimalism is a virtue. But again, that raise the question for div:/mod:. Just curious...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Andres.<br> -- <br> Cuis-dev mailing list<br> <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br> </blockquote></div></div>