Closed gogins closed 3 years ago
In Eigen3 the storage order is by default column major.
Neither in code nor in documentation does numeric.js state the storage order. However, the pretty print function and examples imply that the storage order is row major. My JavaScript code also assumes that the storage order is row major (row vectors).
Exchanging row with column indexes in my test piece simply produces one long chord, so that can't be right.
What is the storage order presumed by the math in my paper? I have the bottom row as zeros except for the final column. Looks correct.
Found a few typos but the exact same problem remains.
This may be of interest: https://www.jstor.org/stable/3681302?origin=crossref&seq=1.
I suspect an error in the math of my source.
I think the problem may be affine transformations numbered from 1 but interpolation points numbered from 0 in the source paper, so a fencepost error in my code.
I still do not see the cause of this time scaling problem.
However, reviewing the code and math has made my understand that the project is somewhat ill-formed. It really only makes sense to use a fractal interpolation function to compute an actual graph of an actual function, meaning that to the PIT group I currently am using should be added not only V, but perhaps also instrument choice and loudness.
In addition, not recursing to the error limit kind of breaks the idea.
I am closing this issue for the time being and perhaps permanently.
Reopening because I couldn't leave it alone. Fixed.
The problem was I was not copying the iterated point from the previous iteration for each transformation in the current iteration.
The idea is actually starting to work! However, as time increases, the intervals between events that should be equal seem to increase.