Generator embedding optimization: Difference between revisions

Line 7,986:

We've now reached the point where Keenan's original version of this algorithm would solve directly for <math>𝒃</math>, analogous to how it solves directly (and approximately) for <math>𝒈</math> in the first iteration. But when we use the matrix inverse technique — where instead of solving directly (and approximately) for a generator tuning map <math>𝒈</math> we instead solve exactly for a generator embedding <math>G</math> and can then later obtain <math>𝒈</math> as <math>𝒈 = 𝒋G</math> — then here we must be solving exactly for some matrix which we could call <math>B</math>, following the analogy <math>𝒈 : G :: 𝒃 : B</math>. (Not to be confused with the subscripted <math>B_s</math> that we use for [[Domain_basis#Basis_matrix_conversion|basis matrices]]; these two matrices will probably never meet, though). This will be a <math>(d, τ-1)</math>-shaped matrix.

We've now reached the point where Keenan's original version of this algorithm would solve directly for <math>𝒃</math>, analogous to how it solves directly (and approximately) for <math>𝒈</math> in the first iteration. But when we use the matrix inverse technique — where instead of solving directly (and approximately) for a generator tuning map <math>𝒈</math> we instead solve exactly for a generator embedding <math>G</math> and can then later obtain <math>𝒈</math> as <math>𝒈 = 𝒋G</math> — then here we must be solving exactly for some matrix which we could call <math>B</math>, following the analogy <math>𝒈 : G :: 𝒃 : B</math>. (Not to be confused with the subscripted <math>B_s</math> that we use for [[Domain_basis#Basis_matrix_conversion|basis matrices]]; these two matrices will probably never meet, though). This will be a <math>(d, τ-1)</math>-shaped matrix, which we could call the '''blend matrix'''.

And this is why we noted the thing earlier about how constraint matrices are about identifying tunings, not optimizing them. If you come across this setup, and see that somehow, for some reason, <math>𝒓_0</math> has replaced <math>𝒋</math>, you might want to try to answer the question: why are we trying to optimize things relative to some arbitrary retuning map, now, instead of JI? The problem with that is: it's the wrong question. It's not so much that <math>𝒓_0</math> is a goal or even a central player in this situation. It just sort of works out this way.

Revision as of 19:00, 31 January 2023 view source Cmloegcmluin (talk \| contribs) autopatrolled, emailconfirmed 5,160 edits →How to identify tunings ← Older edit		Revision as of 19:03, 31 January 2023 view source Cmloegcmluin (talk \| contribs) autopatrolled, emailconfirmed 5,160 edits →How to identify tunings Newer edit →
Line 7,986:		Line 7,986:


	We've now reached the point where Keenan's original version of this algorithm would solve directly for <math>𝒃</math>, analogous to how it solves directly (and approximately) for <math>𝒈</math> in the first iteration. But when we use the matrix inverse technique — where instead of solving directly (and approximately) for a generator tuning map <math>𝒈</math> we instead solve exactly for a generator embedding <math>G</math> and can then later obtain <math>𝒈</math> as <math>𝒈 = 𝒋G</math> — then here we must be solving exactly for some matrix which we could call <math>B</math>, following the analogy <math>𝒈 : G :: 𝒃 : B</math>. (Not to be confused with the subscripted <math>B_s</math> that we use for [[Domain_basis#Basis_matrix_conversion\|basis matrices]]; these two matrices will probably never meet, though). This will be a <math>(d, τ-1)</math>-shaped matrix.		We've now reached the point where Keenan's original version of this algorithm would solve directly for <math>𝒃</math>, analogous to how it solves directly (and approximately) for <math>𝒈</math> in the first iteration. But when we use the matrix inverse technique — where instead of solving directly (and approximately) for a generator tuning map <math>𝒈</math> we instead solve exactly for a generator embedding <math>G</math> and can then later obtain <math>𝒈</math> as <math>𝒈 = 𝒋G</math> — then here we must be solving exactly for some matrix which we could call <math>B</math>, following the analogy <math>𝒈 : G :: 𝒃 : B</math>. (Not to be confused with the subscripted <math>B_s</math> that we use for [[Domain_basis#Basis_matrix_conversion\|basis matrices]]; these two matrices will probably never meet, though). This will be a <math>(d, τ-1)</math>-shaped matrix, which we could call the '''blend matrix'''.

	And this is why we noted the thing earlier about how constraint matrices are about identifying tunings, not optimizing them. If you come across this setup, and see that somehow, for some reason, <math>𝒓_0</math> has replaced <math>𝒋</math>, you might want to try to answer the question: why are we trying to optimize things relative to some arbitrary retuning map, now, instead of JI? The problem with that is: it's the wrong question. It's not so much that <math>𝒓_0</math> is a goal or even a central player in this situation. It just sort of works out this way.		And this is why we noted the thing earlier about how constraint matrices are about identifying tunings, not optimizing them. If you come across this setup, and see that somehow, for some reason, <math>𝒓_0</math> has replaced <math>𝒋</math>, you might want to try to answer the question: why are we trying to optimize things relative to some arbitrary retuning map, now, instead of JI? The problem with that is: it's the wrong question. It's not so much that <math>𝒓_0</math> is a goal or even a central player in this situation. It just sort of works out this way.