[Cuis-dev] denormals

[Martin McClure]

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/20251120/ac5fa75b/attachment.htm>