Kyle,

I get the same answer as you.  However isn't it dividing by 2 one extra time since the reason it exited the loop was that it was equal to 1.0f

John

Hi John,

Thanks for your quick response.

The previous code divides eps by two in the termination condition to look ahead for the value where 1+eps==1, so when the loop is exited, eps contains the smallest value such that 1+eps != 1.

I modified the code to illustrate this better:

    float eps,lead_eps,val1;
    eps = 1.0f;
    lead_eps = 0.0f;
    val1 = 0.0f;

    printf("val1 != 1.0?  \n");
    while( val1 != 1.0f )
    {
        printf("yes: val1=%.17f...........lead_eps=%.17f.....eps=%.17f\n",val1, lead_eps,eps);
        eps/=2.0f;
        lead_eps = eps/2.0f;
        val1 = (1.0f + lead_eps);
    }
    printf("\nno : val1=%.17f...........lead_eps=%.17f.....eps=%.17f\n",val1,lead_eps,eps);
    printf("one plus eps: %.17f\none plus lead_eps=%.17f",1.0f+eps,1.0f+lead_eps);
    printf("\n\neps=%.17f",eps);

my output:

val1 != 1.0?  
yes: val1=0.00000000000000000...........lead_eps=0.00000000000000000.....eps=1.00000000000000000
yes: val1=1.25000000000000000...........lead_eps=0.25000000000000000.....eps=0.50000000000000000
yes: val1=1.12500000000000000...........lead_eps=0.12500000000000000.....eps=0.25000000000000000
yes: val1=1.06250000000000000...........lead_eps=0.06250000000000000.....eps=0.12500000000000000
yes: val1=1.03125000000000000...........lead_eps=0.03125000000000000.....eps=0.06250000000000000
yes: val1=1.01562500000000000...........lead_eps=0.01562500000000000.....eps=0.03125000000000000
yes: val1=1.00781250000000000...........lead_eps=0.00781250000000000.....eps=0.01562500000000000
yes: val1=1.00390625000000000...........lead_eps=0.00390625000000000.....eps=0.00781250000000000
yes: val1=1.00195312500000000...........lead_eps=0.00195312500000000.....eps=0.00390625000000000
yes: val1=1.00097656250000000...........lead_eps=0.00097656250000000.....eps=0.00195312500000000
yes: val1=1.00048828125000000...........lead_eps=0.00048828125000000.....eps=0.00097656250000000
yes: val1=1.00024414062500000...........lead_eps=0.00024414062500000.....eps=0.00048828125000000
yes: val1=1.00012207031250000...........lead_eps=0.00012207031250000.....eps=0.00024414062500000
yes: val1=1.00006103515625000...........lead_eps=0.00006103515625000.....eps=0.00012207031250000
yes: val1=1.00003051757812500...........lead_eps=0.00003051757812500.....eps=0.00006103515625000
yes: val1=1.00001525878906250...........lead_eps=0.00001525878906250.....eps=0.00003051757812500
yes: val1=1.00000762939453125...........lead_eps=0.00000762939453125.....eps=0.00001525878906250
yes: val1=1.00000381469726563...........lead_eps=0.00000381469726563.....eps=0.00000762939453125
yes: val1=1.00000190734863281...........lead_eps=0.00000190734863281.....eps=0.00000381469726563
yes: val1=1.00000095367431641...........lead_eps=0.00000095367431641.....eps=0.00000190734863281
yes: val1=1.00000047683715820...........lead_eps=0.00000047683715820.....eps=0.00000095367431641
yes: val1=1.00000023841857910...........lead_eps=0.00000023841857910.....eps=0.00000047683715820
yes: val1=1.00000011920928955...........lead_eps=0.00000011920928955.....eps=0.00000023841857910
yes: val1=1.00000011920928955...........lead_eps=0.00000005960464478.....eps=0.00000011920928955

no : val1=1.00000000000000000...........lead_eps=0.00000002980232239.....eps=0.00000005960464478
one plus eps: 1.00000011920928955
one plus lead_eps=1.00000000000000000

eps=0.00000005960464478

my output comments:

It is curious that while 1+2^-24 doesn't equal 1, it doesn't equal 1+2^-24 either, but rather 1+2^-23. I am sure it is just something I don't understand about floating point arithmetic.

Right, I missed the /2.0f in the condition.  I really don't know much about floating point either.  I will slide this over to the C2000 forum.  They should know if the value in float.h is correct.

John

Thanks John.

Bump.

Last bump.

John, Kyle,

This seems to be a simulator issue.  I ran this on actual silicon with the following result.

John - can you file an issue against the simulator?

Yeah, thanks!

Honeywell requires a correction to this simulator issue if it truly exists and/or provide a determination of root cause and further information regarding the effects of this bug.  Is accuracy higher, in the simjulator, for example?  Note, we actually require the simulator to behave like the silicon in order to qualifiy our products, so a fix may be the only solution.  Without further information, we cannot explain the difference to our certification authorities.

So, please provide a detailed explaination of the problem, the differences from simulator to silicon, and a date when a new release / patch will be provided.  This assumes that it is not fixed in a newer version already, of course.

Regards,

Brian Sellner
Sr. Technical Manager
Honeywell Aerospace
11100 N. Oracle Rd.
M/S M124
Tucson, AZ 85737
(520) 469-5227 - Office

Brian,

I can see why this would be of significant concern to you.  Is your certification process tied to the simulator or is it something that can be run on hardware?  The F28x simulator is something that is being phased out and is not actively maintained.  For F28x instead the low cost development boards are recommended instead.

Regards,

John

We are tied to the simulator in some regards.  Switching to real hardware for all of our detailed tests posses some problems.

To be honest, I find it a bit concerning that TI is phasing out support of a simulator for a part you still sell to customers. 

We will discuss more internally to see if there are other ways to address this problem.  In the mean time, can we at least get a detailed analysis of the problem and the differences that will be seen from hw to simulator?  Also, I would like you to see if this is something that can be corrected as a patched version for us, with minimal impact on your side.  It would not have to be a formal version, as we could configure it internally.  Hopefully that would be a happy medium.

Brian, John,

My apologies - I just noticed the 2812 comment.

In my initial assessment I did not notice that this was for a fixed-point device (2812).  I tried the code with the fpu32 extensions enabled and a floating-point device.  

I have rerun the code without fpu32 and the results were the same as the original post as shown below.

We will need to investigate this a bit further.

Hi Lori,

 We are a bit off track here.  Let me reiterate our problem so we are all on the same page.  We are using Code Composer Version 3.3.38 to execute simulator test of our software.  In doing so, we discovered that the value of FLT_EPSILON defined in the Code Composer file Float.h is incorrect.  We believe the value should be '5.96046444E-08F.   We would like to know if you agree with our assessment or do you think we are incorrect.  In addition to this we would like you to provide rational used for by TI in determing the value of FLT_EPSILON in Code Composer.

Tim Kimble

We would like to know if you agree with our assessment or do you think we are incorrect.

You are incorrect.

Tim Kimble

In addition to this we would like you to provide rational used for by TI in determing the value of FLT_EPSILON in Code Composer.

I’ll start with the ANSI standard definition for FLT_EPSILON.

The difference between 1 and the least value greater than 1 that is representable in the given floating type.

Side note on standards …  As described in http://processors.wiki.ti.com/index.php/TI_Compilers_and_Industry_Standards, the TI compiler adheres to the C89 standard.  That standard is not generally available online.  The C99 standard is generally available online.  The definition of FLT_EPSILON is identical in the two standards.

So, the definition of FLT_EPSILON depends entirely on the floating point representation used, and nothing more.  Ignore rounding modes, accuracy, etc.  Thus, it is better to work this problem through in terms of the underlying representation.  Directly consider the binary digits used to represent that value.

The next paragraph presumes you understand computer floating point representation, and you have good familiarity with the IEEE 754 standard for it.

The TI compiler (and every other C compiler I know of) uses 32-bit IEEE 754 representation for the type float.  In that representation, here are the bits (written with hex) for the value 1.0: 0x3f800000.  The last 23 bits are the mantissa.  To get the next representable value, just add 1 to that mantissa.  So, the next representable value is: 0x3f800001.  Note the last hex digit changes from 0 to 1.  What is the floating point value for that set of bits?  Much fun math skipped over here gives you … 1.0000001192092896.  Subtract 1 from that, and you have FLT_EPSILON.

Because this is based on representation, and every compiler I’ve seen uses 32-bit IEEE 754 for float, it stands to reason that other compilers would have the same value for FLT_EPSILON.  And indeed they do.  My laptop has gcc version 3.4.4, and it uses 1.19209290e-7F.  My MSVC version 9 uses 1.192092896e-07F.

Thanks and regards,

-George