User talk:FloraC/Critique on D&D's terminology: Difference between revisions

← Older edit

VisualWikitext

@@ Line 31: / Line 31: @@
 '''Re: inclusivity.''' I have deleted the offending quotation. I accept that we can't hold this issue against "subgroup", as it has never been made explicit or consistent.
 I just went ahead and deleted that whole section.
+--[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:41, 4 May 2023 (UTC)
+== Re: Prime-count vector ==
+I disagree that we use "vector" inaccurately. Maybe you don't understand that physicists, engineers, computer scientists, and (most importantly for RTT) linear algebraicists use the term "vector" very differently from the way group theorists use it. I expect that your concerns will seem arcane to our target readership, just as you apparently consider us "ridiculous" to say that a vector is a presentational form, that 81/80 is a quotient and not a vector, and that [-4 4 -1⟩ is its vector form.
+--[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:41, 4 May 2023 (UTC)
+== Re: Held interval  ==
+You think that instead of "held-interval" we should use "constraint". Well, "constraint" works fine in pure math or stats contexts. And indeed, in the D&D guide, we do explain that held-intervals are one type of constraint, where the system is for optimizing the tuning of a regular temperament.
+With "held-interval", we designed a way to speak about this concept in this context which clearly, concisely, and completely expresses it for our target audience, who are musicians, not mathematicians. So at the least, we're talking about some sort of "interval". What kind of interval, though? We might consider "constrained interval", but that's incomplete, because it leaves open to question how exactly it is constrained. A more specific term such as "constrained-to-pure interval" or perhaps "pure-constrained interval" would suffice, but "held interval" is shorter and sweeter than those. (Then we typically hyphenate to "held-interval basis" for clarity in some contexts.)
+--[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:42, 4 May 2023 (UTC)
+== Re: Map ==
+I am aware of Gene's explanation and defense of the term "val"; I understand that you are compelled by it, but I remain as unconvinced by Gene's words as Dave was during that conversation, and my target readership will feel the same way. So I also have nothing to repeat from that thread you linked. I think Dave clearly won that debate (to be clear, that means that we accept that "val" may be appropriate in certain very specific cases in exchanges between advanced mathematicians, wherever one finds needs to distinguish between an ordinary linear map and a "finitely generated homomorphic mapping from Q+ to Z", but in the 99% of RTT cases where this distinction is not useful, "map" is the term to use). I will here repeat, however, the reasoning why Dave and I recommend not using "val", as we wrote it up on the [[map]] page:
+ Dave and Douglas recommend using "map" rather than "val", for two reasons. First, "map" is a basic linear algebra term with wide familiarity (being specialized for this purpose) while "val" is unnecessary jargon that creates a barrier to understanding by newcomers. Second, the coinage of "val" from the obscure mathematical term "valuation" is tenuous and unlikely to provide helpful insight: "p-adic valuation" is an obscure term for "prime count", which would be an element of a prime-count vector ("monzo"), not a map ("val").
+As for Gene's death, I am sensitive to the fact that he was cruelly taken from us before his time, and that his friends and followers should mourn his passing. What ''I'' find "uncool" is how you've invoked his death in an attempt to chill efforts to question his work. We cannot simply end debate of people's ideas an account of their death.
+--[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:42, 4 May 2023 (UTC)
+== Re: Simple map ==
+"Simple map" is Dave's term. You may be surprised that he and fought about it over email for quite some time. At this point, I can't remember what exactly we disagreed about. I can't even remember if he convinced me to appreciate it, or if I only begrudgingly accepted it so we could move on to other problems.
+What I can say now is: I agree with your point that "simple map" isn't distinct enough to mark it as terminology for a higher concept, in particular, because we may wish to refer to maps that are simple or complex in the ordinary sense of those words, e.g. a simple map like ⟨31 49 72] versus a complex map like ⟨31 49 72 87 107 115 127 132 140], or perhaps a simple map like ⟨5 8 11] versus a complex map like ⟨311 493 722].
+I will ask Dave if he can come up with an alternative to "simple map" that has the desirable property of terminological distinctiveness that you and I both want. If he can't, I think it would be better to use only "uniform map".
+--[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:43, 4 May 2023 (UTC)
+== Re: Uniform map, integer uniform map  ==
+Of course, I agree that integers are simpler than non-integers / reals. But the concern here is not ''simplicity''; rather, it is ''specificity''. Integers are more specific than reals.
+The fundamental concept which is most important to name here is that of a map which maps primes uniformly, i.e. one which could be represented by a straight vertical line through the diagrams as shown on the uniform map page. When someone is first learning about maps, I believe it is very important for users to learn quickly that not just any sequence of increasing numbers has much value as a map, like ⟨17 26 40] is pretty crazy and useless, and so is ⟨17 28 39], but any of the maps ⟨17 26 38], ⟨17 26 39], ⟨17 27 39], ⟨17 27 40], ⟨17 28 40], or ⟨17 28 41] are perfectly reasonable from the perspective of uniformity. To ever try to use a non-uniform map would be a horrible idea, bad beyond any aesthetic sense of tempering harmonies or optimizing their tunings, but more like it's to the point that listeners could have no real hope of interpreting harmony that way at all.
+Of course, pure-octave tuning is a very simple concept, and this will favor mappings toward the center of the 17-block, such as the ⟨17 27 39] and ⟨17 27 40] ones. However, we must be careful not to conflate pure-octave tuning with the integer uniform map, i.e. the map right at the center point of the 17-block, which happens to be ⟨17 27 39], not ⟨17 27 40]. Any of these uniform maps — integer or otherwise — ''could'' be used with or without pure-octave tuning, to some success. Again, pure-octave tuning ''favors'' some of them. But in many important cases, such as this one, it doesn't ''significantly'' favor ⟨17 27 39] over ⟨17 27 40], at least by most accounts. This reveals how the integer uniform map isn't so much an effective tuning method or anything like that, but a mere convenience in some cases, like when we just want some easy reasonable place to start, with a single representative map for a temperament. And in most other cases, the idea of the integer uniform map is only a dangerously seductive distraction (as shown by how unfortunately wide and prevalent the interest in "patent vals" has become), where people apparently seem to think that it has more important tuning relevance than it does.
+In conclusion, uniform maps are the more important and basic issue. This is reflected in how our D&D's guide spends a significant chunk of time in the first major article explaining this issue, and almost no time at all explaining the issue of integer uniform maps.
+--[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:43, 4 May 2023 (UTC)
+== Re: Enfactoring ==
+I'm glad to hear that you've been putting "enfactoring" to the test in your communications. The concern you share here is about distinguishing "the two types of enfactoring", which led you to revert to "torsion" and "contorsion". Instead of thinking about this as two ''types'' of enfactoring, we think of two ''objects'' that can be enfactored: mappings, and comma bases. And so where you might write, "This temperament has contorsion / torsion", we would write, "This temperament has an enfactored mapping / comma basis." Your way makes it seem like these are two different things on a deeper mathematical level, but we think this could be misleading to newcomers, because it's essentially the same math, just applied to two different related musical objects.
+--[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:43, 4 May 2023 (UTC)