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

[Juan Vuletich]

Hi Nicolas,

(big snip - inline)

On 5/25/2020 5:03 PM, Nicolas Cellier via Cuis-dev wrote:
> ...
> 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.

It is also the implementation in Cuis :( . I guess we need a new 
primitive right? Maybe some simple math trick could give us the correct 
result?

Still, it is not obvious to me. How far is this from the correct result?

>     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 ;)

Well, sometimes math proves to be useful :)

>
> 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

Gilad makes a lot of claims in that piece. Although I agree with most he 
says, I don't agree with it all. Many of us having own opinions is also 
something that makes the "great unification" unlikely.

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

Cuis pursues minimalism. So, things that are not kernel functionality go 
in optional packages. For example Complex. But having a complete set of 
operations for the Number classes we include, is important. I think we'd 
include these.

WRT IEEE-754 / IEC 60559, I think strict compliance is of paramount 
importance. People should be able to port numerical code using floats to 
/ from other commonly used languages with the least possible amount of 
trouble.

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200525/2f4d332e/attachment.htm>