New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Astronomical Routines Tracker #17

Closed
TestSubjector opened this Issue Jun 7, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@TestSubjector
Contributor

TestSubjector commented Jun 7, 2017

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

  • baryvel
  • co_aberration
  • co_nutate
  • co_refract
  • date (covered by AstronomicalTime.jl)
  • date_conv (covered by AstronomicalTime.jl)
  • eq2hor
  • euler
  • helio
  • hor2eq
  • imf
  • ismeuv
  • planet_coords
  • precess_cd
  • uvbybeta
  • zenpos
    astdisp (pretty printing procedure, unnecessary)
    astropretty~ (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

This comment has been minimized.

Member

giordano commented Jun 8, 2017

Thanks for the list!

Regarding the required functions:

@TestSubjector

This comment has been minimized.

Contributor

TestSubjector commented Jun 9, 2017

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

This comment has been minimized.

Member

giordano commented Jun 9, 2017

@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

This comment has been minimized.

Contributor

TestSubjector commented Jun 9, 2017

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

This comment has been minimized.

Member

giordano commented Jun 9, 2017

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

@TestSubjector

This comment has been minimized.

Contributor

TestSubjector commented Jun 9, 2017

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

This comment has been minimized.

Member

giordano commented Jun 9, 2017

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

This comment has been minimized.

Member

helgee commented Jun 12, 2017

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

@giordano

This comment has been minimized.

Member

giordano commented Sep 27, 2017

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

@giordano giordano closed this Sep 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment