You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should be able to fit a Fourier series with more than one period. This is going to break API backwards compatibility pretty badly, and change some of the command line options. Although most previous command line behaviour should not be difficult to achieve by default.
Library Changes
(almost) Any place we pass a single period, we should now accept either a single period, or a 1 dimensional array-like of periods.
The Fourier.design_matrix function must now return a generalization of the design matrix for any number of periods. In the special case of 1 period, it will simplify to the current behaviour
This should also now take times instead of phases, as they need to be phased by a different period in different parts of the matrix
Command Line Changes
The --period command line argument, which takes a float, should now be replaced with a --periods command line argument, taking 1 or more floats.
The --parameters file should now, instead of looking for the column labeled "Period", look for any column prefixed with "Period" and suffixed with a number.
Somehow impose a consistent ordering on them, either by enforcing that they be followed by an integer (probably the simplest, especially when considering the output table), or some more general rule.
We need to support NaNs as representations of missing periods, as some stars may have more periods than others. _process_star may just have to drop the NaNs, although that may cause inconsistencies between input/output tables if there are NaNs in-between two periods for some stars.
Overarching Changes
We need to fundamentally reconsider how we handle phased plots, as multi-periodic stars cannot be phased, but we need an approach which can generalize the current behaviour of phasing singly periodic stars
Printing fitted magnitudes in the output table will have to be off by default, as it is problematic when considering the number of points needed for a multiperiodic star
The text was updated successfully, but these errors were encountered:
I wanted to add an update, since we're finally making progress on multiple period support.
As of 6819788, Fourier coefficients are being output in a way which is compatible with multiple periods. The current output is actually identical to the special case of single periods, once multiple period support is added. The format is
k
A_k
Phi_k
dA_k
dPhi_k
0
A_0
Phi_0
dA_0
dPhi_0
...
...
...
...
...
n
A_n
Phi_n
dA_n
dPhi_n
In the case of multiple periods, we will simply have multiple k columns, i.e. k_1, ..., k_p.
We should be able to fit a Fourier series with more than one period. This is going to break API backwards compatibility pretty badly, and change some of the command line options. Although most previous command line behaviour should not be difficult to achieve by default.
Library Changes
Fourier.design_matrix
function must now return a generalization of the design matrix for any number of periods. In the special case of 1 period, it will simplify to the current behaviourtime
s instead ofphase
s, as they need to be phased by a different period in different parts of the matrixCommand Line Changes
--period
command line argument, which takes a float, should now be replaced with a--periods
command line argument, taking 1 or more floats.--parameters
file should now, instead of looking for the column labeled"Period"
, look for any column prefixed with"Period"
and suffixed with a number.NaN
s as representations of missing periods, as some stars may have more periods than others._process_star
may just have to drop the NaNs, although that may cause inconsistencies between input/output tables if there areNaN
s in-between two periods for some stars.Overarching Changes
The text was updated successfully, but these errors were encountered: