# User:FloraC/Critique on D&D's terminology

This essay is deprecated. It no longer fully represents the author's POVs. Rework is planned. |

This is a critique on the term choices in *Dave Keenan & Douglas Blumeyer's guide to RTT* and related articles. The main purpose of this essay is to raise awareness of good communication tools and warn against an unnecessary community fragmentation. The entries will be ordered by difficulty – those which can be easily fixed come at the top and those which may require deeper investigations are given at the bottom.

## "Domain basis"

*Domain* and *domain basis* are D&D's replacements for *subgroup* and *subgroup basis*, respectively. Currently the main reasoning is based on pedagogical needs. They argue for using linear algebra, the less advanced math theory, rather than group theory, the more advanced, since they believe the difference between the vector space and the free abelian group is negligible for practical purposes.

This is because group theory is a relatively obscure and advanced field of mathematics, and this article prefers to leverage terminology from the more well-known and basic field of linear algebra whenever possible. […] some argue that RTT cannot be sufficiently described using only linear algebra. This article, however, prioritizes pedagogy of the basics over any potential considerations arising from such advanced RTT problems.

Here they admit that *subgroup* is technically more correct than *subspace*. It should be pointed out that their reason seems to be one *for* taking the correct terms, not *against*. Specifically, they draw the comparison between the two math disciplines, and it appears that RTT would be more difficult by taking the correct terms. The problem in their logic is, if "advanced RTT problems" only arise occasionally, the actual difficulty levels should be similar.

The story behind it is that RTT does not make use of the full power of group theory. RTT only concerns free abelian groups, which as they appropriately noted, are similar to vector spaces.

My suggestion: use *subgroup* and *subgroup basis*. These are technically correct, consistent, and as clear as they can get. Maybe even *sub-* is not needed, just *group*, but that is another topic.

### Resolved issues

#### Consistency

~~First, they argue ~~*subgroup* and *basis* are inconsistent terms since they are a mix from different mathematical fields.

The term "subgroup basis" mixes mathematical terminology from different mathematical fields: "subgroup" comes from group theory, while "basis" comes from linear algebra. The equivalent term for "subgroup" in linear algebra is "subspace", and the equivalent term for "basis" in group theory is "minimal generating set".

That is not correct. The basis is a concept that is used across linear algebra and a particular sector of group theory: the study of free abelian groups. If you look up the definition of the free abelian group, it is simple: a free abelian group is an abelian group that has a basis. Indeed, in RTT, JI is modeled as a free abelian group, rather than a group or module in general. That is why bases are used.

~~Since a free abelian group is a group, it naturally has subgroups. It is not a vector space, so we do not speak of subspaces – but that has to do with their next point below. ~~

#### Specificity

~~At this point, they further argue for ~~*domain basis* than *subspace basis*: they prefer more specialized tuning terms to general mathematical terms.

This article prefers to use specialized terminology for objects in our RTT application, so that we can clearly discuss them independently from the mathematical structures that represent them.

~~To understand this point of theirs, we must look back at the time before they changed ~~
*interval basis* to *domain basis*. Back then, *interval basis* was indeed more *specialized* for tuning, though not more *specific* in its form. Yet that is no longer the case. *Domain* is by no means more specialized or specific than *subgroup*, if not less. So the reason is obsolete.

#### Inclusivity

~~Finally, they argue that ~~*subgroup* is often assumed to be nonstandard subgroups, and to exclude the standard type, while *domain* is designed to include both standard and nonstandard types.

"Subgroup" in many typical RTT usages is apparently intended to exclude the standard prime-limit subgroups. This makes it more difficult than necessary to communicate about the standard prime-limit basis, which are still very much subgroups — of the entire space of primes, for one example. So we think this is unnecessary complexity with no clear benefit.

There is no explicit, clear-cut exclusion of standard subgroups in the definition. Technically, a full prime-limit JI is a subgroup of a larger prime-limit JI. It happens that we have distinct vocabulary for standard subgroups, so the word only tends to appear at the nonstandard type. They also say the term "has taken on a specialized meaning in RTT", which I am again not sure about. For one thing, it has never gained a distinct definition. Still, according to my observation, whether it is meant to include the standard type is up to the context.

~~The hope for a term that invariably includes standard subgroups does not hold itself because language does not work like that. So long as prime limits continue to be used, chances are the actual usage of ~~
*domain* will turn out the same as *subgroup*.

## "Prime-count vector"

*Prime-count vector* is D&D's replacement for *monzo*. This is one of the worse proposed terms as it includes an inaccurate use of the term *vector*. A vector is a mathematical structure rather than a form of presentation, so a JI interval is essentially a vector no matter how it is written and what face value it takes on. For example, the syntonic comma, 81/80, and [-4 4 -1⟩ are all vectors, and since the vectors represent the number of each prime harmonics, they are prime-count vectors. It would be ridiculous in RTT to say the syntonic comma was not a vector, or to say 81/80 was not a vector. It follows that wherever we use *vector* we may as well use *interval*.

A monzo is a particular notation of a vector. The *monzo* article clearly tells us a monzo is "a way of notating a JI interval". The more technical *monzos and interval space* article reads: "this is often written in ket vector notation as […] in which case it is called a monzo." It often happens that the different forms of an interval such as the name, ratio, and monzo are shown side by side. In the above example, neither the syntonic comma nor 81/80 is a monzo, but [-4 4 -1⟩.

On the other hand, the monzo is not the ket, nor should it really include kets by definition. A monzo can be rendered with kets, like [-4 4 -1⟩, or brackets with the transpose symbol, like [-4 4 -1]^{T}, or parentheses and comma separators, like (-4, 4, -1). Just as emphasis can be rendered using italic, bold or underscore. The common spirit among these rendering is the bracketed and appropriately spaced part.

I will not have a problem with Plainsound Music Edition's *harmonic space coordinates* as a synonym of *monzo*, because a list of coordinates is indeed a form of presentation. *Monzo* has the advantage that it is concise – more on the name side than on the description side. A name points to a definition with minimal connotations at face value, whereas a description stays intermediate between the conciseness of a name and the rigor of a definition – and so it does not work as a replacement of either.

My suggestion: use *monzo*, and if you need to explain it, try saying they are *harmonic space coordinates*.

Update: There are probably some fundamental discrepancies in our understandings of what a vector, and what an interval in RTT is, and I do not believe it has to do with the field. My main point remains that monzo is the presentational form and vector is not, and that all intervals are vectors in RTT however they are presented.

## "Held-interval"

~~I really don't get the obsession of expressing a single coherent concept in multiple words. A held interval is simply a constraint. A constraint is something that constrains the system. ~~

Update: I admit there is nothing inherently wrong about *held-interval*. *Constraint* is used in the context where we talk about optimization of an abstract math problem so it is a term that one would always encounter. A purely tuned, purely constrained, or held interval is the real-world counterpart of it. So it is up to the user which aspect of the concept they are thinking of.

## "Map"

~~See ~~
*Vals?* where Gene Ward Smith presented in-depth explanation and defense of the term. There is nothing to repeat and I find it uncool to revive the topic after Gene's death.

Until I do a further research on the original thread. However this part, which I reckon is used to suggest that *val* be wrong, does not hold:

"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").

There is only *valuation*, not *p-adic valuation*, and each element is indeed a valuation i.e. how many generators that make the prime.

## "Simple map"

*Simple map* is D&D's replacement for *generalized patent val* (*GPV*).

I have forgotten if it was me who suggested *simple map* when they were discussing it, because it does look like a term that I could come up with, in the same way I suggested *simple JI*. Unlike *simple JI*, the main problem of *simple map* is again lack of specificity while taking on a very specific and rigorous meaning. *Simple* and *complex* are definitely reasonable qualities of a *map*, which means *val*.

*Uniform* and *patent* are much better at naming mathematical concepts. These words are rather literary, which lends themselves to carrying complex or subtle meanings, and effectively staying clear of any connotations. *Patent val* or *integer uniform map* make no everyday sense. The only possible occurrence of the phrases would be in the mathematical sense. I consider that to be of top importance in our choice of terms.

My suggestion: use either the combo of *patent val* and *generalized patent val*, or *uniform map* and *integer uniform map*, but see below.

## "Uniform map" and "integer uniform map"

The other philosophy embedded in *uniform map* and *integer uniform map* is a turn of conceptual framing:

For patent vals and GPVs, patent vals are considered the base case, and GPVs a generalization thereof, whereas for uniform maps and integer uniform maps, uniform maps are considered the base case and integer uniform maps a specialization thereof. There is an argument that uniform maps are the more fundamental and important concept to regular temperament theory and therefore that this framing is the superior of the two.

Yet think of how we learned division. It is the same cognitive process: we first divide things by integers, and then we learn to extend the divisors to non-integers. That leads to the reason why the base name of *patent val* is arguably more friendly to our minds.

My suggestion: Use *patent val* and *generalized patent val*.

## "Enfactoring"

*Enfactoring* is D&D's replacement for both *torsion* and *contorsion*. In fact, this is one of the few terms of their proposal that I really feel positive, and I was one of the first to accept it. However, after some rounds of communication practice, it turns out there is sometimes the desire to distinguish the two types of enfactoring. In that case we quickly switched to *torsion* and *contorsion*.

My suggestion: use *enfactoring* when there is no need to distinguish its two types. But we should probably never forget *torsion* and *contorsion*.

## "Just tuning map"

*Just tuning map* is D&D's replacement for *just intonation point* (*JIP*). I feel very positive about this replacement, as the neologism concisely conveys both the structure (a tuning map) and its contents (JI). In the original term *intonation* is one word's space wasted and *point* sounds no more than a filler word without the right context (a point in the tuning space).

I recommend *just tuning map*.