> Date: Mon, 27 May 2019 22:28:37 +0900
> From: Tetsuya Isaki <is...@pastel-flower.jp>
>
> At Sat, 25 May 2019 18:01:11 +0300,
> Valery Ushakov wrote:
> > My point is exactly that you are confusing implementation detail that
> > uses right shift as a good enough implementation (which, I reiterate,
> > I don't object to here) and what is the meaning of the operation that
> > you are implementing/approximating (see my first paragraph above).
>
> I'm sorry, I don't understand (I can't parse) this paragraph
> due to my poor English skill. Would you write it again?
>
> And anyway I don't understand your point well. Can you show me
> your proposal patch?
Hi, Isaki-san!
As I understand it, uwe is just asking you to use a different name,
because `AUDIO_ASR' suggests only one particular approximation, and
it's not even the one that the code always uses. Perhaps
`AUDIO_SCALEDOWN' would be clearer?
In more detail:
- Mathematically, the function is used to scale an amplitude x down by
2^n:
f_n(x) = x/2^n.
This function has the property that f_n(-x) = -f_n(x), i.e. f_n is
an odd function.
- In digital audio, we approximate this real-valued function f_n(x)
with integer arithmetic. We have a couple choices for how to do
this:
. truncate(x/2^n), which is also an odd function.
. floor(x/2^n), which is _not_ an odd function, and so is maybe not
as good an approximation.
On platforms where floor(x/2^n) can be computed more efficiently, by
doing x >> n, than truncate(x/2^n), i.e. x/(1 << n), then that's OK:
being off by one in this approximation, under negation, is not very
bad.
- Whichever approximation we choose, we should _name_ the function for
the mathematical operation it approximates, which is scaling an
amplitude down, not for one of the approximations it _might_ use.
Calling it AUDIO_ASR seems wrong because:
. the main purpose is to use _some_ approximation to scale an
amplitude down -- it is an implementation detail that it sometimes
approximates the mathematical function by a right shift;
. the function doesn't necessarily always compute floor(x/2^n) --
that is, the function you have named AUDIO_ASR doesn't necessarily
shift right.
Maybe we could call it AUDIO_SCALEDOWN or something instead?
