Open
Conversation
Member
|
This looks cool but I don't have a strong opinion on the best way to do this -- I'll need to think on it a bit... |
Member
|
(Note: this should not be a 0.1 blocker) |
Member
|
@bmorris3 – Merge conflicts, please rebase. |
67d616a to
1cb4468
Compare
Member
Member
|
@bmorris3 - the milestones need a little bit of cleanup ;) |
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Here take a first crack at the
NonFixedTargetobject.My goal was to forge ahead towards a
NonFixedTargetframework that is flexible enough to easily build on top of. ThisNonFixedTargetis a wrapper around some arbitrary function supplied by the user that returnsSkyCoords for the target at various times (and/or locations, pressures, temperatures, etc.). The various incarnations of a particularNonFixedTarget, at different times for instance, are accessed with theatmethod, like so:The flexibility of the
atmethod is clearer for ourget_moonmethod, which requires a location and pressure,or alternatively, if the site and pressure always remain the same and only the time changes, that can be specified in the
constant_kwargskeyword argument and theatmethod can be called with only a time.(right now, this won't actually work for my current implementation of
get_moon, but this is the idea).My primary motivation for starting the branch is for solar system objects, which I'm currently implementing with
NonFixedTargets in a different branch, to operate like this:Tell me why this is a bad idea – I'm sure there are reasons.