[ot][spam][random][crazy][random][crazy]

[Undescribed Horrific Abuse, One Victim & Survivor of Many]

2022-11-17
1038

1047

i'm poking at it, and running into a complexity trying to make an
effective freq2time matrix.

for a matrix to work on its own, it functions by multiplying the
positive frequencies. the larger matrix has parts that multiply the
negative.
the negative frequencies have data that is the complex conjugate of
the data associated with the positive frequencies.

so, if there were a function, it would be simple to kludge it by
copying the data and taking its conjugate.
but i'm not immediately sure how to make a matrix that performs the
complex conjugate operation on its input.

y'know, i could find that quickly by simply solving for it.
1049
of course it could be true, maybe even quite likely, that a general
complex conjugate is not a linear operation.

if y is the complex conjugate of x
and we consider, is there a matrix where y = x @ M or M @ x
then ... uh .... ok the np linalg functions i am presently used to all
take an existing matrix. they don't operate on just two vectors.

the simplest solution is to use a function rather than a matrix, or to
ignore the half-sized real-domain matrices for now.

reminder: the issue demonstrates via the difference between
multiplying the conjugate data by the matrix for the negative
frequencies, and multiplying the non-conjugate data by the negative of
the same. it possibly or likely appears that for the sinusoid, the
negative functions as if the conjugate were on the left, whereas this
is not true for the step wave.

it would make sense to go down to a smaller scale; to consider one
differing value
1058
basically my internal considering goes off in the opposite direction
of use, so looking at it helps a ton.

(Pdb) p pos_freqs, neg_freqs
(array([0.46428571]), array([-0.46428571]))
(Pdb) p pos_freq_data, neg_freq_data
(array([0.05144037-0.04259059j]), array([0.05144037+0.04259059j]))
(Pdb) p offset
array([27])

138  ->         mat[head_idx:tail_idx,:] += complex_wavelet(wavelet,
np.outer(-freqs[head_idx:tail_idx], offsets))

(Pdb) p (neg_freq_data @ complex_wavelet(COSINE, np.outer(neg_freqs,
offset))).round(3)
array([-0.06-0.03j])
(Pdb) p (pos_freq_data @ complex_wavelet(COSINE, np.outer(neg_freqs,
offset))).round(3)
array([-0.041+0.053j])

Even with the cosine, the result of multiplying the conjugate by the
negative frequencies is different than multiplying the non-conjugate.
The fact that so many assertions are passing implies that this is
somehow made up for by a similar countering multiplication elsewhere.

considering +- b and +-d
(a + bi) * (c + di) = ac + bci + adi - bd = ac - bd + (ad + bc)i

so then we have
ac - bd + adi - bci = X * (ac - bd + bci - adi)

not that confident around that, ummm
the sign of "a" impacts both "ac" and "ad"
so if I want the sign of "ad" to change, then _either_ "a" _or_ "d"
must change in sign
if i don't want ac and bd to change, then either a-and-c or d-and-b
must change in sign
given both conditions rely on elements from both sides of the original
multiplication (a + bi) * (c + di), i can conclude that it is
unreasonable to assume i could find a real constant that would
multiply only one of them to make the conjugate of the result.

the inference is that with the cosine, there are further frequency
values that balance the sum out so it still becomes correct

1134
i ran this test and i did not find the balancing to happen; i may have
made a mistake. it would be worthwhile checking a passing assert.
(Pdb) p (np.concatenate([extended_freq_data[1:14],
extended_freq_data[15:]]) @ complex_wavelet(COSINE,
np.outer(np.concatenate([extended_freqs[1:14], extended_freqs[15:]]),
offset))).round(3)
array([-0.585+0.j])
(Pdb) p (freq_data[1:14] @ (complex_wavelet(COSINE,
np.outer(extended_freqs[1:14], offset)) + complex_wavelet(COSINE,
np.outer(extended_freqs[15:], offset))) ).round(3)
array([0.+0.j])

i might have ran out of the mystery of continuing to do this immediately.