• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 86 subscribers
  • Views 1157 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/LAUNCHXL-F28379D: For the selection of fp_mode = relaxed, any fixed formula/pattern to predict the deviation from ISO or loss in accuracy in floating point operations

Aditya Padmanabha
Expert 1440 points
Part Number: LAUNCHXL-F28379D

Tool/software: TI C/C++ Compiler

Hi,

As per c28x compiler manual, section 2.3.3, setting the fp_mode = relaxed will result in faster code but the result does not conform with ISO standards and will have some loss of accuracy. Is there any formula or pattern which can help me to find the difference in the results in any floating point operations when the mode is relaxed compared to the strict mode? Do we have any ways to predict the amount of the loss of accuracy in relaxed mode in any floating point operations?

Thanks,

Aditya

  • 0
    Expert 2520 points
    Hi,

    For single precision operations you should expect relative result error up to 2/2^24 = FLT_EPSILON (defined in float.h), 0.12 ppm.

    Edward
  • 0
    TI__Guru**** 243690 points

    Aditya Padmanabha said:
    Is there any formula or pattern which can help me to find the difference in the results in any floating point operations when the mode is relaxed compared to the strict mode? Do we have any ways to predict the amount of the loss of accuracy in relaxed mode in any floating point operations?

    Unfortunately, the answer to both questions is no.  You might find a bit more insight in this article on Floating Point Optimization.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 2520 points

    Hi George,

    It is still FLT_EPSILON. From document you pointed to:

    •   In relaxed mode, the compiler may perform speed optimizations at the expense of reducing the precision of some calculations, typically a tiny amount. For instance, (X/3) is not precisely equivalent to (X*(1.0/3)), but in relaxed mode, the compiler is allowed to make this transformation anyway, as multiplication is much faster than division.

    Single FP operation using round to nearest even mode, which is used by CCS and C2800 FPU, has to differ from exact result of mathematical operation no more than RESULT * (FLT_EPSILON / 2). Since replacing X/3 by X*(1.0/3) is two operations instead of one, total allowed error is 2 * (RESULT * (FLT_EPSILON / 2)).

    (BTW TMU DIVF32 instruction seems having problems with proper rounding to nearest even. Was it really validated? 1.0/3.0 should be the same as 3.0/9.0 and 9.0/27.0, unfortunately they differ)

    Edward

  • 0 in reply to EK
    TI__Mastermind 27200 points

    Edward,

    Yes, that is correct.  To compute Y/X, the TMU first estimates 1/X and then multiplies it with Y.  For the 1/X computation, we have a max error of 1 ULP.  Extending it for Y/X there will be a 2 ULP error.  Hence, we don’t expect 3.0/9.0 and 9.0/27.0 to have similar results.

    Regards,

    Richard

     

  • 0 in reply to Richard Poley
    Expert 2520 points

    Hi Richard,

    One operation with round to nearest should produce <= 0.5 ULP error, not 1 ULP. In other words correct result must be no more than halfway between two adjacent FP numbers. Two operations - 1 ULP, not 2 ULP. Perhaps we mean different ULPs? Did you mean closest separation between FP numbers with different exponents, like 1.0 (0x3F800000) and 0.999999940395355 (0x3F7FFFFF). These two differ by 0.5 ULPs.

    I didn't know that TMU multiplies by reciprocal. But this doesn't justify difference 1/3 vs 3/9 v 9/27.

    1/3)

    1(3f800000) / 3(40400000) = (3eaaaaab) with round to nearest.

    Lets' prove using integer divide 80000000000000 / C00000 = AAAAAAAA, after rounding and discarding extra bits AAAAAB

    3/9)

    1(3f800000) / 9(41100000) = 3de38e39

    80000000000000 / 900000 = E38E38E3, -"- E38E39

    (3de38e39) * 3(40400000) = (3eaaaaab)

    e38e39 * C00000 = AAAAAAC00000, after rounding AAAAAB

    3/27)

    1(3f800000) / 27(41d80000) = 3d17b426

    80000000000000 / D80000 = 97B425ED -> 97B426

    (3d17b426) * 9(41100000) =  (3eaaaaab)

    97B426 * 900000 = 555555600000, subnormal, shift left AAAAAAC00000, after rounding the same AAAAAB

    You may also notice that even without rounding all three 1/3, 3/9 and 9/27 should produce identical results.

    Regards,

    Edward