Astronomical Routines Tracker

[TestSubjector]

This is an issue to track most of the important astronomical utilities, not present in the package.

• [x] baryvel
• [x] co_aberration
• [x] co_nutate
• [x] co_refract
• [x] ~date~ (covered by AstronomicalTime.jl)
• [x] ~date_conv~ (covered by AstronomicalTime.jl)
• [x] eq2hor
• [x] euler
• [x] helio
• [x] hor2eq
• [x] imf
• [x] ismeuv
• [x] planet_coords
• [x] precess_cd
• [x] uvbybeta
• [x] zenpos ~astdisp~ (pretty printing procedure, unnecessary) ~astro~pretty~ (printing procedure, unnecessary) ~fm_unred~ (requires spline dependency) ~get_coords~ (pretty printing procedure, unnecessary) ~ticlabels~ (labeling and printing procedure)

Additionally, a few of these routines call other procedures, some of which are not there in the package. As AstroLib.jl's functions are not a drop-in replacement of IDL AstroLib's procedures, these 'required' procedures may not be necessary. However they are listed below for reference.

• jplepheard (called by baryvel)
• jplephinterp (called by baryvel)
• tdb2tdt (called by baryvel) ~setdefaultvalue (called by eq2hor)~ (not required)
• cspline (called by fm_unred) ~poly (called by fm_unred)~ (use @evalpoly) ~textopen (called by uvbybeta)~ (not required, simply use println( )) ~textclose (called by uvbybeta)~ (not required, simply use println( ))

[giordano]

Thanks for the list!

Regarding the required functions:

• Ephemeris related functions may be available at https://github.com/JuliaAstrodynamics/JPLEphemeris.jl
• Unfortunately tdb2tdt is proprietary (maybe ERFA.jl has something for that)
• setdefaultvalue is probably unnecessary
• Julia's @evalpoly should be a drop-in replacement of poly
• textopen and textclose may not be necessary (but didn't look thoroughly)

[TestSubjector]

Julia's @evalpoly should be a drop-in replacement of poly

@evalpoly(z, c...) generates code at compile-time so it requires length of c (the coefficients) at that stage only.

One trick that can be used to avoid that is to have something like @eval @evalpoly(z, $(c...)) where eval forces the evaluation of the argument.

textopen and textclose may not be necessary (but didn't look thoroughly)

Yeap, not required. Just listing for reference.

[giordano]

@evalpoly(z, c...) generates code at compile-time so it requires length of c (the coefficients) at that stage only.

Yes, but in fm_unred the coefficients are known.

[TestSubjector]

Yes, but in fm_unred the coefficients are known.

Not in ismeuv though. (for some reason the poly procedure was not listed as a dependency there)

[giordano]

The c1 and c2 vectors in ismeuv are constant, aren't they?

[TestSubjector]

The c1 and c2 vectors in ismeuv are constant, aren't they?

My bad. Got confused a bit regarding how @evalpoly works.

The main problem I was having was with regards to the coefficient's length julia> d = [1,2,3] julia> @evalpoly(4, d) ERROR: BoundsError: attempt to access (:d,) at index [0] julia> @evalpoly(4, d...) ERROR: BoundsError: attempt to access (:(d...),) at index [0]

However, inserting the coefficients as literal works julia> @evalpoly(4, d[1], d[2], d[3]) 57 Reference: https://stackoverflow.com/questions/28077057/julia-evalpoly-macro-with-varargs

[giordano]

Yes, you can't splat an iterable in a macro call, because at compile time it's a single expression.

You don't even need to allocate a useless array, just do

julia> @evalpoly 4 1 2 3
57

If the length of the coefficient vector is known when you write down the code, @evalpoly is extremely efficient.

[helgee]

Everything date-related should be covered by AstronomicalTime.jl.

[giordano]

All listed functions have been ported, we can close this. Thanks for your work @TestSubjector!