On Sat, 29 Jun 2024 at 16:25, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Dean Rasheed <dean.a.rash...@gmail.com> writes: > > There's another complication though (if the threshold is made > > configurable): the various numeric functions that use mul_var() are > > immutable, which means that the results from the Karatsuba algorithm > > must match those from the schoolbook algorithm exactly, for all > > inputs. > > That seems like an impossible standard to meet. What we'd probably > have to do is enable Karatsuba only when mul_var is being asked > for an exact (full-precision) result.
Yeah, using Karatsuba for approximate products is probably a bit too ambitious. I think it'd be reasonably straightforward to have it produce the same results for all rscale values. You'd just have to decide on the required rscale for each sub-product, based on where it's being added, truncating at various points, and being sure to only round once at the very end. The problem is that it'd end up computing a larger fraction of the full product than the schoolbook algorithm would have done, so the threshold for using Karatsuba would have to be higher (probably quite a lot higher) and figuring out how that varied with the requested rscale would be hard. So using Karatsuba only in the full-precision case seems like a reasonable restriction. That'd still benefit some other functions like sqrt() and therefore ln() and pow() to some extent. However,... > There is definitely an argument to be made that this proposal is > not worth the development effort and ongoing maintenance effort > we'd have to sink into it. I'm leaning more towards this opinion, especially since I think the patch needs a lot more work to be committable. Regards, Dean