User talk:FloraC/Critique on D&D's terminology - Revision history

Cmloegcmluin: /* Re: Enfactoring */ new section

2023-05-04T00:43:53Z

Re: Enfactoring: new section

← Older revision		Revision as of 00:43, 4 May 2023
Line 78:		Line 78:

	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.		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)		--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 00:43, 4 May 2023 (UTC)

Cmloegcmluin: /* Re: Uniform map, integer uniform map */ new section

2023-05-04T00:43:29Z

Re: Uniform map, integer uniform map: new section

← Older revision		Revision as of 00:43, 4 May 2023
Line 66:		Line 66:

	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".		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)		--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 00:43, 4 May 2023 (UTC)

Cmloegcmluin: /* Re: Simple map */ new section

2023-05-04T00:43:07Z

Re: Simple map: new section

← Older revision		Revision as of 00:43, 4 May 2023
Line 58:		Line 58:

	--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 00:42, 4 May 2023 (UTC)		--[[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)

Cmloegcmluin: /* Re: Map */ new section

2023-05-04T00:42:50Z

Re: Map: new section

← Older revision		Revision as of 00:42, 4 May 2023
Line 46:		Line 46:

	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.)		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)		--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 00:42, 4 May 2023 (UTC)

Cmloegcmluin: /* Re: Held interval */ new section

2023-05-04T00:42:18Z

Re: Held interval: new section

← Older revision		Revision as of 00:42, 4 May 2023
Line 40:		Line 40:

	--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 00:41, 4 May 2023 (UTC)		--[[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)

Cmloegcmluin: /* Re: Prime-count vector */ new section

2023-05-04T00:41:52Z

Re: Prime-count vector: new section

← Older revision		Revision as of 00:41, 4 May 2023
Line 32:		Line 32:

	I just went ahead and deleted that whole section.		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)		--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 00:41, 4 May 2023 (UTC)

Cmloegcmluin: /* Re: Domain basis */

2023-05-04T00:41:25Z

Re: Domain basis

← Older revision		Revision as of 00:41, 4 May 2023
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.		'''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.		I just went ahead and deleted that whole section.

			--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 00:41, 4 May 2023 (UTC)

Cmloegcmluin: /* Re: Domain basis */ new section

2023-05-04T00:41:10Z

Re: Domain basis: new section

← Older revision		Revision as of 00:41, 4 May 2023
Line 18:		Line 18:

	:: To set expectations up front, I can already see that for some of your critiques, you will almost certainly not change my mind. But I pledge to stay open to your point of view, and I can see that for some others of your critiques you may well persuade me, in part because you make good points, I care relatively little about the issue, Dave and I weren't in solid agreement about a choice to begin with, or some combination of these and possibly other factors. Thanks as always for taking my/our work seriously and spending the time and energy to engage with it, even when it is to offer constructive criticism like this. --[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 15:38, 30 March 2023 (UTC)		:: To set expectations up front, I can already see that for some of your critiques, you will almost certainly not change my mind. But I pledge to stay open to your point of view, and I can see that for some others of your critiques you may well persuade me, in part because you make good points, I care relatively little about the issue, Dave and I weren't in solid agreement about a choice to begin with, or some combination of these and possibly other factors. Thanks as always for taking my/our work seriously and spending the time and energy to engage with it, even when it is to offer constructive criticism like this. --[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 15:38, 30 March 2023 (UTC)

			== Re: Domain basis ==

			This is an issue where Dave and I never reached complete agreement. He is fine with "subgroup basis" himself. It's only me who doesn't like it.

			'''Re: consistency.''' I have deleted the offending quotation. Sorry for the incorrectness.

			'''Re: simplicity.''' I do not admit that subgroup is technically more correct than subspace. I only acknowledge that some (such as yourself) argue for this. While JI may only be accurately described by free abelian groups, RTT can be accurately described by either those or by vector spaces, depending on the context or approach. If we take the commonplace, historical, and advisable approach of optimizing tunings of temperaments in terms of projections — i.e. lower dimensional approximations that are re-embedded into the original space, such as quarter-comma meantone with generator [0 0 ¼⟩ — then we're working in vector spaces. That's the way I recommend thinking of it, and I see no compelling reason for most musicians to learn "free abelian group", when it's hard enough for them to understand "vector" and "space".

			'''Re: specificity.''' I have deleted the offending quotation. You correctly identified that this reason was based on the previous term we played with, "interval basis", and is now obsolete.

			'''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.

Cmloegcmluin: /* When/how to respond */

2023-03-30T15:38:36Z

When/how to respond

← Older revision		Revision as of 15:38, 30 March 2023
Line 14:		Line 14:

	: I don't think I'm finishing reviewing all the terms any time soon, but the existing sections can be taken as finished so far. I'll update the essay accordingly as you respond, and perhaps you'll wanna do it in a separate page in your own namespace. [[User:FloraC\|FloraC]] ([[User talk:FloraC\|talk]]) 04:26, 30 March 2023 (UTC)		: I don't think I'm finishing reviewing all the terms any time soon, but the existing sections can be taken as finished so far. I'll update the essay accordingly as you respond, and perhaps you'll wanna do it in a separate page in your own namespace. [[User:FloraC\|FloraC]] ([[User talk:FloraC\|talk]]) 04:26, 30 March 2023 (UTC)

			:: I'll probably avoid creating a critique-of-critique page on my namespace, so I guess I'll stick to discussion topics here.

			:: To set expectations up front, I can already see that for some of your critiques, you will almost certainly not change my mind. But I pledge to stay open to your point of view, and I can see that for some others of your critiques you may well persuade me, in part because you make good points, I care relatively little about the issue, Dave and I weren't in solid agreement about a choice to begin with, or some combination of these and possibly other factors. Thanks as always for taking my/our work seriously and spending the time and energy to engage with it, even when it is to offer constructive criticism like this. --[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 15:38, 30 March 2023 (UTC)

FloraC: /* When/how to respond */ re

2023-03-30T04:26:10Z

When/how to respond: re

← Older revision		Revision as of 04:26, 30 March 2023
Line 12:		Line 12:
	# We remain in disagreement, and the pages stay as they are.		# We remain in disagreement, and the pages stay as they are.
	--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 19:53, 29 March 2023 (UTC)		--[[User:Cmloegcmluin\|Cmloegcmluin]] ([[User talk:Cmloegcmluin\|talk]]) 19:53, 29 March 2023 (UTC)

			: I don't think I'm finishing reviewing all the terms any time soon, but the existing sections can be taken as finished so far. I'll update the essay accordingly as you respond, and perhaps you'll wanna do it in a separate page in your own namespace. [[User:FloraC\|FloraC]] ([[User talk:FloraC\|talk]]) 04:26, 30 March 2023 (UTC)