Talk:Patent val: Difference between revisions
re +1 |
Cmloegcmluin (talk | contribs) No edit summary |
||
Line 35: | Line 35: | ||
::: Additionally, it probably isn't favorable to replace ''val'' by ''map''. Which word is more common in RTT? I suppose it's ''map''. So unless ''val'' is deprecated completely as a term, we should be using it more so as to make it familiar to people. This corresponds to the consequence that increasing its use rate means increasing the Shannon entropy of our RTT terms set. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 22:51, 27 September 2021 (UTC) | ::: Additionally, it probably isn't favorable to replace ''val'' by ''map''. Which word is more common in RTT? I suppose it's ''map''. So unless ''val'' is deprecated completely as a term, we should be using it more so as to make it familiar to people. This corresponds to the consequence that increasing its use rate means increasing the Shannon entropy of our RTT terms set. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 22:51, 27 September 2021 (UTC) | ||
:::: Thanks for clarifying the meaning of edomapping. In the parlance I recommend, "map" is already the word for an individual line of a mapping. "Map" is my substitute for "val". So a "mapping" is a matrix like {{vector|{{map|12 19 28}} and a "map" is a covector like {{map|12 19 28}}. I don't think that's popular parlance but I think it works well and I would like to popularize it. | |||
:::: I'm glad you find "nearest map" to be fine. Would you agree I should alter my proposal from "simple map" to "nearest map" and you would find it acceptable, then? | |||
:::: I don't understand what you mean, however, by "['nearest map'] is already there". My guess was that you meant that it's already a common usage. But I don't find any hits for "nearest map" or "nearest val" anywhere on the wiki or the Discord server. Perhaps there's evidence elsewhere, such as on Facebook, but I'm not sure how to search it effectively. Or what did you mean exactly by that? | |||
:::: I do not mean to replace every instance of "patent val" on the wiki, for the reason you describe: impracticality. I would wish that over time some may naturally be supplemented with a parenthetical or outright replaced, and I would likely contribute gradually to the effort myself, but even if I was willing to do that amount of effort, I don't think it's right to force the issue on the community like that. My goal is not simply to change how people read this stuff, but to help improve how they think about it. I totally respect your choice to keep your idiolect close to the majority (and also, that's a cool word, "idiolect"...) | |||
:::: I note, however, that the "p" used in wart notation does not actually stand for "patent". Well, of course, it can be made to, but my point is that the man who designed wart notation, Graham Breed, did not intend it to stand for patent. In fact, he dislikes the term "patent" as well. He meant for the p in wart notation to stand for "prime", as he explained in this recent Facebook post: https://bit.ly/3ocLPKJ Anyway, I don't blame you for assuming that. I assumed it myself, until I heard it from him directly, and at first was quite taken aback! | |||
:::: The val vs map issue is another topic, certainly. I assume you made a mistake in the above and meant to say you suppose that "val" is more popular? I would agree. And as an extremely rough measure I searched for the count of pages that contain "val" vs. the count that contain "map" and there's over 1000 with val while only around 300 with map, which doesn't surprise me at all. In fact, I would say that I expected it to be even more lopsided, and expect that a lot of those usages of "map" are as verbs, like A maps to B. I don't understand your point about Shannon entropy exactly, but it sounds interesting, so please clarify if you'd like. I think I get the gist of your point, though, that if val is more popular, and we don't have good reason to deprecate it, then we should rally around it as a community, rather than splinter off into clusters that advocate for one of several different terms, confusing the issue overall for everyone on average. | |||
:::: I do have what I think is good reason to deprecate val in favor of map, though: "val" creates an unnecessary barrier to understanding for ''newcomers'' to RTT, who in the long run — assuming the community continues to grow, which I believe we all hope it should — will constitute the vast majority. Many newcomers to RTT are already familiar with established terms for the concepts RTT borrows from linear algebra. Even if "val" does have some connection to the mathematical concept of a "valuation", this is of no help in illuminating its music-theory meaning, which is simply that of being a mapping from a single generator to primes. The first sentence in the Xenharmonic Wiki article for "val" says, "a val is a linear map". And the first sentence of the Wikipedia article where "covector" redirects to is: "... a covector is a linear map from a vector space to its field of scalars". So that is why I prefer "map" to "val". --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 01:59, 28 September 2021 (UTC) | |||
== proposal to rename "generalize patent val" to "uniform map" == | == proposal to rename "generalize patent val" to "uniform map" == | ||
Line 63: | Line 77: | ||
::: The cognitive process I mentioned above therefore leads to the reason why ''generalized patent val'' is friendly to our minds. Moreover, I like that the relationship between patent val and generalized patent val is demonstrated by the name in that one contains the other. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 22:16, 27 September 2021 (UTC) | ::: The cognitive process I mentioned above therefore leads to the reason why ''generalized patent val'' is friendly to our minds. Moreover, I like that the relationship between patent val and generalized patent val is demonstrated by the name in that one contains the other. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 22:16, 27 September 2021 (UTC) | ||
:::: We disagree about how best to explain this concept. You've convinced me that there is some virtue to the existing way of explaining it that's in the article. So I retract my proposal to replace it. Perhaps you would allow that — if I made some revisions to my way as you've recommended — there would be room for including my way of explaining it too. Eventually. But again this not my main interest here, so I'll drop the issue for now. | |||
:::: You've also convinced me to stop using the phrase "contradiction in terms" with respect to "non-integer EDOs". You're totally correct. Sorry for resisting, and thanks for explaining your take on that. | |||
:::: I'd like to call your attention to a point that I made in the original post which is that an "integer uniform map" is exactly equivalent to a "simple map"/"patent val" for the given integer. This to me is how best to achieve one name containing the other, which I do agree with you is a desirable effect that should be preserved. As I described, my approach inverts their relationship, so that it is the "integer uniform map" which is a specific type of "uniform map", rather than the other way around, where a "generalized patent val" is a generalized type of "patent val". In fact, when Dave Keenan and I were developing these proposals, it turned into somewhat of a drag-out fight, where for days I refused to budge that "integer uniform map" should be the only replacement for "patent val", while he only accepted "simple map", but we eventually came to the agreement that both terms had merit in different contexts. They are just two different helpful ways of thinking about the same structure; in contexts pertaining to tuning accuracy, "simple map" works great, and in contexts pertaining to other uniform maps, "integer uniform map" works great. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 01:59, 28 September 2021 (UTC) |
Revision as of 01:59, 28 September 2021
![]() |
This page also contains archived Wikispaces discussion. |
306c
c? what? 306edo takks about 306c?z! PiotrGrochowski (talk) 07:07, 19 September 2018 (UTC)
proposal to rename "patent val" to "simple map"
My first concern with “patent” map is that "patent", as an adjective, is unfamiliar to most people, unless it relates to those documents called patents. Calling them "obvious maps" would have been better than "patent maps".
The second concern is that they are not always obvious. If it were, there would be no contention about it. This name suggests a positive value judgment (and dismissive value judgement on other maps) which we think is inappropriate. A name like “patent” or "obvious" map may lead too many people concerned with accurate tuning to accept this map when if they'd known better they may have preferred the map with the most accurate tuning overall, i.e. the “best” map. The classic example of a best map which is not the patent map is 17c at the 5-limit.
These concerns arose in recent public discussion I was involved in, and it was agreed at that time that "naive" was an apt replacement for "patent". But through further discussion, we decided that this would have the opposite problem: where "patent" had excessively positive connotations, "naive" would have had inappropriately negative connotations, and might run the risk of discouraging people from using them despite such maps being relatively good. So we concluded that a word with more neutral connotations was appropriate, and so we're going with "simple". These maps may not always be obvious, but they are always simple to calculate.
The "simple map" sets octaves pure, and then for each other prime harmonic individually, chooses the nearest mapping (the one with least error). That's clearly simple, and it's good, but it's not necessarily best. On the other hand, the best map is not strictly defined yet, but it would have a more elaborate definition, involving a consideration of errors in the ratios between primes, not only in the primes themselves. --Cmloegcmluin (talk) 23:27, 25 September 2021 (UTC)
- I think your first two points somewhat neutralize each other. If people are unfamiliar with the word, no connotation could arise. Otherwise, if people feel positive with the word, they already know what it means.
- To me, patent in the sense of obvious is rather literary, which is suitable for carrying complex or subtle meanings, and effectively stay clear of any connotations. Simple map is a combo of two everyday words and gives me the impression that the concept isn't rigorously defined. If I must choose such a term, it'd be Kite's nearest edomapping. Nearest is more informative than simple at least.
- I also oppose using naive as a substitute. That word should be reserved for direct approximation. FloraC (talk) 18:01, 26 September 2021 (UTC)
- Thanks for for your reply, FloraC. I'll reply to your points in reverse order.
- Re: "naive". I agree. Your point — about direct approximation being a more appropriate candidate for that word — is an interesting additional reason not to use naive here. (To be clear, I was not advocating for it at this point; I merely mentioned it as one thing that was discussed in the past.)
- Re: how "patent" being a less everyday word than "obvious" may actually be advantageous, by better connoting that the thing defined is a specially defined thing: I totally get what you mean there. In fact, I made that point myself during some discussion! That said, this issue of "patent vs. obvious" is superseded by the fact that I think neither "patent" nor "obvious" are appropriate words for this term. This leads me to your first point, where it looks like you've misunderstood my original post (probably my fault! though I haven't been able to come up with a guess as to how you've misread it).
- You say that my first two points somewhat neutralize each other, but I think that must be because you've misunderstood my second point (which is conveyed in my second paragraph). What I was trying to say about 17-ET in the 5-limit was that it's hard to say which of its maps would be "the" obvious/patent one to use. The simplest/nearest-edomapping one is ⟨17 27 39] but the best one by many common standards is instead ⟨17 27 40]. So which one is obvious/patent — the simple/near one, or the best one? My point is that neither can be said to be obvious/patent. Maybe to one person one is obvious, but to another person the other is obvious. And so if there's any disagreement at all, no one gets to claim obvious (while probably everyone could agree which one of them was simple). And I further say that 17-ET is not an isolated example, and that this lack of consistent patentness/obviousness sufficiently problematizes the use of either word, patent or obvious.
- You do make an excellent point, however, about how "nearest" carries more helpful information than "simple", though. How do you feel about "nearest map", then? I ask because this term is always used in reference to an EDO/ET, so I'm not certain what "edomapping" brings to the table that "map" doesn't already, while I would penalize it for being jargony where "map" is an established linear algebra term. --Cmloegcmluin (talk) 02:27, 27 September 2021 (UTC)
- I believe edomapping is supposed to be a substitute for val, referring to an individual line of the map.
- Nearest val/map is fine and it's already there. Yet if you mean by renaming to replace every instance of patent val on this wiki, I suspect that's beyond practical. Consider all the legacies, for example, the p in the wart notation. (I, for one, also don't plan to change my idiolect until a majority of people has made the transition.) FloraC (talk) 22:16, 27 September 2021 (UTC)
- Additionally, it probably isn't favorable to replace val by map. Which word is more common in RTT? I suppose it's map. So unless val is deprecated completely as a term, we should be using it more so as to make it familiar to people. This corresponds to the consequence that increasing its use rate means increasing the Shannon entropy of our RTT terms set. FloraC (talk) 22:51, 27 September 2021 (UTC)
- Thanks for clarifying the meaning of edomapping. In the parlance I recommend, "map" is already the word for an individual line of a mapping. "Map" is my substitute for "val". So a "mapping" is a matrix like {{vector|⟨12 19 28] and a "map" is a covector like ⟨12 19 28]. I don't think that's popular parlance but I think it works well and I would like to popularize it.
- I'm glad you find "nearest map" to be fine. Would you agree I should alter my proposal from "simple map" to "nearest map" and you would find it acceptable, then?
- I don't understand what you mean, however, by "['nearest map'] is already there". My guess was that you meant that it's already a common usage. But I don't find any hits for "nearest map" or "nearest val" anywhere on the wiki or the Discord server. Perhaps there's evidence elsewhere, such as on Facebook, but I'm not sure how to search it effectively. Or what did you mean exactly by that?
- I do not mean to replace every instance of "patent val" on the wiki, for the reason you describe: impracticality. I would wish that over time some may naturally be supplemented with a parenthetical or outright replaced, and I would likely contribute gradually to the effort myself, but even if I was willing to do that amount of effort, I don't think it's right to force the issue on the community like that. My goal is not simply to change how people read this stuff, but to help improve how they think about it. I totally respect your choice to keep your idiolect close to the majority (and also, that's a cool word, "idiolect"...)
- I note, however, that the "p" used in wart notation does not actually stand for "patent". Well, of course, it can be made to, but my point is that the man who designed wart notation, Graham Breed, did not intend it to stand for patent. In fact, he dislikes the term "patent" as well. He meant for the p in wart notation to stand for "prime", as he explained in this recent Facebook post: https://bit.ly/3ocLPKJ Anyway, I don't blame you for assuming that. I assumed it myself, until I heard it from him directly, and at first was quite taken aback!
- The val vs map issue is another topic, certainly. I assume you made a mistake in the above and meant to say you suppose that "val" is more popular? I would agree. And as an extremely rough measure I searched for the count of pages that contain "val" vs. the count that contain "map" and there's over 1000 with val while only around 300 with map, which doesn't surprise me at all. In fact, I would say that I expected it to be even more lopsided, and expect that a lot of those usages of "map" are as verbs, like A maps to B. I don't understand your point about Shannon entropy exactly, but it sounds interesting, so please clarify if you'd like. I think I get the gist of your point, though, that if val is more popular, and we don't have good reason to deprecate it, then we should rally around it as a community, rather than splinter off into clusters that advocate for one of several different terms, confusing the issue overall for everyone on average.
- I do have what I think is good reason to deprecate val in favor of map, though: "val" creates an unnecessary barrier to understanding for newcomers to RTT, who in the long run — assuming the community continues to grow, which I believe we all hope it should — will constitute the vast majority. Many newcomers to RTT are already familiar with established terms for the concepts RTT borrows from linear algebra. Even if "val" does have some connection to the mathematical concept of a "valuation", this is of no help in illuminating its music-theory meaning, which is simply that of being a mapping from a single generator to primes. The first sentence in the Xenharmonic Wiki article for "val" says, "a val is a linear map". And the first sentence of the Wikipedia article where "covector" redirects to is: "... a covector is a linear map from a vector space to its field of scalars". So that is why I prefer "map" to "val". --Cmloegcmluin (talk) 01:59, 28 September 2021 (UTC)
proposal to rename "generalize patent val" to "uniform map"
My main concern with the term "generalized patent val", or GPV, is that it gets things backwards: it posits the GPV as a type of patent val, when it makes more sense to think of it the other way around, with the patent val as a type of GPV.
The present definition of GPV on the wiki bends over backwards to make its way work, essentially using non-integer EDOs, which are a contradiction in terms. Consider this alternative definition, however, which is more straightforward:
A GPV is any relatively near-just map found by uniformly multiplying the generators for JI (⟨log₂2 log₂3 log₂5 ... ]) by any value before rounding it to integers. For example, choosing 17.1, we find the map 17.1⟨1 1.585 2.322] = ⟨17.1 27.103 39.705] which rounds to ⟨17 27 40]. This is one of the many GPVs for 17-EDO, and every EDO has many possible GPVs. To find a GPV for n-EDO, choose any multiplier that rounds to n; another example for 17-EDO could be 16.9⟨1 1.585 2.322] = ⟨16.9 26.786 39.241] which rounds to ⟨17 27 39].
The key element in this definition is the uniform multiplier, and from it we draw our proposed replacement name for this structure: a uniform map. So the definition could be:
A uniform map is any relatively near-just map found by uniformly multiplying the generators for JI (⟨log₂2 log₂3 log₂5 ... ]) by any value before rounding it to integers. For example, choosing 17.1, we find the map 17.1⟨1 1.585 2.322] = ⟨17.1 27.103 39.705] which rounds to ⟨17 27 40]. This is one of the many uniform maps for 17-EDO, and every EDO has many possible uniform maps. To find a uniform map for n-EDO, choose any multiplier that rounds to n; another example for 17-EDO could be 16.9⟨1 1.585 2.322] = ⟨16.9 26.786 39.241] which rounds to ⟨17 27 39].
Any uniform map whose multiplier is an integer — or "integer uniform map" — is always the patent val (or simple map, per my other proposal above) for the corresponding EDO. And every simple map is also an integer uniform map. These are just two different helpful ways of thinking about the same structure; in contexts pertaining to tuning accuracy, "simple map" works great, and in contexts pertaining to other uniform maps, "integer uniform map" works great. --Cmloegcmluin (talk) 23:27, 25 September 2021 (UTC)
- The definition may use some readability improvements but ultimately it's just wordplays. Your alternative definition still involves non-integer edos. Or what else do you think the multiplier is? Imagine a ruler with a varying scale put on the pitch continuum. 17 means that the octave is at the 17th point, implying there are 17 unit intervals between the starting point and the octave, which means 17edo. And therefore 17.1 means 17.1edo. FloraC (talk) 18:01, 26 September 2021 (UTC)
- Thanks for your reply here too, FloraC.
- If you mean to say that the multiplier in my definition is literally equivalent to a non-integer EDO, then I disagree with that. I think it is completely reasonable to interpret this multiplier as just that: a decimal number being multiplied against the JIP, as a step in a technique for finding this specific type of ET map. This conceptualization bypasses any notion of non-integer EDO. I do understand the mathematical reality of this situation quite comfortably, and I am not being willfully obtuse about this, so I could certainly concede that if someone wanted to think about non-integer EDOs while reading my definition, they still could find a way to do so. In other words: I recognize that these ideas are closely related. But it is quite important to me that I've managed to avoid explicitly using the phrase "non-integer EDO", because I believe that the way of thinking about the problem involving that contradiction in terms is unhelpful and perhaps harmful.
- But I don't intend to dwell on that matter, which is mostly along the lines of what I would consider to be, in your words, merely a "readability improvement." The item of primary interest to me here is not the articulation of the definition, but the name for the term itself. I'm more concerned about replacing "generalized patent val" with "uniform map". I was only using the cleanliness of this definition relative to the existing definition as one argument in favor of that rename.
- So, what I'm most curious about is: do you agree that this structure is better understood not as a generalization of the "simple map"/"patent val" structure, but that it's more accurately understood the other way around, with the "simple map"/"patent val" being a specific kind of this? I am quite interested in your perspective on that issue. --Cmloegcmluin (talk) 02:27, 27 September 2021 (UTC)
- There's no reason to introduce the entity of a "decimal number multiplied against the jip", and if you do it, it needs an explanation. That's to ask what it is. The answer is the division number as illustrated by our ruler. Besides, you worded like avoiding explicit use of non-integer edos is an achievement, which I don't exactly agree, and to me this attempt sounds forced. In particular, I don't agree that non-integer edos involve contradiction. It's the same cognitive process as how people learn division: we first divide things by integers, and then we learn to extend the divisors to non-integers. Does division by a non-integer divisor involve contradiction? It doesn't.
- The cognitive process I mentioned above therefore leads to the reason why generalized patent val is friendly to our minds. Moreover, I like that the relationship between patent val and generalized patent val is demonstrated by the name in that one contains the other. FloraC (talk) 22:16, 27 September 2021 (UTC)
- We disagree about how best to explain this concept. You've convinced me that there is some virtue to the existing way of explaining it that's in the article. So I retract my proposal to replace it. Perhaps you would allow that — if I made some revisions to my way as you've recommended — there would be room for including my way of explaining it too. Eventually. But again this not my main interest here, so I'll drop the issue for now.
- You've also convinced me to stop using the phrase "contradiction in terms" with respect to "non-integer EDOs". You're totally correct. Sorry for resisting, and thanks for explaining your take on that.
- I'd like to call your attention to a point that I made in the original post which is that an "integer uniform map" is exactly equivalent to a "simple map"/"patent val" for the given integer. This to me is how best to achieve one name containing the other, which I do agree with you is a desirable effect that should be preserved. As I described, my approach inverts their relationship, so that it is the "integer uniform map" which is a specific type of "uniform map", rather than the other way around, where a "generalized patent val" is a generalized type of "patent val". In fact, when Dave Keenan and I were developing these proposals, it turned into somewhat of a drag-out fight, where for days I refused to budge that "integer uniform map" should be the only replacement for "patent val", while he only accepted "simple map", but we eventually came to the agreement that both terms had merit in different contexts. They are just two different helpful ways of thinking about the same structure; in contexts pertaining to tuning accuracy, "simple map" works great, and in contexts pertaining to other uniform maps, "integer uniform map" works great. --Cmloegcmluin (talk) 01:59, 28 September 2021 (UTC)