I've gotten by that assertion. The resulting interface could be more clear, but it works for now. I pass None as the freq_count and it calculates it from repetition_samples to hold a single repetition. 0613 The next assertion appears to be because the inversion of the 1-1 to matrix is pseudo. This is because the matrix is not square: it is 9x16 because it contains only the frequencies for real-valued data, but for 16 samples. This is the next confusion to make rational! It made a 9x16 matrix, which is likely a subregion of the 16x16 matrix it was making before. I'm thinking of the number of unknowns and vlaues contained in there, and how the sinusoids are complex and basically 2-valued, and thinking it should expand the frequencies to 16x16. 0618 What is the user interface? For a real inverse transform, we pass a short vector of frequency data, and receive a long vector of time data. . So there should indeed be a rectangular matrix. Then, for a real forward transform, we pass a long vector of frequency data, and receive a shor vector of time data. So there should again indeed be a rectangular matrix. Then for the internals, I'm thinking that the current wavelet() function is not quite matching what would be used for an rfft. In np.fft.irfft, the result is the same as for the complex fft, as if the positive and negative frequencies were summed. I think? I can maybe add a bunch of asserts that the two generate the right things. 0623 I mutated some asserts to test this. Gotta get that real-domain transform to be the same as numpy's. 0629 I mutated more asserts and am narrowing down the issue. I'm sending this to help my feelings sort out the layout of spam on this list a little bit.