[L2Ork-dev] Precision of [sqrt~] for double-precision

[Matt Barber]

Even with double precision numbers stored in those tables, you're still
restricting your input to the 254 exponent values and 10 bits of mantissa.

The rough outline of the algorithm hinges on the idea that sqrt(a*b) =
sqrt(a) * sqrt(b). So, since floating point is represented
exponent*mantissa, you can get sqrt(e*m) by doing sqrt(e)*sqrt(m). That
means if you can pre-compute all possible sqrt(e) except NaNs, infs, and
denormals, and enough mantissa values to whatever significant bits you
want, you can get really efficient. The reason to precompute the reciprocal
first is because you save the divide in the perform function. Instead, you
can rely on f*(1/sqrt(f)) = sqrt(f), so it's a simple multiply by the float
you already have.

The rest of it is just bit paperwork. All the << 23 you see are to get to
the exponent bits. The mantissa table holds rsqrt values for 1.0 +
intervals of 1./1024. (that initial 1.0 is implied in normalized float
representation).

So basically, you're accepting double-precision values for inputs truncated
to 18 bits of precision. One problem is that you'll get very bad values for
very high input exponents because you're bashing everything to
single-precision exponent range. Might not be the worst thing, but
something to consider.

Matt



On Wed, Jun 6, 2018 at 11:34 PM, Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> Hi list,
>
> Looking at a double precision patch here:
>
> https://git.purrdata.net/jwilkes/purr-data/merge_requests/224
>
> And looking at these declarations/definitions from d_math.c:
>
> static float rsqrt_exptab[DUMTAB1SIZE], rsqrt_mantissatab[DUMTAB2SIZE];
>
> So... what happens if we just change "float" to "t_float" here?
>
> At a glance it seems like we can still cast back to "float" to
> derive the index in sigsqrt_perform. Then we grab the
> t_float from that index and do the remaining multiplications
> at double precision instead of single precision.
>
> On the other hand, that would be 8 double-precision float
> operations per sample.
>
> Anyhow, as it is this algorithm appears to compute the
> same values for both single- and double-precision versions
> of Purr Data.
>
> I'm not sure how to judge the importance of realtime
> efficiency vs. whatever precision expectations someone
> has when running double-precision Purr Data. (I also don't
> completely understand the algorithm.)
>
> Any thoughts?
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20180607/a909349f/attachment.html>