<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hi Nicolas,<br>
    <br>
    (big snip - inline)<br>
    <br>
    On 5/25/2020 5:03 PM, Nicolas Cellier via Cuis-dev wrote:
    <blockquote
cite="mid:CAKnRiT4rOLLgZ+BnpZVY0Whp7SZObU5f8d=2eezYDhHKE+TTxQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">...<br>
        <div class="gmail_quote">
          <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>
      </div>
    </blockquote>
    <br>
    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?<br>
    <br>
    Still, it is not obvious to me. How far is this from the correct
    result?<br>
    <br>
    <blockquote
cite="mid:CAKnRiT4rOLLgZ+BnpZVY0Whp7SZObU5f8d=2eezYDhHKE+TTxQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <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>
      </div>
    </blockquote>
    <br>
    Well, sometimes math proves to be useful :)<br>
    <br>
    <blockquote
cite="mid:CAKnRiT4rOLLgZ+BnpZVY0Whp7SZObU5f8d=2eezYDhHKE+TTxQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <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
              moz-do-not-send="true"
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
              moz-do-not-send="true"
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>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:CAKnRiT4rOLLgZ+BnpZVY0Whp7SZObU5f8d=2eezYDhHKE+TTxQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <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>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Thanks,<br>
    <pre class="moz-signature" cols="72">-- 
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
  </body>
</html>