Incorrect calculation result

[Mantas]

Hello support,

I have a problem with one macro. It is calculating incorrectly parameter julian_day. It is returning a value of 2452930.25, where it should return a value of 2452930.312847. The first part day_frac calculates ok, and returnes a value of 17.812847, and the second part floor(365.25*(year+4716.0)) + floor(30.6001*(month+1)) is returning a value of 2454450. Up to this point it is ok, then it adds and subtracts as follows:
2454450+17.812847-1524.5 which should result in 2452943.312847, right? But instead it returns a value of 2452943.25 Why

P.S. on the third step it subtracts -13, su end result should be 2452930.312847.

Here is the program:

jd.fcf_arm

Example of julian day

(15.59 KiB) Downloaded 378 times

Please help fix this program.

Best regards,
Mantas

[Mantas]

I think it is the same 6 digit precision problem. If I floor() and divide the jd /1000.0 before adding and subtracting the day_dec and 1524.5 it returns the correct fraction .3128...and not .25...

I am really waiting for that update to 15 digit precision. My program is working correctly, just this precision is causing the delay in completing my project.

Best regards,
Mantas

[JonnyW]

Hello. The problem is the values range is exceeding the 24-bit limit of a float, cutting off the lower bits. Is this the same problem when downloaded? The downloaded ARM stuff should use doubles - see the definition in internals.c of MX_FLOAT.

Simulation in v5.3 ARM uses floats (single precision). I have modded this in v5.4 to use doubles instead so your calculation is more accurate.

We are currently preparing the build and testing for PIC v5.4 and if this is successful we will be rolling out an ARM update too.

I think I remember having an integer-only date to MJD floating around at home somewhere, anyway. If it is not reliant on 64-bit arithmetic I might be able to create a FC macro for this for you. Wont be today I'm afraid as the code is at home. I'm not 100% sure I have something suitable, it may calculate the fractional part separately.

Cheers,

Jonny

[Mantas]

Hello Jonny,

Yes, when downloaded it is also giving the same .25 at the end. I am using gcvt() function to display it on LCD, and I cant simulate it, I only see the results on my hardware. Just as a side note, I think a lot of my variables in my calculations is exceeding 24 bit value, but ARM is 32 bit, so it should be ok. The thing is that this julian day parameter is the base and beginning of all my calculations, and if this is not correct then all of my calculations are going nowhere. For example, if this fraction is .25 and not 0.31 then later I get one parameter 295 degrees instead of 318 which is 23 degrees error... and 23 degrees error is not very good for tracking sun's position for CSP applications. Ok Jonny, I hope you can help me out in some way

Cheers,
Mantas

[JonnyW]

Hi. Yeah, ARM is 32 bit, but so are the 24 bit floats.

A floating point number is just an integer with a special format. 1 bit is set aside for the sign (s) of the value, 7 buts are the exponent (e), and 24 bits are the mantissa (m). The cpu works the value out as s * m * (1 << e)

In a double-width precision float the float takes 64 bits, 52 bits of which are set aside for the mantissa.

If the range from the highest to lowest bits of the mantissa exceed the allocated space, the bottom bits are cut off.

Find the file <flowcode directory>\v5\CAL\ARM\ARM_CAL_TypeDefs.c and open it in a text editor. Line 47 has the code:

Code: Select all

typedef float          MX_FLOAT;  // In BoostC, needs '#define MX_FLOAT float'

Change this to:

Code: Select all

typedef double         MX_FLOAT;  // In BoostC, needs '#define MX_FLOAT float'

This will cause Flowcode to use double-with precision.

Note I have not tested this and there may be issues but the AVR and dsPIC builds have this defined as double so I think the ARM was just an oversight. Let me know if this works as expected and I'll ensure this filters into the next ARM release.

Cheers,

Jonny

[Mantas]

Hello Jonny

If you were a girl I would say I love you But now I'll just say that I own you a pint of beer You are my savior! It is working perfectly now! precise to the last bit, as it should be! Big thanks from me, and the case is closed. No more truncated floating point numbers. I am very happy! Now I can move on with my project

Cheers,
Mantas

[JonnyW]

Excellent, glad that was a help! And with your new system you're on the way to finding the nearest pub for that pint!

Jonny