Dean Rasheed <dean.a.rash...@gmail.com> writes: > On Wed, 23 Feb 2022 at 20:55, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I'm +1 on 0001 and 0002, but 0003 feels >> a bit ad-hoc. It certainly *looks* weird for the allegedly faster >> function to be handing off to the allegedly slower one. I also wonder >> if we're leaving anything on the table by not exploiting >> div_var_fast's weaker roundoff guarantees in this case. Should we >> think about a more thoroughgoing redesign of these functions' APIs?
> Hmm, I'm not sure what kind of thing you had in mind. I'm not either, tbh. Just seems like this needs more than some hacking around the margins. > One thought that occurred to me was that it's a bit silly that > exp_var() and ln_var() have to use a NumericVar for what could just be > an int, if we had a div_var_int() function that could divide by an > int. Then both div_var() and div_var_fast() could hand off to it for > one and two digit divisors. Oooh, that seems like a good idea. regards, tom lane