Talk:Normal forms: Difference between revisions

re
Cmloegcmluin (talk | contribs)
Line 128: Line 128:


::::::::::: Re: POTE generator(s) line. Problem is the generators in this line in all the temp pages don't consistently come from a certain form. My plan is to regulate them to the equave-reduced generator form. Not related but I'll also revise this line to ''Optimal tuning (POTE)''. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 16:59, 1 October 2021 (UTC)
::::::::::: Re: POTE generator(s) line. Problem is the generators in this line in all the temp pages don't consistently come from a certain form. My plan is to regulate them to the equave-reduced generator form. Not related but I'll also revise this line to ''Optimal tuning (POTE)''. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 16:59, 1 October 2021 (UTC)
:::::::::::: Re: equave-reduced generator form. You had said "In this take ... porcupine's generator is ~10/9 (not ~9/5)." But both 10/9 and 9/5 are octave-reduced (the equave is the octave here). In what way does your definition select 10/9 over 9/5? That's what I was confused about earlier, but this definition you've now shared has not resolved my confusion. Because this is the definition of a normal form, not a canonical form, I understand that it's not necessary that the results be unique; i.e. it might be the case that both 10/9 and 9/5 were options for a equave-reduced generator (normal) form. But you specifically claimed that 9/5 did not qualify, and I expect you do wish for this form to uniquely identify. So maybe there's something about your definition that I'm missing, that should be included explicitly.
:::::::::::: Re: names. The job of a name is not to unambiguously and completely specify the thing it names; sure, "equave-reduced" wasn't enough to convey the entire definition of that form to me, but I wouldn't expect it to have done that. So a name shouldn't contain ''all'' the information about a thing, but a name does a good job if it contains ''some'' of the most important info about it. For a newcomer, "product complexity" vs "Benedetti height" have the same cost: there's not enough information in either name to understand the thing, so you must look it up to learn it. But in the case of people like me who have already learned the thing but, say, use it only once every couple months or something, "product complexity" would have a clear advantage because of its descriptiveness: it doesn't contain the entire definition, but it's the right amount to jog my memory and let me feel confident about using it without requiring another look up. On the other hand, I have to look up "Benedetti height" every freaking time just to remind myself which person's name got associated with which complexity metric. I agree that the term "product complexity" leaves out the information about what exactly gets its product taken, and so while for me that's plenty to remember that it's the numerator and denominator, other people might not be so certain based on that name. But that's an acceptable cost. No one name could be perfect for everyone. By pushing for "product complexity" I'm pushing for the name I think should work the best for the most people, is all.
:::::::::::: That all said! Yes, I think "minimal ratio form" is good and I would be happy if you used it. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 20:59, 1 October 2021 (UTC)
Return to "Normal forms" page.