Elena [service address] wrote:
Yes I know... I meant computing B2A tables in function of a virtually smoothed A2B table (virtually = smoothed only at search-time, using an incraesed tolerancy).
There is no such thing as "virtually" smoothed - the smoothing parameters are used in the construction of the A2B cLUT. Some sort of separate smoothing can't be applied when the tables are being read, because they are actually being analytically inverted in creating the B2A. So to implement such a feature would mean actually creating 3 A2B tables (3 x the execution time there), and wiring the B2A table construction to access the three different A2B tables rather than one. The B2A table lookups get some speedup from caching the inverse lookup calculation values and creating the three tables simultaneously - this would be lost with three separate A2B tables. So I don't think this is a good direction to go in. Fixing the underlying problem is probably a better use of time and effort. Graeme Gill.