[Cuis-dev] denormals

[Luciano Notarfrancesco]

Great, that’s a good example. Until I understand it better, instead of
guessing where to handle them just in case, I’ll first add a check and halt
if they come up. Thanks!

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/86045f4a/attachment.htm>