I don't think that difference in one low-order bit in mantissa is bad result. Yes, IPP uses optimized algorithm for the best achievable performance - so if you need better accuracy - use 64f data type or another approach. IPP provides some tradeof between performance and accuracy with shift to performance. In this particular case the difference in one low-order mantissa bit is because of unrolling on the SSE register width - if result is not satisfactory for you - you always can switch to VectorSlope_64f with convertion to 32f at the final stage - you'll loss ~2x in performance.
Please take a look at results of my investigation:
1. This is how these numbers look like in Base10, Base 16 and Base2 ( Binary ):
Sign Exponent Mantissa
0.125000000 (Base10) = 0x3F900000 (Base16) = 0 01111111 00100000000000000000000 (Base2)
0.124999493 (Base10) = 0x3DFFFFBC (Base16) = 0 01111011 11111111111111110111100 (Base2)
2. Absolute Error is ( 0.124999493 - 0.125000000 ) = -0.000000507
Epsilon for a Single-Precision FP number is 1.192092890e-07
If I divide |0.000000507| by 1.192092890e-07 it gives ~4.25.
( Exact value is: 4.2530242756501970244952975099113 )
So, the absolute error is greater than Epsilon for aSingle-Precision FP number in ~4.25 times!
I think the case 'ippsVectorSlope_32f(pResult, 8192, 0, 1/48000f) => 0.124999493' has to be investigated
by an Intel software engineer.
More accurate representation for 0.124999493 according to IEEE 754 standard is 1.249994933605194091796875E-1