Time scaling in HarmonyIFS seems wrong

[gogins]

The idea is actually starting to work! However, as time increases, the intervals between events that should be equal seem to increase.

• [x] Proofread JavaScript code versus C++ code. Seems the same except for matrix storage order.
• [x] Investigate matrix storage order.
• [x] Investigate point and transformation const correctness.
• [x] Proofread my code versus the mathematics in my draft paper.
• [x] Proofread the mathematics in my draft paper versus the mathematics in my source papers. Found the problem. On each row of the transformation matrix there are additional scaling terms that I missed by not reading far enough in my source paper.... As a result, there is insufficient contraction of time when applying those rows. Barnsley-Heglund-Massopust-2016-Self-Referential_Functions.pdf Manousopoulos-Drakopoulos-Theoharis-2008-Curve_Fitting_by_Fractal_Interpolation.pdf

[gogins]

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.

[gogins]

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.

[gogins]

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.

[gogins]

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.

[gogins]

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.