Re: DSP API overlapping arrays + inv() and neg()

Jussi,

That might be something worth pursuing. At some point the API only  
supported the source-is-destination paradigm, and I encountered the  
inv/neg problem too. Are you suggesting that there should be another  
signature, (dest/src1, src2), in addition to the current (dest, src1,  
src2) signature, or should we drop the latter from the API?

Keep in mind, there are a few disadvantages of the source-is-destination  
paradigm:

1) Order matters, as you pointed out. May require additional operations to  
cover all use-cases.

2) In many situations, you need to do an explicit memory-copy operation,  
for instance:

   a = b - c   becomes:

   a.set(b);
   DSP.sub(a, c);

3) Some operations (Filter & FFT) can't be done in-place, so you'd either  
have to use a different paradigm for those operations (and solve the  
overlapping-problem anyway - possibly using exceptions), or use internal  
destination buffers and do an extra memory-copy operation.

My idea with the current spec would be to disallow overlapping operation,  
and for some operations support source & destination to be the same. If  
violated, throw an exception.

We also have to consider the case where the the second source argument (if  
any) overlaps with the destination argument, so for instance in DSP.sub(a,  
b, c), a, b, and c may all be overlapping (e.g. thanks to  
TypedArray.subarray).

/Marcus


Den 2012-11-02 21:00:45 skrev Jussi Kalliokoski  
<jussi.kalliokoski@gmail.com>:

> Hey Marcus,
>
> We were just discussing our implementations of the DSP API on IRC with  
> Jens. We were thinking about the problem of source >and destination  
> arrays being the same or overlapping, and came to the conclusion that  
> it's not a good idea to allow this >because it will be impossible to  
> define this behavior without restricting implementations too much (we  
> shouldn't require >the implementations to guarantee that things are run  
> in 0 - n order, otherwise we'll exclude parallelization). However,  
> >avoiding creating unnecessary copies of data is a good thing, so we  
> thought that a suitable solution would be that >dropping the destination  
> parameter(s) would imply that destination and first source are the same  
> array.
>
> That, however, presents another problem, because sub and div give  
> different results if you change the order of the sources >(obviously).  
> For this, inv(erse) and neg(ate) would be useful additions to the API.
>
> Cheers,
> Jussi



-- 
Marcus Geelnard
Core graphics developer
Opera Software ASA