Allow number values for basic operations

[jussi-kalliokoski]

(This has been brought up before on the AudioWG mailing list)

Currently only the x value is allowed to be a number for basic operations (add, mul, div, etc), which complicates things when you want to for example divide an array by a single number. Now you can only divide a single number by an array.

In my mind ideally the basic operations should only enforce that the dst is an array.

[opera-mage]

There's no practical reason for not supporting what you say, but on the other hand it will not give you any added functionality either (as far as I'm concerned, it's only for convenience). There are a few reasons why supporting many variants have not been included yet:

1. The current API exposes the necessary primitives that should/would be implemented natively. Additional overloaded signatures in the API would just be transformed to calls to one of the existing methods. E.g. add(dst, src, scalar) -> add(dst, scalar, src), add(dst, scalar1, scalar2) -> fill(dst, scalar1+scalar2), div(dst, src, scalar) -> mul(dst, 1/scalar, src), etc.

2. Having more overloaded variants of a method typically adds calling overhead. There are more cases to be handled either dynamically for each call (worst case), or at JIT-time if the API is tightly integrated with the ECMAScript engine and all argument types are known at compile time (best case). In the latter case, having multiple signatures is not really a problem, but in the former case, you can get a significant relative overhead for short arrays (e.g. <= 128 elements), especially if we're considering support for things like mulCplx(dstR, dstI, src1R, scalar1, scalar2, src2I) -> many possible signatures per method.

3. It would increase the API surface area, adding to e.g. testing complexity.

So, in principle I'm not against it, but I wanted to hold off with adding it until there's consensus that it's necessary.