tags:

views:

64

answers:

1

The cod that I am using contains these snippets of code. I am calling ThetaG_JD with the argument 2455343.50000 which is just a sample Julian date. Every time I run the program, I receive a EXC_BAD_ACCESS on the indicated line. When using gdb and printing out the intermediary values and passing them through the floor function, I get no error, but when Frac() is used it always returns an error.

double Frac(double arg)
{
    /* Returns fractional part of double argument */
    return arg - floor(arg);
}

double ThetaG_JD(double jd)
{
    /* Reference:  The 1992 Astronomical Almanac, page B6. */

    double UT=0, TU=0, GMST=0;
    //THIS LINE
    UT=Frac(jd+0.5);
    // THAT ONE ^^
    jd=jd-UT;
    TU=(jd-2451545.0)/36525;
    GMST=24110.54841+TU*(8640184.812866+TU*(0.093104-TU*6.2E-6));
    GMST=Modulus(GMST+secday*omega_E*UT,secday);

    return (twopi*GMST/secday);
}
+1  A: 

The EXC_BAD_ACCESS is somewhat puzzling to me, but this sounds suspiciously like a floating point exception. It's been a while, but as I recall on x87 hardware, you could generate overflow/underflow/NaN and the processor wouldn't let you know with an exception until the next FP operation which could be in a totally different part of the code. You could try something like jd += 0.5 instead of the call for Frac and see if it still dies.

Also the x87 status register will be able to show you if there's an error state and you should be able to see that within gbd.

Mark B
Upon checking the status registers I did notice there was an error state. I solved this by simply changing the floor function with a cast to an int. It seems to be working as expected.
fastrack20
At least consider investigating how the error state got set in the first place - you may be generating unexpected incorrect results somewhere else that happen to look "good enough".
Mark B
Yes, I am going to investigate this further as when the program terminates, I still return an error.
fastrack20
It seem that the fstat register contains 32. I am not sure what this value means, however.
fastrack20
'Bit five controls whether the precision exception can occur. A precision exception occurs whenever the FPU produces an imprecise result, generally the result of an internal rounding operation. Although many operations will produce an exact result, many more will not. For example, dividing one by ten will produce an inexact result. Therefore, this bit is usually one since inexact results are very common.' from http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/Chapter_14/CH14-3.html
Mark B