0458 ! Where I left off yesterday, after giving complex phase to my square wave, the matrix looks better, but there are still components that aren't conjugates. (Pdb) p inverse_mat[:,6] array([-0.0625-0.0625j, 0.0625-0.0625j, -0.0625+0.0625j, -0.0625-0.0625j, 0.0625-0.0625j, -0.0625+0.0625j, -0.0625-0.0625j, 0.0625+0.0625j, -0.0625-0.0625j, 0.0625-0.0625j, -0.0625+0.0625j, -0.0625-0.0625j, 0.0625-0.0625j, -0.0625+0.0625j, -0.0625-0.0625j, 0.0625+0.0625j]) (Pdb) p freqs array([ 0. , 0.0625, 0.125 , 0.1875, 0.25 , 0.3125, 0.375 , 0.4375, -0.5 , -0.4375, -0.375 , -0.3125, -0.25 , -0.1875, -0.125 , -0.0625]) It looks to me like the first component that isn't a conjugate when negated is frequency 0.25 . 0.25 makes 0.0625-0.0625j, whereas -0.25 makes 0.0625-0.0625j: the two values are the same. I've likely made this situation by having a function that doesn't produce the property. The 0-offset sample shows it much easier: (Pdb) p inverse_mat[:,0] array([-0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j]) It looks like it has no conjugates at all. (Pdb) p create_freq2time(time_count, freqs, SINE)[:,0] array([0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j, 0.0625+0.j]) (Pdb) p create_freq2time(time_count, freqs, SQUARE)[:,0] array([-0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j, -0.0625-0.0625j]) My square wave never outputs a 0 value, so it is impossible for it to match its complex conjugate at time=0, which has no negative. This likely happens again at time=1, time=2, etc. (Pdb) p complex_wavelet(SQUARE, np.array([0,0,1,-1,2,-2])) array([-1.-1.j, -1.-1.j, -1.-1.j, -1.-1.j, -1.-1.j, -1.-1.j]) They're all equal, with no conjugates at all! Thinking about this a little. - i could change the wave so its minimum is 0, but then it would not make negative conjugates unless i also negated the whole wave when negative - i could make the wave a step wave that touches 0, 1, and -1, but then it wouldn't be square any more - i could also interpret the whole transform a little differently, like i did to make the matrix supporting off-frequencies in the first place, to facilitate this I'm thinking that negating the wave when it is negative would match the behavior of sine. I'm accumulating the properties of the cosine wave that let it get replaced by other functions. - even i.e. f(x) == f(-x) - zero at 90 degrees f(0.25) == 0 - negative at 180 degrees f(0.5) == -f(0) Given my current complex wavelet function is taking the modulus of x to be near zero, if I made an odd-function square wave that had a base of 0 at 0 and hit +1 at t>0 and -1 at t<0, this could be considered equivalent to a 3-valued step wave, in some way, since x would loop, or I could stop looping x. 0545 Instead of a square wave, I'm just using STEP = lambda x: COSINE(x).round() . This significantly reduces the changes I need to comprehend. I'm thinking what's notable for the real-domain forward matrix, is the frequencies need to be reconstructible from only half of them. At the moment, that means that the second half _of the actual frequency data_ must be the reversed complex conjugates of the first half. A simpler approach to this could have been to not use complex numbers at all, and instead break data into two separate values. Then it would be obvious how to engage real-domain data: you'd just remove the complex data. 0557 The assertion is still failing, but the frequencies look correct: (Pdb) p (randvec @ create_time2freq(freqs=fftfreq(complex = True, repetition_samples = 16), wavelet=STEP)).round(2) array([ 9.13-0.j , -1.17+0.32j, 0.24-0.7j , -0.43-1.37j, 0.6 -0.62j, 0.16-0.9j , 0.8 +1.07j, -0.22+0.21j, -0.32+0.j , -0.22-0.21j, 0.8 -1.07j, 0.16+0.9j , 0.6 +0.62j, -0.43+1.37j, 0.24+0.7j , -1.17-0.32j]) (Pdb) p (randvec @ unextracting_ft).round(2) array([ 9.13-0.j , -1.17+0.32j, 0.24-0.7j , -0.43-1.37j, 0.6 -0.62j, 0.16-0.9j , 0.8 +1.07j, -0.22+0.21j, -0.32-0.j ]) The problem now must be in the inverse transform matrix, which is simpler. For some reason the real frequency data is still retaining imaginary components: (Pdb) p ((randvec @ unextracting_ft) @ extracting_ift).round(2) array([0.55-0.25j, 0.4 -0.21j, 0.34+0.43j, 0.74+0.28j, 0.5 -0.12j, 0.59+0.16j, 0.61-0.27j, 0.64-0.24j, 0.96+0.19j, 0.64-0.24j, 0.61-0.27j, 0.59+0.16j, 0.5 -0.12j, 0.74+0.28j, 0.34+0.43j, 0.4 -0.21j]) (Pdb) p randvec.round(2) array([0.55, 0.72, 0.6 , 0.54, 0.42, 0.65, 0.44, 0.89, 0.96, 0.38, 0.79, 0.53, 0.57, 0.93, 0.07, 0.09]) 0614 I'm here; it's a small and closed system: 126 if not is_complex: 127 has_nyquist = bool(freqs[-1] == 0.5) 128 head_idx = 1 if has_dc_offset else 0 129 tail_idx = len(freqs) - (1 if has_nyquist else 0) 130 131 # todo: remove test data 132 full_mat = complex_wavelet(wavelet, np.outer(np.concatenate([freqs, -freqs[head_idx:tail_idx][::-1]]), offsets)) 133 time_data = np.random.random(full_mat.shape[1]) 134 extended_freq_data = time_data @ np.linalg.inv(full_mat) 135 freq_data = extended_freq_data[:len(freqs)] (Pdb) 136 import pdb; pdb.set_trace() 137 138 mat[head_idx:tail_idx,:] += complex_wavelet(wavelet, np.outer(-freqs[head_idx:tail_idx], offsets)) 139 -> mat = mat.real full_mat @ extended_freq_data == time_data correctly. However, mat @ freq_data adds imaginary components to the output. They are no longer canceling. I don't yet understand why this is, given the same parts (-freqs[head_idx,tail_idx]) are summed into the output. 0622 So, like before, I imagine a thing to do is drilling down into the matrix construction. I'll consider sample 6. 0.46147936225293185 (Pdb) p full_mat[:,6].round(3) array([ 1. -0.j , 0.223+0.975j, -0.901+0.434j, -0.623-0.782j, 0.623-0.782j, 0.901+0.434j, -0.223+0.975j, -1. +0.j , -0.223-0.975j, 0.901-0.434j, 0.623+0.782j, -0.623+0.782j, -0.901-0.434j, 0.223-0.975j, 1. -0.j , 0.223+0.975j, -0.901+0.434j, -0.623-0.782j, 0.623-0.782j, 0.901+0.434j, -0.223+0.975j, -1. +0.j , -0.223-0.975j, 0.901-0.434j, 0.623+0.782j, -0.623+0.782j, -0.901-0.434j, 0.223-0.975j]) (Pdb) p (extended_freq_data @ full_mat[:,6]).round(3) (0.461-0j) (Pdb) p time_data[6].round(3) 0.461 0635 So. Every item in that column #6, is multiplied by every frequency, and they are summed. As far as I know, that's what the code is already reproducing, so there is something I'm conceiving wrongly going on here (as is often the case). I'll start by checking the top portion. The mat that's failing is made with these 2 lines: 125 mat = complex_wavelet(wavelet, np.outer(freqs, offsets)) 138 mat[head_idx:tail_idx,:] += complex_wavelet(wavelet, np.outer(-freqs[head_idx:tail_idx], offsets)) I'll check the top portion first. 0643 I failed to negate the nyquist frequency and found that the output differed because of this: (Pdb) p (extended_freq_data[:len(freqs)] @ full_mat[:len(freqs),6]).round(3) (0.458+0.004j) (Pdb) p (extended_freq_data[:len(freqs)] @ np.outer(freqs, offsets)[:len(freqs),6]).round(3) (-0.494-0.42j) (Pdb) p (extended_freq_data[:len(freqs)-1] @ np.outer(freqs, offsets)[:len(freqs)-1,6]).round(3) (-0.209-0.42j) (Pdb) p (extended_freq_data[:len(freqs)-1] @ np.outer(freqs, offsets)[:len(freqs)-1,6]).round(3) (-0.209-0.42j) Inspecting the source code, it looks like I am also failing to negate the nyquist frequency there, too. I tried inverting it and it still does not pass. 0648