<div><div><div><div dir="auto">Ok, this was useful, I realized I was mixing up two different things: subnormals, and the passage from Small64Floats to Boxed64Floats. I did some more research and it seems with audio signals I can just zero out anything below certain inaudible threshould. A threshould of 0.00001585 (-96 dB) turns out to be a common choice in profesional audio DSP, and this is way above subnormals. It can be important when there’s feedback, for example in filters, delays, reverbs, etc, where you might have something like this:</div><div dir="auto">    internalState := internalState * dampingFactor + input</div><div dir="auto">Thanks for the feedback (!) Martin, and to help me understand the issue a bit better!</div><div dir="auto"><br></div><div><br><div class="gmail_quote"></div></div></div><div><div><div class="gmail_quote"></div></div></div></div><div><div><div><div class="gmail_quote"></div></div></div></div></div><div><div><div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 21, 2025 at 02:39 Martin McClure <<a href="mailto:martin@hand2mouse.com" target="_blank">martin@hand2mouse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><u></u>

  
    
  
  <div>
    <p>Right, for some applications it's OK to approximate. </p>
    <p>One of the worst cases is if you're computing a / b. If both a
      and b are normal floats with 52 significant fraction bits, you'll
      get full 52-bit accuracy with only rounding of less than one ULP,
      but if b is subnormal you will get an accuracy of at most the
      number of significant bits in b. And if you flush b to zero, then
      you divide by zero....</p></div><div>
    <p>On 11/20/25 11:27 AM, Luciano Notarfrancesco via Cuis-dev wrote:</p>
    <blockquote type="cite">
      
      <div dir="auto">Right, I see, depends on the application… I’m not
        doing that for every float, for pcm audio i just flush to zero
        anything under -90 dB, and I saw some people add a little dither
        noise instead, but in other cases it’s not so straight forward…
        I’m not sure I’m doing it right for filter coefficients, etc,
        I’ll look more carefully at how other similar projects do it.
        Thanks!</div>
      <div><br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Fri, Nov 21, 2025 at
            02:06 Martin McClure <<a href="mailto:martin@hand2mouse.com" target="_blank">martin@hand2mouse.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
            <div>
              <p>Avoiding subnormal floats is desirable, since
                subnormals have fewer significant bits than normal
                floats. This should ideally be done by designing the
                application to do its computations so that subnormals
                are never created. Forcing subnormals to go to zero is
                the wrong direction entirely -- that is saying "I've
                lost some bits of accuracy, so now let's throw away <i>all</i> the
                bits and have <i>no</i> accuracy."</p>
              <p>A faster path to a wrong answer is seldom, if ever, a
                good trade.</p>
              <p>Regards,</p>
              <p>-Martin</p>
            </div>
            <div>
              <div>On 11/20/25 10:00 AM, Luciano Notarfrancesco via
                Cuis-dev wrote:<br>
              </div>
              <blockquote type="cite"> It seems to me that when working
                with floats in Cuis we should try to avoid denormals (or
                subnormals, i.e. floats that are very close to 0 but not
                0). They used to be slower than other floats in old
                CPUs, and they are not so much of a problem anymore in
                modern CPUs, but I think they would still be problematic
                in Cuis because they turn into BoxedFloat64 (instead of
                SmallFloat64). What’s the best way to handle them? For
                the time being I implemented
                BoxedFloat64>>undenormalized as:
                <div dir="auto">    self isDenormalized ifTrue: [^ 0.0]</div>
                <div dir="auto">and in Float just returns self. The
                  method isDenormalized comes in the base image, but
                  it’s not super fast. Is there a better way to do it?</div>
                <br>
                <fieldset></fieldset>
              </blockquote>
            </div>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
    </blockquote>
  </div>

</blockquote></div></div>
</div>
</div>
</div>