- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

*...Perhaps VectorSlope is not computing the value as documented ( result* = offset + n*slope), but is avoiding multiplication by iteratively

...

**adding the slope value**?

...

It looks like in order to achieve as better as possible performance Intel's software developers could do that.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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.

Regards,

Igor

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

*ippsVectorSlope_32f(pResult, 8192, 0, 1/48000f)pResult[6000] containsippsVectorSlope_32f(pResult, 8192, 0, 1);ippsDivC_32f_I(48000f, pResult, 8192);pResult[6000] contains Any ideas?*

**0.124999493 - That's bad**.

**0.125 - That's good**.

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.

**Note:**

More accurate representation for 0.124999493 according to IEEE 754 standard is 1.249994933605194091796875E-1

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page