Use index types to number polynomials #6
Merged
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.
This is a substantial API change, although it is not a
breaking change as the old API is still supported via
deprecations. The concept is to use three types,
NM
,OSA
, andNoll
, to specify the numberingconvention. The constructor of each checks for
validity, so it is impossible to construct invalid index
values. Then, instead of passing in both an
::Int
andan
index ∈ (:OSA, :Noll)
to lots of functions, thepackage functions are simply implemented in terms
of their preferred index type, and other index types
are supported by conversion.
The advantages of this design are:
Int
).x2y
for conversion means that if you haven
different indexing conventions, you needn^2-n
(quadratic inn
) exported names. But if you use types, you only needn
exported names (linear inn
).This also enhances flexibility, e.g., on
master
specifyingJ = 0:9
forZernikecoefficients
results in an error because that function only takes aVector{Int}
. It also adopts the conventions of the Julia style guide regarding capitalization of names.Finally, to ensure I didn't make breaking changes, I deliberately left the tests the way they were: my editor cleaned up some extraneous spaces, and I added one
convert
test, but all the old tests still pass. If you like this and want to merge it, in a separate PR I will:test/deprecated.jl
fileSome day you can release v0.2 (or v1.0?) of this package, at which point you can strip out all the old deprecations. But having them in place should provide very useful hints for people about how to migrate over to the new API.
CC @jona125