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

From Xenharmonic Wiki
Jump to navigation Jump to search

Quick note on GPV

As I messaged you on Discord, I do plan to engage with the rest of this, in particular after our RTT guide is finished being published. For now, though, just a quick note: our suggested replacement for "generalized patent val" is not "simple map". "Simple map" is the replacement for "patent val". Our replacement for "generalized patent val" is "uniform map". "Integer uniform map" is a synonym for "simple map". --Cmloegcmluin (talk) 15:53, 30 January 2023 (UTC)

Thank you for point it out. FloraC (talk) 06:11, 31 January 2023 (UTC)

When/how to respond

Hi Flora. I'm just checking in to see if you happen to have reviewed the whole guide by now, to see if you might have additions or revisions to your critique. And I'd like to know how best to respond to your criticisms — perhaps in discussion topics right here? I'm still busy looking for a job and need to focus on that effort, but I will get to this soon. Ultimately I suppose that for each of your criticisms the outcome will be one of the following:

  1. You convince me of your position, and I make the changes throughout the relevant pages.
  2. I convince you to withdraw the criticism, and you remove it from this page.
  3. We remain in disagreement, and the pages stay as they are.

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

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

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

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

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

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

--Cmloegcmluin (talk) 00:43, 4 May 2023 (UTC)