Hi

I'm pretty new around here, but I have a question.

I'm trying to create a calculation to predict sunrise and sunset times for any point on earth, but I'm having some strife with the numbers.

When I use the following calculation:

MeanEclLongSun + 1.915 * (Sin (Radians (meanAnom))) - (.02 * (Sin (Radians (meanAnom * 2))))

I end up with a result which differs from the same calculation performed on a scientific calculator. Now this is curious, since individual calculation of:

1.915 * (Sin (Radians (meanAnom)))

works perfectly. More complex calculation, though, throws a different answer. For example,

.02 * (Sin (Radians (meanAnom * 2)))

yields the result 0.007750955, while the calculator comes up with 7.906977972343e-3. There is a difference of 0.000156022. This difference magnifies as further calculation is performed as above. It's a very fine difference, but it throws sunrise and sunset out by minutes.

The calculator accords with almanac times, the FMP calculations do not. I am out of my mathematical depth here. I wonder if the order I have used in my equations is subtly wrong, or is it FMP's rounding error?

Steve

Just an addendum to the above for the purposes of working the equation:

assume values of

MeanEclLongSun = 292.411 and

meanAnom = 11.401

These actually represent degree values, but since they are in decimal form I am only using them as numbers. Perhaps this contributes to the problem?

I am guessing you are facing a problem with the limits of floating-point arithmetics. Hard to say for certain with such a complex example, and without access to an alternative computing device such as your calculator.

I'd suggest you break up your calculation into smaller pieces and find the first step where FMP disagrees with your calculator. Then check the same step using the OS X calculator. That should tell you if the problem is FMP-specific or computer-wide.

I tried with PCCalc2 on my mac.

   Sin( 22.802 degrees ) = .3875477663

according to it.

That leads to the value .0077509553, I tried multiplying the .02 manually, and got .007750955306, so if anything is incorrect it must be the Sin of this number is off?

Ah, when you put it like that, it's much clearer. This doesn't look like a rounding error. The difference is too large (about half degree, I think). And the sine of 22.8 degrees *is* 0.3875 according to any source I could think of - including a printed reference table from pre-computer days.

You might want to try wrapping the whole calculation with a SetPrecision call, just to see if that helps with the Radian conversion being more accurrate.

SetPrecision( ; 50 )

Otherwise, I'm stumped why it would be off by so much.

I'm afraid that won't work - trigonometric functions do not support extended precision. Besides, SetPrecision() only extends the precision - here we have a discrepancy within the "normal" precision.

The Radians function involves multiplying by Pi (internally), which is affected by SetPrecision.

Trying these out on FM 8.5, I get:

    Radians(20) = .3490658503988659

    SetPrecision( Radians(20); 30 ) = .349065850398865915384738153698

I doubt this would lead to such a large error, but I thought it was worth a shot.

Thanks very much for your help. I have now tried using the calculator, manual calculation and FMP and I am getting much better agreement. I'm guessing that the way I entered the info on the calculator changed the result slightly.

I'll go away and keep plugging, but when I see large maths calcs like this, all the springs fall out of my head, so I may be back...

Much obliged for your time

Steve

No, it cannot be a matter of precision. Your final result was 0.00775 instead of OP's 0.00791. Reverse that and you get:

0.00791 / 0.02 = 0.3955

as the (supposed) sine of 22.8 degrees. But 0.3955 is the sine of 23.3 degrees (type "asin(0.3955) in degrees" into Google's search box). The error must be somewhere else.