Hi!
I am again about accuracy. input parameters exp=0xffffff6d=-147 -> -(36.75) right? value d2=210
210^(4/3)*2^(-36.75)*2^28
ans = 2.89921171527700
my answer 3
MAD 0.15 - #define FPM_INTEL answer 2
What is the problem? Thanks for answer.
On Mar 24, 2004, at 12:36 AM, Grigory A. wrote:
I am again about accuracy. input parameters exp=0xffffff6d=-147 -> -(36.75) right? value d2=210
210^(4/3)*2^(-36.75)*2^28
ans = 2.89921171527700
my answer 3
MAD 0.15 - #define FPM_INTEL answer 2
What is the problem?
Keeping in mind that 2^(-36.75) = 2^(-36) × 2^(-3/4), you will find that III_requantize(210, -147) calculates:
210^(4/3) ⇒ 0x04e0393e × 2^12 0x04e0393e × 2^(-36+12) ⇒ 0x00000005 2^(-3/4) ⇒ 0x09837f05 0x00000005 × 0x09837f05 ⇒ 0x00000002
I think the difference is due to rounding errors from the limited precision of the fixed-point type. You're talking about a difference of 3.725e-9, pretty insignificant in the grand scheme of things.
If you configure with --enable-accuracy, you'll get a slightly better fixed-point multiplication in the last step that happens to yield the value you were expecting.
Hello Rob,
Wednesday, March 24, 2004, 7:12:59 PM, you wrote: RL> Keeping in mind that 2^(-36.75) = 2^(-36) ? 2^(-3/4), you will find RL> that III_requantize(210, -147) calculates:
RL> 210^(4/3) ? 0x04e0393e ? 2^12 RL> 0x04e0393e ? 2^(-36+12) ? 0x00000005 RL> 2^(-3/4) ? 0x09837f05 RL> 0x00000005 ? 0x09837f05 ? 0x00000002
RL> I think the difference is due to rounding errors from the limited RL> precision of the fixed-point type. You're talking about a difference of RL> 3.725e-9, pretty insignificant in the grand scheme of things.
RL> If you configure with --enable-accuracy, you'll get a slightly better RL> fixed-point multiplication in the last step that happens to yield the RL> value you were expecting.
Yes I am agree. Only one difference in my calculation scheme I firs multiply on root - in this case 2^(-3/4) and next rounding and shifting. This small changes give more precise result.
And why I am talking about it. Now I am "porting" MAD 0.15 to 3DSP platform www.3dsp.com this is 32 bits dsp with 32x32 multiplier - so I am expect good result.
Now at my decoder differences after III_requantize() are +-1 only - but at synthesis time sbsamples have +-25 with average rms ~1.2e-8 compare to MAD. My calculation is performed in 4.28x1.31 format - so error coming from this last bit in 4.28 representation of Xr data.
And - I have working "MAD" decoder for TI tms320vc55xx series dsp - but it is 16 bits implementation - so only limited accuracy and some time even worst :). If some one need - I can send it. Later I will publish it on web.
On Mar 24, 2004, at 5:36 PM, Grigory A. wrote:
Keeping in mind that 2^(-36.75) = 2^(-36) × 2^(-3/4), you will find that III_requantize(210, -147) calculates:
210^(4/3) ⇒ 0x04e0393e × 2^120x04e0393e × 2^(-36+12) ⇒ 0x00000005 2^(-3/4) ⇒ 0x09837f05 0x00000005 × 0x09837f05 ⇒ 0x00000002
Yes I am agree. Only one difference in my calculation scheme I firs multiply on root - in this case 2^(-3/4) and next rounding and shifting. This small changes give more precise result.
You make a good point. The accuracy can indeed be improved by multiplying the root first, before losing significant digits from the shift.
This probably merits a change for the next release.
Thanks,
-
Grigory A. -
Rob Leslie