[Cuis-dev] denormals

[Luciano Notarfrancesco]

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:
    internalState := internalState * dampingFactor + input
Thanks for the feedback (!) Martin, and to help me understand the issue a
bit better!


On Fri, Nov 21, 2025 at 02:39 Martin McClure <martin at hand2mouse.com> wrote:

> Right, for some applications it's OK to approximate.
>
> 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....
>
> On 11/20/25 11:27 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>
> 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!
>
> On Fri, Nov 21, 2025 at 02:06 Martin McClure <martin at hand2mouse.com>
> wrote:
>
>> 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 *all* the bits and have *no* accuracy."
>>
>> A faster path to a wrong answer is seldom, if ever, a good trade.
>>
>> Regards,
>>
>> -Martin
>> On 11/20/25 10:00 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>
>> 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:
>>     self isDenormalized ifTrue: [^ 0.0]
>> 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?
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20251121/502e72a7/attachment.htm>