[Liboil] complex types?

[David Schleef]

On Wed, Nov 16, 2005 at 12:56:08AM +0100, Stephane Fillod wrote:
> With stride or without ? Should stride be present everywhere?
> Personaly, I don't need stride in forseeable future.

Without.  Function classes with strides are nearly impossible to
make fast.

> On a different topic, can you please explain what is the convention 
> about implementation modifiers like "_i10", "_l10" ? I will need
> them for sincos.

For now, ignore them.  I'll add them to function classes if I think
they're appropriate.

_i10 stands for "inaccurate by a factor of 10", where the baseline
accuracy is 2^-52 for doubles and 2^-24 (I think).  It's a decilog
scale, so _i20 is a factor of 100, etc.  The baseline accuracy comes
from the least expressible number greater than 1.0.

_l10 stands for "something is limited to 10".  Sometimes this means
input range, e.g., _l15 is (was?) used for some function class that
could only handle input values in the range [-1<<14, 1<<14-1].
Another class uses this to mean that only 10 of the input values
can be non-zero (oil_idct8x8theora_l10).

These modifiers are obviously not well-thought-out.  In order to
be useful, applications need to be able to make predictions about
accuracy based on value of n, input values, etc.  I also don't
think that simply defining new classes is a maintainable solution.

In the pie-in-the-sky future, I'd like to see a wrapper library
around liboil that will select specific implementations based on
speed or accuracy, and provide those as a "palette" of functions
that the application code calls.  This requires that any liboil
function calls be vectored through an array (the "palette") tied
to the context.  This likely requires autogenerated code to set
up correctly.



dave...

-- 
David Schleef
Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux