Re: Optimize mul_var() for var1ndigits >= 8
От | Joel Jacobson |
---|---|
Тема | Re: Optimize mul_var() for var1ndigits >= 8 |
Дата | |
Msg-id | cfad3a9e-f935-46b4-80f6-c98769b4831f@app.fastmail.com обсуждение исходный текст |
Ответ на | Re: Optimize mul_var() for var1ndigits >= 8 ("Joel Jacobson" <joel@compiler.org>) |
Ответы |
Re: Optimize mul_var() for var1ndigits >= 8
|
Список | pgsql-hackers |
On Mon, Aug 12, 2024, at 12:47, Joel Jacobson wrote: >> 2). Attempt to fix the formulae incorporating maxdigits mentioned >> above. This part really made my brain hurt, and I'm still not quite >> sure that I've got it right. In particular, it needs double-checking >> to ensure that it's not losing accuracy in the reduced-rscale case. > > To test if there are any differences that actually matter in the result, > I patched mul_var to log what combinations that occur when running > the test suite: I expanded the test to generate 10k different random numerics for each of the reduced rscale cases. This actually found some differences, where the last decimal digit differs by one, except in one case where the last decimal digit differs by two. Not sure if this is a real problem though, since these differences might not affect the result of the SQL-callable functions. The case found with the smallest rscale adjustment was this one: -[ RECORD 1 ]------+-------------------------------- var1 | 0.0000000000009873307197037692 var2 | 0.426697279270850 rscale_adjustment | -15 expected | 0.0000000000004212913318381285 numeric_mul_rscale | 0.0000000000004212913318381284 diff | -0.0000000000000000000000000001 Here is a count grouped by diff: diff | count --------------+---------- 0.000e+00 | 14114384 1.000e-108 | 1 1.000e-211 | 1 1.000e-220 | 2 1.000e-228 | 6 1.000e-232 | 2 1.000e-235 | 1 1.000e-28 | 13 1.000e-36 | 1 1.000e-51 | 2 1.000e-67 | 1 1.000e-68 | 1 1.000e-80 | 1 -1.000e-1024 | 2485 -1.000e-108 | 3 -1.000e-144 | 2520 -1.000e-16 | 2514 -1.000e-228 | 4 -1.000e-232 | 1 -1.000e-27 | 36 -1.000e-28 | 538 -1.000e-32 | 2513 -1.000e-48 | 2473 -1.000e-68 | 1 -1.000e-80 | 2494 -2.000e-16 | 2 (26 rows) Should I investigate where each reduced rscale case originates from, and then try to test the actual SQL-callable functions with values that cause the same inputs to mul_var as the cases found, or do we feel confident these differences are not problematic? Regards, Joel
Вложения
В списке pgsql-hackers по дате отправления: