Talk:Patent val: Difference between revisions

(49 intermediate revisions by 5 users not shown)

Line 1:

__toc__

== 306c ==

Line 50:

Line 53:

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

::::: Yes, edomapping is supposed to be a substitute for val. Obvs I vote for nearest over simple/patent/obvious. I strongly agree that "val" creates an unnecessary barrier to understanding. Map or mapping is much better. I personally like edomapping even more because it is extremely self-explanatory. In a phrase like "the nearest edomapping for 17-edo" it is indeed redundant, but there I would just say "the nearest mapping for 17-edo". --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 07:04, 28 September 2021 (UTC)

::::: Yes, edomapping is supposed to be a substitute for val. Obvs I vote for nearest over simple/patent/obvious. I strongly agree that "val" creates an unnecessary barrier to understanding. Map or mapping is much better. I personally like edomapping even more because it is extremely self-explanatory. In a phrase like "the nearest edomapping for 17-edo" it is indeed redundant, but there I would just say "the nearest mapping for 17-edo". See also my comment below in "Uniform map". --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 07:04, 28 September 2021 (UTC)

:::::: By "it's already there" I was saying that ''nearest edomapping'' is in the first sentence of this article. And we're ready to propagate this term to other pages once the ''val'' vs ''map'' issue is resolved.

:::::: So, no, I meant to say ''map'' was more popular. ''Val'' mainly arises in edos whereas ''map'' arises in higher-rank temps. The search giving more results of ''val''s may be attributed to the template. Hence the number of search results can't be evidence for use rates. The Shannon entropy argument is based on the premise that val is a word of below-average use rate so increased use rate makes the communication more efficient – interesting indeed as it may be a theoretical basis for the keep-people-familiar argument. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 09:15, 28 September 2021 (UTC)

::::::: Hi Kite, thanks for joining this thread!

::::::: Re: edomapping. Kite, we have different rankings of the terms. I would certainly rank your term "edomapping" way above "val", for the reason you give: it doesn't create a barrier to understanding. It's descriptive, which is something I fight for in terminology (and why I can see value in "nearest" over "simple"). But I still don't like it quite as much as "map" because it's a word that was made-up for xen, and so to a newcomer it will look weird and unfamiliar. We have a problematically off-putting amount of jargon in this domain, and terms like "edomapping" contribute to that. Also, "map" has better generalizable use; edomapping doesn't work for maps that don't include the octave, e.g. we could say {{map|13 19 23}} is the nearest map for 13-ED3, but we couldn't say it was the nearest edomapping.

::::::: Re: "it's already there". I see, FloraC. You meant only the word "nearest" was already there. Right. Then indeed I agree that the term is ready for propagation, once the ''val'' vs ''map'' issue is resolved, although I would revise that last clause because it looks like it's actually the ''val'' vs ''map'' vs ''edomapping'' issue.

::::::: But first I would like to give Dave Keenan a chance to chime in here, because he was the one who originally came up with "simple map". I know that he is generally amenable to the types of arguments given here for "nearest" over "simple", so I have some confidence that he'll like it, but personally I owe it to him to solicit his opinion directly. So I've just emailed him about this.

::::::: Re: the relative popularity of map and val. Ah! Very interesting. I'm sorry that I guessed you had mistyped. I can see that two factors came together to lead me to assume you had accidentally written that "map" was more popular when you meant "val": 1) the amount of time I spend on Facebook and email with old-school RTT people who are steeped in Gene's jargon, where I am overwhelmingly exposed to "val" and in the minority of "map" users, and 2) my guess re: the meaning of this unfamiliar Shannon Entropy concept, which — due to some bad intuitions of mine — seems to be the exact opposite of what it really means (more on that in a bit). I hope you understand.

::::::: Well, I'm encouraged to hear that what you actually think is that "map" is the one which is more popular; that tells me that the community is moving in the direction I prefer. I agree that many of the occurrences of "val" are coming from the template, but I had permitted those as evidence of popularity, at least insofar as people are regularly exposed to it and accepting of it. Anyway, I did say it was only an incredibly rough estimate, though, and I only said it that way when I assumed I was using it to help ''your'' case. :) But if it's only hurting both of our cases, then of course, for similar reasons, I am willing to go ahead and agree with you that it can't really be used for evidence here. (By the way, it is also heartening to know that the template has gotten enough buy-in that we could accomplish a lot of patent val -> something better by changing things at one single point!)

::::::: Re: the Shannon Entropy thing. What I'm trying to say about my bad intuitions is this. I think that a situation where we have 2 terms we each use about half of the time or 3 terms we each use about a third of the time is a bad situation. I thought that was common sense, and so I assumed Shannon Entropy might be a fancy name for that idea (and here's a great piece of evidence where jargon and non-descriptive, in this case eponymous naming are creating a barrier to my understanding). I assumed that everyone would prefer standardization: a situation where we use a single term for a single thing almost all of the time and any other terms almost never. But if I'm understanding correctly now, it sounds like you're saying that we ''should'' strive for the situation where all of the words are used equally often? I'm probably still missing some important information, though. And I can't find any information about this "keep-people-familiar argument" concept you mention to help me make sense of it either. Sorry. If you want to convey these ideas to me more effectively, I would ask you to unpack these unfamiliar concepts for me, or find a simpler way that doesn't involve them. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 16:22, 28 September 2021 (UTC)

:::::::: I understand what I'm tryna argue is counterintuitive. Maybe I failed to make the context clear. It's this: ''val'' can't be replaced entirely by ''map''. You can replace this word in the phrase ''patent val'', but beyond this phrase, it can't be replaced by all occurrences. It turns up in all the temp pages, for example, where simply replacing the lines of ''vals'' to ''maps'' isn't appropriate. It has to do with the concern that ''val'' isn't totally synonymous with ''map''. ''Val'' or ''edomapping'' (I reckon these two are synonymous) emphasises itself being an individual row of the map. Therefore, ''val'' remains a word that's likely to be encountered by those who work with RTT even if it's removed from the phrase ''patent val''. That's why we hope to keep people familiar with both terms by using the term of lower use rate more, which can be explained through Shannon entropy. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 01:26, 29 September 2021 (UTC)

::::::::: If we can't agree on a replacement for "val", there seems little point in pursuing the other proposed terminology changes. So, Kite and/or Flora, please explain why you claim that "edomapping" is a suitable replacement for "val" when, as Douglas mentioned, vals need not be related to EDOs at all, e.g. they may be ED3 maps, or as the [[Val]] article says, "It's very common for vals to refer to EDOs specifically, although they also show us how to relate larger chains of generators to JI as well (such as a stack of meantone fifths)". i.e. a val can be a single row of a mapping for a temperament of rank greater than 1, and therefore not directly related to an ED of any kind. In short: "non-edo val" makes perfect sense while "non-edo edomapping" does not.

::::::::: And in case that isn't enough, the [[Mapping]] article makes it clear that a "mapping" is a ''list'' of vals, which can be viewed as a matrix. Of course some mappings contain only one val, and so a val could be considered to be a rank-1 mapping. But it would be somewhat circular to define a mapping as a list of rank-1 mappings, as seems to be implied by your clam that "edomapping" is synonymous with "val".

::::::::: And please explain what prevents us from defining "map" in RTT as synonymous with "val", given that the [[Val]] article begins, "A val is a linear map representing ...". I see that [[Map]] currently redirects to [[Mapping]], but I see no reason why it must do so. Why not use the shorter term "map" for the lower-level objects of which mappings are composed? And aren't we more likely to succeed in replacing "val" in people's existing usage, if the replacement has only one syllable, like the original? And "bimap", "trimap", "multimap" work so much better than "biedomapping", "triedomapping", "multiedomapping", as replacements for "bival", "trival" and "multival" in the exterior algebra formulation. --[[User:Dave Keenan|Dave Keenan]] ([[User talk:Dave Keenan|talk]]) 04:40, 5 October 2021 (UTC)

:::::::::: Aren't ''mapping'' and ''map'' just the same word in different inflections? I don't see how anyone would use them for different entities instead of interchangeably. It only makes things confusing. Also switching to ''mapping'' from ''map'' is a relatively recent change I believe.

:::::::::: ''Edomapping'' is synonymous with ''val'' because it's meant to be so. The circular definition problem is independent of names. If you define a val as a single row of the mapping and the mapping as a list of vals, it's circular definition whatever you call it. That said, I agree that it's less appropriate for non-edo vals and that's why I'd stick to ''val''.

:::::::::: Finally, if you're planning to replace every occurrence of ''val'': how about the "vals" in each temp page? [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 08:44, 5 October 2021 (UTC)

::::::::: It is true that, in mathematics generally, ''mapping'' and ''map'', when used as nouns, are synonyms, and both are synonymous with ''function''. But there is very little difference between an individual row of a mapping, and a mapping with only one row. So if we were to agree that, in RTT, only an individual row should be called a ''map'', and someone new to the field assumes that a map is the same as a mapping, then there are almost no consequences of that temporary confusion, if it can even be called confusion. For 12edo, its 5-limit ''map'' is ⟨12 19 28], and its 5-limit ''mapping'' is [⟨12 19 28]⟩. The mnemonic is simple: The shorter term applies to the smaller object. The difference rarely matters to anyone, but when it does, at least we would have descriptive terms rather than the confusing and unnecessary jargon of "val", which acts as a barrier to understanding.

::::::::: You may be aware that I am one of the founders of regular temperament theory along with Paul Erlich, Graham Breed, Gene Smith and others, since 1998. In online discussions of regular temperaments, and in our writings, all four of us have referred to any array of numbers whose units are "generators per prime", as a mapping, ever since we first referred to them as anything at all, which seems to have been in early 2001. Only rarely has this been shortened to "map" — typically only as a heading in tables of temperament data generated by Gene Smith. But even Gene is on record as defining a "prime mapping" as a "list of vals", here: http://www.tonalsoft.com/enc/p/prime-mapping.aspx

::::::::: I didn't rely on my memory for the above, but spent several hours going through the results of the following tuning archive searches:

::::::::: site:yahootuninggroupsultimatebackup.github.io "mapping"

::::::::: site:yahootuninggroupsultimatebackup.github.io "map"

::::::::: Of course most of the temperament data in the Xen Wiki was generated by Gene, so it is not surprising if it contained "map" as an abbreviation of "mapping". So I assume, when you say that switching to ''mapping'' from ''map'' is a relatively recent change, you are referring to someone having expanded these occurrences of "map" to "mapping". That would be a good thing. It would make them consistent with the output from Graham Breed's temperament finder, and it would open the way to defining "map" as synonymous with "val".

::::::::: In the Xen Wiki and Graham Breed's temperament finder and the tuning archives, [there is a case in which*] the term "map" (and not "mapping") already consistently refers to an individual row of the form ⟨...]. This is in the case of a "tuning map", which maps from generators to cents. This is a map in "tuning space". By analogy, a val is therefore a map in "temperament space", and so it would be perfectly consistent with existing terminology, to refer to a val as a "temperament map" as opposed to a temperament mapping. We are merely proposing that an unqualified "map" should be assumed to be a temperament map, i.e. a val, not a tuning map. Or at least that when it is clear from the context that it is a temperament map, the qualifier "temperament" can be dropped. [*clarification added 30 Dec 2021] --[[User:Dave Keenan|Dave Keenan]] ([[User talk:Dave Keenan|talk]]) 16:29, 6 October 2021 (UTC)

:::::::::: I guess I agree that ''map'' is a possible replacement for ''val'', but my point has always been practical. What's the plan? How do you make all the RTT users forget about ''val''? How about all these pages? The letter ''V'' in the formulae? [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 00:24, 7 October 2021 (UTC)

:::::::::: And with so many legacies, I must oppose this change since I oppose forced language reforms. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 00:38, 7 October 2021 (UTC)

::::::::: Thanks FloraC.

::::::::: It is arguable that the introduction of ''val'' was a forced language reform since, before that, and after, tuning list contributors were happy to use descriptive terms like "ET mapping" and "mapping row". So arguably, ''if'' we replaced ''val'' we would merely be ''undoing'' a forced language reform.

::::::::: However I don't actually want to replace any existing occurrences of ''val''. I only want to ensure that the way is open for Douglas to use ''map'' as a synonym for it, in his excellent pedagogical articles. And for others to use ''map'' in that way, if they choose, going forward.

::::::::: The first thing to do in that regard would be to redirect "Map" to the "Val" page instead of the "Mapping" page, and to mention ''map'' as a synonym near the start of the "Val" page.

::::::::: The only other thing would be to check all existing (whole-word) occurrences of "map" in the wiki (outside of Douglas' articles), and if they refer to a matrix, as opposed to a row vector ⟨...], expand them to "mapping". --[[User:Dave Keenan|Dave Keenan]] ([[User talk:Dave Keenan|talk]]) 09:41, 8 October 2021 (UTC)

:::::::::: However val was introduced in the first place, it's the status quo and what's undoing of language reform is simultaneously another layer of language reform. Anyway, you've clearly presented the feasible first steps to switch to ''map'' and I'll follow, although I'd like to make ''map'' a disambiguation page to catch all the usage. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 11:26, 8 October 2021 (UTC)

::::::::: I dislike val strongly because the dictionary says it's an abbreviation for value. Which is not only vague, but also misleading because there are multiple values in a single val. I don't see why val can't be replaced with something better. I still like edomapping. I think it's the opposite of jargon, because it's very self-explanatory. For the ED3 case, I propose edt-mapping or ed3-mapping. For the general case of rank-1 mappings that aren't edos, I propose edonoi-mapping. In other words, you just specify what the mapping is used for in the name. For the even more general case of the combination of edomappings and edonoi-mappings, I propose rank-1 mapping. For everything outside of that, I propose mapping-row. I'm OK with mapping being shortened to map in any or all of these cases. I'm also OK with hyphenating, e.g. edo-map or edo-mapping. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 06:29, 9 October 2021 (UTC)

::::::::::That's a good solution. Thanks FloraC.

::::::::::Kite, I find all those terms you suggest above to be acceptable (except I don't know what "edonoi" means). I have used many of them myself in the past. But none of them is a potential replacement for "val" since vals include both "rank-1 mappings" and "mapping rows". Douglas and I have chosen to use "map" for this purpose in our pedagogical materials, thereby giving it a more specific meaning than "mapping" within the domain of tuning theory. --[[User:Dave Keenan|Dave Keenan]] ([[User talk:Dave Keenan|talk]]) 06:45, 10 October 2021 (UTC)

::::::::::: EDONOI means equal division of a non-octave interval. It's a fairly widespread term. "none of them is a potential replacement for val" I'm proposing edonoi-mapping, mapping-row etc. as replacements for specific use cases of val, and the term map or mapping as the general replacement for val. So I think we agree that val can be completely replaced by map/mapping. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 21:09, 16 October 2021 (UTC)

== proposal to rename "generalize patent val" to "uniform map" ==

Line 85:

Line 156:

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

::::: "Uniform" isn't very self-explanatory, IMO. I propose replacing GPV with "exact edomapping" or possibly non-integral or decimal edomapping. But in practice the GPV gets rounded off anyway, and none of these terms apply, not even uniform. In fact I must admit I'm confused what precisely a GPV is. I would think it's an exact, non-integral edomapping, and rounding it off turns it into a normal (i.e. integral) edomapping. But the article says "We can show that ⟨17 27 40] is a generalized patent val".

::::: I think the whole concept of GPV would be much clearer if 1) GPV means only an exact un-rounded-off edomapping, and 2) there is a separate term for an integral edomapping that can result from rounding off a GPV. I propose "proper edomapping", which includes 17 and 17c and even 17bbccc (the ⟨17 28 41] of the article) but not 17cc or 17ccc. This seems to be the whole point of GPVs, to create a rigorous definition of proper and improper edomappings.

::::: I'd also like to note that "exact edomapping" makes sense but "exact map" or "exact mapping" doesn't. Because there's no point in generalizing the meantone mapping [⟨1 0 -4], ⟨0 1 4]]. Point being, there are times when one wants to say edomapping not mapping (see my comment in the "simple map" discussion above). --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 08:09, 28 September 2021 (UTC)

:::::: I agree that "uniform" is not self-explanatory. But I don't think self-explanatory-ness should be a target for terminology. I think it's only necessary that terms are descriptive. I think "generalized patent val" is also not self-explanatory, so it's not a relative point against "uniform map".

:::::: Unfortunately, I'm having trouble figuring out how best to reply to the rest of your thoughts and suggestions here. As you admit, you feel confused about what precisely this concept is, and it seems likely to me that you do have some misconception about it, because I can't follow much of your thinking, or reconcile many of your statements with my understanding of the ideas here. So perhaps we should both pause making suggestions or criticisms involving terminology, and first make sure that we're all on the same page about the structure itself.

:::::: I love visual explanations myself and hope that this one will be helpful to you, too. Uniform maps (or GPVs) finally clicked for me when a guy on the Discord server named Dead Shaman shared a special type of chart with me. I adapted his chart for use in my RTT How-To, where I explain that a uniform map is any map that can be found at a vertical line drawn through it. Here's an example (there's a lot of other stuff going on in these charts that's not necessary, so no need to understand everything):

[[File:Near linings up rare2.png|thumb|center|700px]]

:::::: And that is why the example you were surprised about, {{map|17 27 40}}, is indeed a uniform map, because you can see it drawn as such a vertical line in another area of that chart, as seen here:

[[File:17-ET.png|thumb|center|200px]]

:::::: Please let me know if this explanation helps, or if you have any other questions. FloraC and I have also provided alternative explanations of the concept in our discussion above that aren't present in the article itself (yet... maybe we'll rework it soon), so if you are unfamiliar with those explanations, they may prove helpful as well. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 16:48, 28 September 2021 (UTC)

::::::: I understand the math perfectly well. I understand the diagram too. What I don't understand is the terminology. Generalized in this context means generalized from integers to real numbers, right? Which allows the numbers to be exact, e.g. 3/1 is exactly 26.944/17 the size of 2/1, hence ⟨17 26.944] is an exact edomapping. And exact is what you mean by uniform, right? But nobody actually uses these real-number edomappings. Instead, the real numbers are rounded to integers. Which makes them not generalized, and not exact. So I don't understand, or more bluntly I strongly object to, calling the rounded edomappings generalized.

::::::: In other words, here's three of what I would call generalized PVs: ⟨17 26.944 39.473 47.725] and ⟨17.1 27.103 39.705 48.006] and ⟨17.45 27.658 40.518 48.988]. And here's what you get when you round them: ⟨17 27 39 48] and ⟨17 27 40 48] and ⟨17 28 41 49]. But there's nothing generalized about those last three. They are ordinary edomappings. But the whole point of exact real-number edomappings is that you can derive ordinary inexact integral edomappings from them. And because these three have been derived this way, they are more "reasonable" or "natural" than others which can't be. And "proper" is a much better term for that than "generalized". So IMO any edomapping through which you can draw a vertical line on the diagram and hit every component rectangle should be called a proper edomapping, and any one that you can't do this with should be called an improper edomapping.

::::::: Using my proposed terminology, 17edo has exactly 9 proper 7-limit edomappings, one of which is the nearest edomapping. As you would expect, the nearest edomapping of any edo is always proper. Using the current terminology, 17edo has 9 GPVs. One of them is the patent val, plus there's 8 non-patent vals. But each of those non-patent val is also a generalized patent val. So even though they're non-patent, they still have "patent" in the name. Which is confusing. This confusion goes away when you use the term proper.

::::::: Interesting side point: 17edo's smallest (i.e. contains the smallest numbers) proper edomapping is ⟨17 26 38 46]. And 16edo's largest is ⟨16 26 38 46]. The last 3 numbers are the same because 16.5 can be rounded up to 17 or down to 16. In other words, 16.5-edo is both stretched 17edo and compressed 16edo. In fact the whole section on GPVs might be improved by explicitly discussing stretched edos. We could even call GPVs stretched edomappings, if we use the word stretched loosely to mean both stretched and compressed and also neither one. Then what I'm calling proper edomappings would be called nearest stretched edomappings. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 08:40, 29 September 2021 (UTC)

:::::::: Ah! Sorry. I did not mean to insult your intelligence or otherwise offend. As soon as I saw your reply, I remembered that when I drafted my previous post, I had the flicker of a thought that I should say something like "or maybe you do totally understand the concept but I just need you to clarify what you mean by 'exact' and 'proper'". I regret failing to follow through on that now. And you've gone ahead and done it for me. Thank you for that. Your full explanation lets me see that we're actually just about on the same page, so that's great.

:::::::: To be clear, I am the one who made the original post here arguing against the terminology "generalized patent val". You don't have to convince me that it's bad; we agree on that. I do think FloraC here still supports it to some extent, so arguments presented against it are still useful. I myself have elsewhere made the point you make above about how putting the words "generalized" and "patent" together is already confusing; I see that I didn't make it myself above in my original post, so I'd like to explicitly say that I second that point.

:::::::: You are correct so far when you say that the "generalized" part of "generalized patent val" means "from integers to reals". (And I'll take this opportunity to reiterate my position that it's more logical to structure it the other way around: defining a basic concept for the reals, i.e. uniform maps, and then specify integers when appropriate, i.e. integer uniform maps, AKA simple maps / patent vals / nearest edomappings.)

:::::::: However, I think you have the wrong idea about which numbers exactly that "generalized patent vals" are supposed to be thought of as generalizing from integers from reals. So, to be clear, I am choosing to assist my opponents here by clarifying their reasoning, but of course I want us to have a fair consideration of each other's ideas at their best and clearest. And as far as I can tell, it seems to be the case that you think "generalized patent vals" generalize ''all of the entries in the map'' from integers to reals, but that is not correct. ''Only the EDO number'' that is used in the otherwise identical process for computing a patent val is generalized. Or as I prefer to think about it, what is generalized is the ''multiplier'' that the terms of the JIP (i.e. {{map|log₂2 log₂3 log₂5 ...}}) are uniformly scaled by (except, again, I prefer to say that the default case is that this uniform multiplier is real, and if you need it to be integer, you say so).

:::::::: You say that "nobody actually uses these real-number edomappings (directly)" and I agree with that. That's a big reason why structures like {{map|17 26.944 39.473 47.72}}, {{map|17.1 27.103 39.705 48.006}}, {{map|17.45 27.658 40.518 48.988}} are ''not'' what we've given the name "generalized patent val"/"uniform map" for. You say that those ''are'' the structures that the name "generalized patent vals" makes sense for, and while I agree that generalized patent val ''could'' be a reasonable name for them if anyone wanted to name them, I don't believe there's a wide desire or any good reason to name these such structures at all. They don't have enough value in and of themselves. They are merely intermediate states before being rounded to the structures of value that are worth being named, i.e. "generalized patent vals"/"uniform maps" (I had to check your numbers here to make sure I understood what points you were illustrating with them — and yes, these are all indeed valid uniform scalings of the JIP which upon rounding would therefore give you GPVs/uniform maps).

:::::::: Consider the case of a non-generalized patent val, or as I would say, an integer uniform map. What is the "integer" of the name here is the EDO or uniform scalar; note that other than the first term of the map pre-rounding, all of the other numbers in the map will always be reals, even for integer uniform maps / patent vals. Let's compare using the examples you gave yourself. {{map|17 26.944 39.473 47.72}} rounds to {{map|17 27 39 48}} and so that is the "patent val"/"(integer) uniform map" for 17, and {{map|17.1 27.103 39.705 48.006}} rounds to {{map|17 27 40 48}} and it is the "generalized patent val"/"uniform map" for 17.1. In both cases, all the entries in the final maps are integers. And in both cases, all of the entries in the not-yet-rounded maps besides the entry for prime 2 are reals. The only difference is whether the entry for prime 2 in the map before it is rounded is an integer or a real. Does it make sense now why "generalized patent val" is a reasonable term, and I why I'd disagree with you that there is "nothing generalized" about the final results? (Though again, I am defending our opponents' reasoning here; I think generalized patent val is ''reasonable'', sure, but that's hardly enough for it to qualify as ''good'' or ''great'' at its job... just look how much confusion it has caused here alraedy, and how much work we're having to do in order to get on the same page about it!)

:::::::: So the act of generalizing from integers to reals is not what "allows" things be exact, as you say. I can see now that you are using the word "exact maps" to name those not-yet-rounded maps such as {{map|17 26.944 39.473 47.72}}, {{map|17.1 27.103 39.705 48.006}}, {{map|17.45 27.658 40.518 48.988}} which I suggested above don't need to be named. So, no, this is not what I mean by "uniform". My term "uniform map" is completely synonymous with "generalized patent val", which is the name for maps like these ''after'' they have been rounded. As you put it, "the whole point of exact real-number edomappings is that you can derive ordinary inexact integral edomappings from them". Right. I agree. If I had to rewrite that statement myself I would write "the point of maps that are uniform scalings of the JIP is that you can derive uniform maps from them".

:::::::: You then say 'And because these three have been derived this way, they are more "reasonable" or "natural" than others which can't be. And "proper" is a much better term for that than "generalized".' I agree with all of your points here, and I now see what you mean by proper. But I think my proposed "uniform" is an even better term than "proper". That's because "uniform" is more descriptive. "Proper" is vague. When you used the word "proper" I had no idea what you meant. "Propriety" always requires further explanation about what qualities a thing is proper with respect to, while "uniformity" already gives you a sense of what the thing looks/feels/sounds like; uniform gives you the image of a perfectly straight vertical line drawn across the charts that I shared in my previous post, i.e. perfectly straight and not curved or wiggly or anything, which would be "unnatural" mapping choices. This is the same type of reasoning, actually, why FloraC above convinced me that your term "nearest" was superior to my term "simple" as a replacement for "patent"!

:::::::: As you say, "Using my proposed terminology, 17edo has exactly 9 proper 7-limit edomappings, one of which is the nearest edomapping. As you would expect, the nearest edomapping of any edo is always proper." Using ''my'' proposed terminology, then, 17edo has exactly 9 uniform 7-limit maps, one of which is the integer uniform map AKA the nearest map. I think my terminology is slightly more self-explanatory than yours.

:::::::: It looks like you're using the word "stretched" in the same sense as I'm using "scaled" in my explanations of "uniform", i.e. uniform scaling of the JIP before rounding. My word "scaled" supports both stretching and compressing already, so perhaps you would like to use it. But I don't think we should discuss "nearest stretched edomappings" until we've tied up some discussion points we've already got open. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 17:19, 29 September 2021 (UTC)

::::::::: OK, I understand now that ⟨17.1 27.103 39.705 48.006] is not a GPV. True, "proper" does need explanation. But it does seem appropriate for this. Hmm, still don't quite get the logic behind the term uniform, which the dictionary says means "identical or consistent, as from example to example" or "without variations in detail".

::::::::: I do like "scaled", thank you I will use it! I'm good with "nearest scaled edomappings". The phrase is admittedly a bit intimidating, but I could see it working. The newcomer should first learn about edomappings, then nearest edomappings, then scaled edomappings, then nearest scaled edomappings. We could call them NSEs or something, unless we call them proper/uniform. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 00:47, 30 September 2021 (UTC)

:::::::::: I'm glad we're on the same page now re: GPVs. I agree "proper" is a reasonable choice. I probably like it better than "generalized". But I still prefer "uniform". Of course, the fact that I need to provide extra explanation for "uniform" to you doesn't bode well for my case :) But let me give it a shot, leaning on the dictionary definition you provided. Please glance back up at my charts I pasted above. Again, the perfectly straight vertical lines I draw through the chart represent uniform maps. I suppose you could think of these lines, as you follow them vertically through the chart, as "choosing" the mapping for each prime. The fact that I require the line to be perfectly straight up-and-down is what makes it work. So if I had not uniformly scaled the lines per each of the primes, the line wouldn't be perfectly straight, and I wouldn't have a uniform map. That's the uniform part: uniform per prime, no variations in scale between them, identical and consistent scaling per prime. Does that work? As I explain it, I'm realizing that "straight map" might work just as well or better. What are your thoughts on that?

:::::::::: I'm glad you like "scaled". But I still prefer uniform map. I don't know what you mean by a "scaled edomapping" (one that's not a "nearest scaled edomapping"... what is scaled ''of'', then?). In my opinion a newcomer would first learn about maps, then uniform maps, then integer uniform maps. That's the order I present the ideas in my RTT How-To at present. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 01:36, 30 September 2021 (UTC)

::::::::::: A scaled edomapping is a mapping for a scaled edo, e.g. 16.9-edo. There are many possible edomappings for 16.9. One of them is the nearest scaled edomapping. The definition of proper/uniform edomapping is that it is also a nearest scaled edomapping for some scaling.

::::::::::: Oh I just had a horrible thought. When calculating tuning errors for unscaled edos, there's never an exact tie, because that would imply a JI comma of exactly 0 cents, which contradicts the unique factorization theorem. Because there's never an exact tie, there is only 1 nearest edomapping. BUT if we allow non-integral edos, ties are possible, and there can be two nearest edomappings!! For example there exists a number N near 12 such that 11/8 falls exactly midway between 5\N and 6\N. 11/8 = 5.5\N, and 551.3¢/1200¢ = 5.5 / N, and N = 5.5 * (1200 / 551.3) = about 11.97. This corresponds to the vertical line passing through the boundary between prime 11's 41 block and 42 block. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 07:35, 2 October 2021 (UTC)

== alternative proposal: add new page for uniform map ==

I am wondering how people here would feel about me adding a new page for "uniform map". Through discussion on this Talk page here, I have realized that my concerns about the current page go beyond merely terminological. My terminological concerns can be addressed by adding some parenthetical statements here and there. But my main concern is on a conceptual level, and I don't think it could be properly addressed without turning the page completely inside-out, which I don't think is reasonable.

The main problem is that I think the two topics are presented inside-out from the way that would be best. To be clear, I think it would be more logical to first present the version of this concept which uses real numbers as the basic kind ("uniform map"), and then introduce the integers-only version as a specific kind of that ("integer uniform map"). The current page does it the other way around, presenting the integer version as the basic kind ("patent val"), and then the reals version as a generalized kind of it ("generalized patent val").

I think both ways of presenting the concept are reasonable. And I think one could even make the case that these opposite perspectives on the concept are actually tantamount to two different conceptualizations of the shared mathematical reality — two conceptualizations which are each justified in having their own respective page to be documented on. I do think there are many people who would significantly benefit from my conceptualization, who are currently missing out on it.

So what would people think if I added a parallel page? This proposal assumes that the two pages should be firmly linked to each other, and be very clear and up-front about their synonymies. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 01:42, 4 October 2021 (UTC)

: Okay, I've gone ahead and done this now: [[uniform map]]. Comments and criticism welcome, of course. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:23, 12 December 2021 (UTC)

== Thoughts on changing "patent val," and other terminology changes in general ==

I just want to chime in that I also strongly disagree with changing "patent val" to "uniform map." If Doug + Dave want to do that for their pages then that's alright, but to the extent this is really a recommendation to make a general change to the Wiki then I strongly disagree with it. My thoughts pretty are much on the same page as FloraC on the matter, who has probably articulated it better than I could.

In general, if you have some proposal to change core RTT terminology, please also bring it to the attention of the [https://www.facebook.com/groups/xenwiki/permalink Facebook Xenwiki] group. [[User:Mike Battaglia|Mike Battaglia]] ([[User talk:Mike Battaglia|talk]]) 21:49, 16 November 2021 (UTC)

: Yes, strong agree on bringing proposals to the attention of that Facebook group. I would go even further and say that it's also important to run stuff like this by the very active XA Discord server's channel for the wiki. I was certainly planning on doing both of those before I would make any actual changes like this. I merely ''began'' here on the wiki discussion pages themselves, which seemed like a good place to test the waters before wasting wider audiences' time. And as you can see there hasn't been a lot of activity over the past month as we've been focusing on other things.

: Looking back on it, I can see that the original language with which I posted stuff here (which was pasted in September, but originally composed back in May!) was from a time when I felt a lot more bold about reforming this stuff. So yeah, I certainly don't think anymore that I could manage to demote "patent val" to a secondary term for this concept. I would be happy enough to be able to include links from this page to our work that say "Dave Keenan and Douglas Blumeyer use the term 'uniform map' for this," or whatever. Maybe one day it will earn the right to be listed with the main words, such as how Kite's "nearest edomapping" gets to be listed. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 22:11, 16 November 2021 (UTC)

:: That sounds good - it would really be nice if we could get a "Douglas + Dave Theory" main page of some kind so we could see this all organized at some point. (And I thought you went by Doug or is it always Douglas?) [[User:Mike Battaglia|Mike Battaglia]] ([[User talk:Mike Battaglia|talk]]) 23:00, 16 November 2021 (UTC)

::: I'm trying to go with "Douglas". Thanks for asking. Dave writes little on the wiki himself. Here's my work: https://en.xen.wiki/w/Douglas_Blumeyer#Some_of_his_work_here_on_the_wiki --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 23:38, 16 November 2021 (UTC)

=== Concern about the confusingness of nearest edomapping ===

It strikes me that the "nearest edomapping" would be the [[direct approximation]], so that the name is exactly a wrong self-description. Contrast with something like "nearest edomapping val" where the presence of the word "val" makes the meaning clearer. I really do not think it is a good idea to have this as a synonym for "patent val"; I don't think I've ever even seen it used. If it stays on the page at all, the name needs to be changed to something less confusing. --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 21:56, 31 January 2025 (UTC)

@@ Line 1: / Line 1: @@
 {{WSArchiveLink}}
+__toc__
 == 306c ==
@@ Line 50: / Line 53: @@
 :::: 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)
-::::: Yes, edomapping is supposed to be a substitute for val. Obvs I vote for nearest over simple/patent/obvious. I strongly agree that "val" creates an unnecessary barrier to understanding. Map or mapping is much better. I personally like edomapping even more because it is extremely self-explanatory. In a phrase like "the nearest edomapping for 17-edo" it is indeed redundant, but there I would just say "the nearest mapping for 17-edo". --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 07:04, 28 September 2021 (UTC)
+::::: Yes, edomapping is supposed to be a substitute for val. Obvs I vote for nearest over simple/patent/obvious. I strongly agree that "val" creates an unnecessary barrier to understanding. Map or mapping is much better. I personally like edomapping even more because it is extremely self-explanatory. In a phrase like "the nearest edomapping for 17-edo" it is indeed redundant, but there I would just say "the nearest mapping for 17-edo". See also my comment below in "Uniform map". --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 07:04, 28 September 2021 (UTC)
+:::::: By "it's already there" I was saying that ''nearest edomapping'' is in the first sentence of this article. And we're ready to propagate this term to other pages once the ''val'' vs ''map'' issue is resolved.
+:::::: So, no, I meant to say ''map'' was more popular. ''Val'' mainly arises in edos whereas ''map'' arises in higher-rank temps. The search giving more results of ''val''s may be attributed to the template. Hence the number of search results can't be evidence for use rates. The Shannon entropy argument is based on the premise that val is a word of below-average use rate so increased use rate makes the communication more efficient – interesting indeed as it may be a theoretical basis for the keep-people-familiar argument. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 09:15, 28 September 2021 (UTC)
+::::::: Hi Kite, thanks for joining this thread!
+::::::: Re: edomapping. Kite, we have different rankings of the terms. I would certainly rank your term "edomapping" way above "val", for the reason you give: it doesn't create a barrier to understanding. It's descriptive, which is something I fight for in terminology (and why I can see value in "nearest" over "simple"). But I still don't like it quite as much as "map" because it's a word that was made-up for xen, and so to a newcomer it will look weird and unfamiliar. We have a problematically off-putting amount of jargon in this domain, and terms like "edomapping" contribute to that. Also, "map" has better generalizable use; edomapping doesn't work for maps that don't include the octave, e.g. we could say {{map|13 19 23}} is the nearest map for 13-ED3, but we couldn't say it was the nearest edomapping.
+::::::: Re: "it's already there". I see, FloraC. You meant only the word "nearest" was already there. Right. Then indeed I agree that the term is ready for propagation, once the ''val'' vs ''map'' issue is resolved, although I would revise that last clause because it looks like it's actually the ''val'' vs ''map'' vs ''edomapping'' issue.
+::::::: But first I would like to give Dave Keenan a chance to chime in here, because he was the one who originally came up with "simple map". I know that he is generally amenable to the types of arguments given here for "nearest" over "simple", so I have some confidence that he'll like it, but personally I owe it to him to solicit his opinion directly. So I've just emailed him about this.
+::::::: Re: the relative popularity of map and val. Ah! Very interesting. I'm sorry that I guessed you had mistyped. I can see that two factors came together to lead me to assume you had accidentally written that "map" was more popular when you meant "val": 1) the amount of time I spend on Facebook and email with old-school RTT people who are steeped in Gene's jargon, where I am overwhelmingly exposed to "val" and in the minority of "map" users, and 2) my guess re: the meaning of this unfamiliar Shannon Entropy concept, which — due to some bad intuitions of mine — seems to be the exact opposite of what it really means (more on that in a bit). I hope you understand.
+::::::: Well, I'm encouraged to hear that what you actually think is that "map" is the one which is more popular; that tells me that the community is moving in the direction I prefer. I agree that many of the occurrences of "val" are coming from the template, but I had permitted those as evidence of popularity, at least insofar as people are regularly exposed to it and accepting of it. Anyway, I did say it was only an incredibly rough estimate, though, and I only said it that way when I assumed I was using it to help ''your'' case. :) But if it's only hurting both of our cases, then of course, for similar reasons, I am willing to go ahead and agree with you that it can't really be used for evidence here. (By the way, it is also heartening to know that the template has gotten enough buy-in that we could accomplish a lot of patent val -> something better by changing things at one single point!)
+::::::: Re: the Shannon Entropy thing. What I'm trying to say about my bad intuitions is this. I think that a situation where we have 2 terms we each use about half of the time or 3 terms we each use about a third of the time is a bad situation. I thought that was common sense, and so I assumed Shannon Entropy might be a fancy name for that idea (and here's a great piece of evidence where jargon and non-descriptive, in this case eponymous naming are creating a barrier to my understanding). I assumed that everyone would prefer standardization: a situation where we use a single term for a single thing almost all of the time and any other terms almost never. But if I'm understanding correctly now, it sounds like you're saying that we ''should'' strive for the situation where all of the words are used equally often? I'm probably still missing some important information, though. And I can't find any information about this "keep-people-familiar argument" concept you mention to help me make sense of it either. Sorry. If you want to convey these ideas to me more effectively, I would ask you to unpack these unfamiliar concepts for me, or find a simpler way that doesn't involve them. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 16:22, 28 September 2021 (UTC)
+:::::::: I understand what I'm tryna argue is counterintuitive. Maybe I failed to make the context clear. It's this: ''val'' can't be replaced entirely by ''map''. You can replace this word in the phrase ''patent val'', but beyond this phrase, it can't be replaced by all occurrences. It turns up in all the temp pages, for example, where simply replacing the lines of ''vals'' to ''maps'' isn't appropriate. It has to do with the concern that ''val'' isn't totally synonymous with ''map''. ''Val'' or ''edomapping'' (I reckon these two are synonymous) emphasises itself being an individual row of the map. Therefore, ''val'' remains a word that's likely to be encountered by those who work with RTT even if it's removed from the phrase ''patent val''. That's why we hope to keep people familiar with both terms by using the term of lower use rate more, which can be explained through Shannon entropy. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 01:26, 29 September 2021 (UTC)
+::::::::: If we can't agree on a replacement for "val", there seems little point in pursuing the other proposed terminology changes. So, Kite and/or Flora, please explain why you claim that "edomapping" is a suitable replacement for "val" when, as Douglas mentioned, vals need not be related to EDOs at all, e.g. they may be ED3 maps, or as the [[Val]] article says, "It's very common for vals to refer to EDOs specifically, although they also show us how to relate larger chains of generators to JI as well (such as a stack of meantone fifths)". i.e. a val can be a single row of a mapping for a temperament of rank greater than 1, and therefore not directly related to an ED of any kind. In short: "non-edo val" makes perfect sense while "non-edo edomapping" does not.
+::::::::: And in case that isn't enough, the [[Mapping]] article makes it clear that a "mapping" is a ''list'' of vals, which can be viewed as a matrix. Of course some mappings contain only one val, and so a val could be considered to be a rank-1 mapping. But it would be somewhat circular to define a mapping as a list of rank-1 mappings, as seems to be implied by your clam that "edomapping" is synonymous with "val".
+::::::::: And please explain what prevents us from defining "map" in RTT as synonymous with "val", given that the [[Val]] article begins, "A val is a linear map representing ...". I see that [[Map]] currently redirects to [[Mapping]], but I see no reason why it must do so. Why not use the shorter term "map" for the lower-level objects of which mappings are composed? And aren't we more likely to succeed in replacing "val" in people's existing usage, if the replacement has only one syllable, like the original? And "bimap", "trimap", "multimap" work so much better than "biedomapping", "triedomapping", "multiedomapping", as replacements for "bival", "trival" and "multival" in the exterior algebra formulation. --[[User:Dave Keenan|Dave Keenan]] ([[User talk:Dave Keenan|talk]]) 04:40, 5 October 2021 (UTC)
+:::::::::: Aren't ''mapping'' and ''map'' just the same word in different inflections? I don't see how anyone would use them for different entities instead of interchangeably. It only makes things confusing. Also switching to ''mapping'' from ''map'' is a relatively recent change I believe.
+:::::::::: ''Edomapping'' is synonymous with ''val'' because it's meant to be so. The circular definition problem is independent of names. If you define a val as a single row of the mapping and the mapping as a list of vals, it's circular definition whatever you call it. That said, I agree that it's less appropriate for non-edo vals and that's why I'd stick to ''val''.
+:::::::::: Finally, if you're planning to replace every occurrence of ''val'': how about the "vals" in each temp page? [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 08:44, 5 October 2021 (UTC)
+::::::::: It is true that, in mathematics generally, ''mapping'' and ''map'', when used as nouns, are synonyms, and both are synonymous with ''function''. But there is very little difference between an individual row of a mapping, and a mapping with only one row. So if we were to agree that, in RTT, only an individual row should be called a ''map'', and someone new to the field assumes that a map is the same as a mapping, then there are almost no consequences of that temporary confusion, if it can even be called confusion. For 12edo, its 5-limit ''map'' is ⟨12 19 28], and its 5-limit ''mapping'' is [⟨12 19 28]⟩. The mnemonic is simple: The shorter term applies to the smaller object. The difference rarely matters to anyone, but when it does, at least we would have descriptive terms rather than the confusing and unnecessary jargon of "val", which acts as a barrier to understanding.
+::::::::: You may be aware that I am one of the founders of regular temperament theory along with Paul Erlich, Graham Breed, Gene Smith and others, since 1998. In online discussions of regular temperaments, and in our writings, all four of us have referred to any array of numbers whose units are "generators per prime", as a mapping, ever since we first referred to them as anything at all, which seems to have been in early 2001. Only rarely has this been shortened to "map" — typically only as a heading in tables of temperament data generated by Gene Smith. But even Gene is on record as defining a "prime mapping" as a "list of vals", here: http://www.tonalsoft.com/enc/p/prime-mapping.aspx
+::::::::: I didn't rely on my memory for the above, but spent several hours going through the results of the following tuning archive searches:
+::::::::: site:yahootuninggroupsultimatebackup.github.io "mapping"
+::::::::: site:yahootuninggroupsultimatebackup.github.io "map"
+::::::::: Of course most of the temperament data in the Xen Wiki was generated by Gene, so it is not surprising if it contained "map" as an abbreviation of "mapping". So I assume, when you say that switching to ''mapping'' from ''map'' is a relatively recent change, you are referring to someone having expanded these occurrences of "map" to "mapping". That would be a good thing. It would make them consistent with the output from Graham Breed's temperament finder, and it would open the way to defining "map" as synonymous with "val".
+::::::::: In the Xen Wiki and Graham Breed's temperament finder and the tuning archives, [there is a case in which*] the term "map" (and not "mapping") already consistently refers to an individual row of the form ⟨...]. This is in the case of a "tuning map", which maps from generators to cents. This is a map in "tuning space". By analogy, a val is therefore a map in "temperament space", and so it would be perfectly consistent with existing terminology, to refer to a val as a "temperament map" as opposed to a temperament mapping. We are merely proposing that an unqualified "map" should be assumed to be a temperament map, i.e. a val, not a tuning map. Or at least that when it is clear from the context that it is a temperament map, the qualifier "temperament" can be dropped. [*clarification added 30 Dec 2021] --[[User:Dave Keenan|Dave Keenan]] ([[User talk:Dave Keenan|talk]]) 16:29, 6 October 2021 (UTC)
+:::::::::: I guess I agree that ''map'' is a possible replacement for ''val'', but my point has always been practical. What's the plan? How do you make all the RTT users forget about ''val''? How about all these pages? The letter ''V'' in the formulae? [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 00:24, 7 October 2021 (UTC)
+:::::::::: And with so many legacies, I must oppose this change since I oppose forced language reforms. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 00:38, 7 October 2021 (UTC)
+::::::::: Thanks FloraC.
+::::::::: It is arguable that the introduction of ''val'' was a forced language reform since, before that, and after, tuning list contributors were happy to use descriptive terms like "ET mapping" and "mapping row". So arguably, ''if'' we replaced ''val'' we would merely be ''undoing'' a forced language reform.
+::::::::: However I don't actually want to replace any existing occurrences of ''val''. I only want to ensure that the way is open for Douglas to use ''map'' as a synonym for it, in his excellent pedagogical articles. And for others to use ''map'' in that way, if they choose, going forward.
+::::::::: The first thing to do in that regard would be to redirect "Map" to the "Val" page instead of the "Mapping" page, and to mention ''map'' as a synonym near the start of the "Val" page.
+::::::::: The only other thing would be to check all existing (whole-word) occurrences of "map" in the wiki (outside of Douglas' articles), and if they refer to a matrix, as opposed to a row vector ⟨...], expand them to "mapping". --[[User:Dave Keenan|Dave Keenan]] ([[User talk:Dave Keenan|talk]]) 09:41, 8 October 2021 (UTC)
+:::::::::: However val was introduced in the first place, it's the status quo and what's undoing of language reform is simultaneously another layer of language reform. Anyway, you've clearly presented the feasible first steps to switch to ''map'' and I'll follow, although I'd like to make ''map'' a disambiguation page to catch all the usage. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 11:26, 8 October 2021 (UTC)
+::::::::: I dislike val strongly because the dictionary says it's an abbreviation for value. Which is not only vague, but also misleading because there are multiple values in a single val. I don't see why val can't be replaced with something better. I still like edomapping. I think it's the opposite of jargon, because it's very self-explanatory. For the ED3 case, I propose edt-mapping or ed3-mapping. For the general case of rank-1 mappings that aren't edos, I propose edonoi-mapping. In other words, you just specify what the mapping is used for in the name. For the even more general case of the combination of edomappings and edonoi-mappings, I propose rank-1 mapping. For everything outside of that, I propose mapping-row. I'm OK with mapping being shortened to map in any or all of these cases. I'm also OK with hyphenating, e.g. edo-map or edo-mapping. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 06:29, 9 October 2021 (UTC)
+::::::::::That's a good solution. Thanks FloraC.
+::::::::::Kite, I find all those terms you suggest above to be acceptable (except I don't know what "edonoi" means). I have used many of them myself in the past. But none of them is a potential replacement for "val" since vals include both "rank-1 mappings" and "mapping rows". Douglas and I have chosen to use "map" for this purpose in our pedagogical materials, thereby giving it a more specific meaning than "mapping" within the domain of tuning theory. --[[User:Dave Keenan|Dave Keenan]] ([[User talk:Dave Keenan|talk]]) 06:45, 10 October 2021 (UTC)
+::::::::::: EDONOI means equal division of a non-octave interval. It's a fairly widespread term. "none of them is a potential replacement for val" I'm proposing edonoi-mapping, mapping-row etc. as replacements for specific use cases of val, and the term map or mapping as the general replacement for val. So I think we agree that val can be completely replaced by map/mapping. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 21:09, 16 October 2021 (UTC)
 == proposal to rename "generalize patent val" to "uniform map" ==
@@ Line 85: / Line 156: @@
 :::: 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)
+::::: "Uniform" isn't very self-explanatory, IMO. I propose replacing GPV with "exact edomapping" or possibly non-integral or decimal edomapping. But in practice the GPV gets rounded off anyway, and none of these terms apply, not even uniform. In fact I must admit I'm confused what precisely a GPV is. I would think it's an exact, non-integral edomapping, and rounding it off turns it into a normal (i.e. integral) edomapping. But the article says "We can show that ⟨17 27 40] is a generalized patent val".
+::::: I think the whole concept of GPV would be much clearer if 1) GPV means only an exact un-rounded-off edomapping, and 2) there is a separate term for an integral edomapping that can result from rounding off a GPV. I propose "proper edomapping", which includes 17 and 17c and even 17bbccc (the ⟨17 28 41] of the article) but not 17cc or 17ccc. This seems to be the whole point of GPVs, to create a rigorous definition of proper and improper edomappings.
+::::: I'd also like to note that "exact edomapping" makes sense but "exact map" or "exact mapping" doesn't. Because there's no point in generalizing the meantone mapping [⟨1 0 -4], ⟨0 1 4]]. Point being, there are times when one wants to say edomapping not mapping (see my comment in the "simple map" discussion above). --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 08:09, 28 September 2021 (UTC)
+:::::: I agree that "uniform" is not self-explanatory. But I don't think self-explanatory-ness should be a target for terminology. I think it's only necessary that terms are descriptive. I think "generalized patent val" is also not self-explanatory, so it's not a relative point against "uniform map".
+:::::: Unfortunately, I'm having trouble figuring out how best to reply to the rest of your thoughts and suggestions here. As you admit, you feel confused about what precisely this concept is, and it seems likely to me that you do have some misconception about it, because I can't follow much of your thinking, or reconcile many of your statements with my understanding of the ideas here. So perhaps we should both pause making suggestions or criticisms involving terminology, and first make sure that we're all on the same page about the structure itself.
+:::::: I love visual explanations myself and hope that this one will be helpful to you, too. Uniform maps (or GPVs) finally clicked for me when a guy on the Discord server named Dead Shaman shared a special type of chart with me. I adapted his chart for use in my RTT How-To, where I explain that a uniform map is any map that can be found at a vertical line drawn through it. Here's an example (there's a lot of other stuff going on in these charts that's not necessary, so no need to understand everything):
+[[File:Near linings up rare2.png|thumb|center|700px]]
+:::::: And that is why the example you were surprised about, {{map|17 27 40}}, is indeed a uniform map, because you can see it drawn as such a vertical line in another area of that chart, as seen here:
+[[File:17-ET.png|thumb|center|200px]]
+:::::: Please let me know if this explanation helps, or if you have any other questions. FloraC and I have also provided alternative explanations of the concept in our discussion above that aren't present in the article itself (yet... maybe we'll rework it soon), so if you are unfamiliar with those explanations, they may prove helpful as well. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 16:48, 28 September 2021 (UTC)
+::::::: I understand the math perfectly well. I understand the diagram too. What I don't understand is the terminology. Generalized in this context means generalized from integers to real numbers, right? Which allows the numbers to be exact, e.g. 3/1 is exactly 26.944/17 the size of 2/1, hence ⟨17 26.944] is an exact edomapping. And exact is what you mean by uniform, right? But nobody actually uses these real-number edomappings. Instead, the real numbers are rounded to integers. Which makes them not generalized, and not exact. So I don't understand, or more bluntly I strongly object to, calling the rounded edomappings generalized.
+::::::: In other words, here's three of what I would call generalized PVs: ⟨17 26.944 39.473 47.725] and ⟨17.1 27.103 39.705 48.006] and ⟨17.45 27.658 40.518 48.988]. And here's what you get when you round them: ⟨17 27 39 48] and ⟨17 27 40 48] and ⟨17 28 41 49]. But there's nothing generalized about those last three. They are ordinary edomappings. But the whole point of exact real-number edomappings is that you can derive ordinary inexact integral edomappings from them. And because these three have been derived this way, they are more "reasonable" or "natural" than others which can't be. And "proper" is a much better term for that than "generalized". So IMO any edomapping through which you can draw a vertical line on the diagram and hit every component rectangle should be called a proper edomapping, and any one that you can't do this with should be called an improper edomapping.
+::::::: Using my proposed terminology, 17edo has exactly 9 proper 7-limit edomappings, one of which is the nearest edomapping. As you would expect, the nearest edomapping of any edo is always proper. Using the current terminology, 17edo has 9 GPVs. One of them is the patent val, plus there's 8 non-patent vals. But each of those non-patent val is also a generalized patent val. So even though they're non-patent, they still have "patent" in the name. Which is confusing. This confusion goes away when you use the term proper.
+::::::: Interesting side point: 17edo's smallest (i.e. contains the smallest numbers) proper edomapping is ⟨17 26 38 46]. And 16edo's largest is ⟨16 26 38 46]. The last 3 numbers are the same because 16.5 can be rounded up to 17 or down to 16. In other words, 16.5-edo is both stretched 17edo and compressed 16edo. In fact the whole section on GPVs might be improved by explicitly discussing stretched edos. We could even call GPVs stretched edomappings, if we use the word stretched loosely to mean both stretched and compressed and also neither one. Then what I'm calling proper edomappings would be called nearest stretched edomappings. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 08:40, 29 September 2021 (UTC)
+:::::::: Ah! Sorry. I did not mean to insult your intelligence or otherwise offend. As soon as I saw your reply, I remembered that when I drafted my previous post, I had the flicker of a thought that I should say something like "or maybe you do totally understand the concept but I just need you to clarify what you mean by 'exact' and 'proper'". I regret failing to follow through on that now. And you've gone ahead and done it for me. Thank you for that. Your full explanation lets me see that we're actually just about on the same page, so that's great.
+:::::::: To be clear, I am the one who made the original post here arguing against the terminology "generalized patent val". You don't have to convince me that it's bad; we agree on that. I do think FloraC here still supports it to some extent, so arguments presented against it are still useful. I myself have elsewhere made the point you make above about how putting the words "generalized" and "patent" together is already confusing; I see that I didn't make it myself above in my original post, so I'd like to explicitly say that I second that point.
+:::::::: You are correct so far when you say that the "generalized" part of "generalized patent val" means "from integers to reals". (And I'll take this opportunity to reiterate my position that it's more logical to structure it the other way around: defining a basic concept for the reals, i.e. uniform maps, and then specify integers when appropriate, i.e. integer uniform maps, AKA simple maps / patent vals / nearest edomappings.)
+:::::::: However, I think you have the wrong idea about which numbers exactly that "generalized patent vals" are supposed to be thought of as generalizing from integers from reals. So, to be clear, I am choosing to assist my opponents here by clarifying their reasoning, but of course I want us to have a fair consideration of each other's ideas at their best and clearest. And as far as I can tell, it seems to be the case that you think "generalized patent vals" generalize ''all of the entries in the map'' from integers to reals, but that is not correct. ''Only the EDO number'' that is used in the otherwise identical process for computing a patent val is generalized. Or as I prefer to think about it, what is generalized is the ''multiplier'' that the terms of the JIP (i.e. {{map|log₂2 log₂3 log₂5 ...}}) are uniformly scaled by (except, again, I prefer to say that the default case is that this uniform multiplier is real, and if you need it to be integer, you say so).
+:::::::: You say that "nobody actually uses these real-number edomappings (directly)" and I agree with that. That's a big reason why structures like {{map|17 26.944 39.473 47.72}}, {{map|17.1 27.103 39.705 48.006}}, {{map|17.45 27.658 40.518 48.988}} are ''not'' what we've given the name "generalized patent val"/"uniform map" for. You say that those ''are'' the structures that the name "generalized patent vals" makes sense for, and while I agree that generalized patent val ''could'' be a reasonable name for them if anyone wanted to name them, I don't believe there's a wide desire or any good reason to name these such structures at all. They don't have enough value in and of themselves. They are merely intermediate states before being rounded to the structures of value that are worth being named, i.e. "generalized patent vals"/"uniform maps" (I had to check your numbers here to make sure I understood what points you were illustrating with them — and yes, these are all indeed valid uniform scalings of the JIP which upon rounding would therefore give you GPVs/uniform maps).
+:::::::: Consider the case of a non-generalized patent val, or as I would say, an integer uniform map. What is the "integer" of the name here is the EDO or uniform scalar; note that other than the first term of the map pre-rounding, all of the other numbers in the map will always be reals, even for integer uniform maps / patent vals. Let's compare using the examples you gave yourself. {{map|17 26.944 39.473 47.72}} rounds to {{map|17 27 39 48}} and so that is the "patent val"/"(integer) uniform map" for 17, and {{map|17.1 27.103 39.705 48.006}} rounds to {{map|17 27 40 48}} and it is the "generalized patent val"/"uniform map" for 17.1. In both cases, all the entries in the final maps are integers. And in both cases, all of the entries in the not-yet-rounded maps besides the entry for prime 2 are reals. The only difference is whether the entry for prime 2 in the map before it is rounded is an integer or a real. Does it make sense now why "generalized patent val" is a reasonable term, and I why I'd disagree with you that there is "nothing generalized" about the final results? (Though again, I am defending our opponents' reasoning here; I think generalized patent val is ''reasonable'', sure, but that's hardly enough for it to qualify as ''good'' or ''great'' at its job... just look how much confusion it has caused here alraedy, and how much work we're having to do in order to get on the same page about it!)
+:::::::: So the act of generalizing from integers to reals is not what "allows" things be exact, as you say. I can see now that you are using the word "exact maps" to name those not-yet-rounded maps such as {{map|17 26.944 39.473 47.72}}, {{map|17.1 27.103 39.705 48.006}}, {{map|17.45 27.658 40.518 48.988}} which I suggested above don't need to be named. So, no, this is not what I mean by "uniform". My term "uniform map" is completely synonymous with "generalized patent val", which is the name for maps like these ''after'' they have been rounded. As you put it, "the whole point of exact real-number edomappings is that you can derive ordinary inexact integral edomappings from them". Right. I agree. If I had to rewrite that statement myself I would write "the point of maps that are uniform scalings of the JIP is that you can derive uniform maps from them".
+:::::::: You then say 'And because these three have been derived this way, they are more "reasonable" or "natural" than others which can't be. And "proper" is a much better term for that than "generalized".' I agree with all of your points here, and I now see what you mean by proper. But I think my proposed "uniform" is an even better term than "proper". That's because "uniform" is more descriptive. "Proper" is vague. When you used the word "proper" I had no idea what you meant. "Propriety" always requires further explanation about what qualities a thing is proper with respect to, while "uniformity" already gives you a sense of what the thing looks/feels/sounds like; uniform gives you the image of a perfectly straight vertical line drawn across the charts that I shared in my previous post, i.e. perfectly straight and not curved or wiggly or anything, which would be "unnatural" mapping choices. This is the same type of reasoning, actually, why FloraC above convinced me that your term "nearest" was superior to my term "simple" as a replacement for "patent"!
+:::::::: As you say, "Using my proposed terminology, 17edo has exactly 9 proper 7-limit edomappings, one of which is the nearest edomapping. As you would expect, the nearest edomapping of any edo is always proper." Using ''my'' proposed terminology, then, 17edo has exactly 9 uniform 7-limit maps, one of which is the integer uniform map AKA the nearest map. I think my terminology is slightly more self-explanatory than yours.
+:::::::: It looks like you're using the word "stretched" in the same sense as I'm using "scaled" in my explanations of "uniform", i.e. uniform scaling of the JIP before rounding. My word "scaled" supports both stretching and compressing already, so perhaps you would like to use it. But I don't think we should discuss "nearest stretched edomappings" until we've tied up some discussion points we've already got open. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 17:19, 29 September 2021 (UTC)
+::::::::: OK, I understand now that ⟨17.1 27.103 39.705 48.006] is not a GPV. True, "proper" does need explanation. But it does seem appropriate for this. Hmm, still don't quite get the logic behind the term uniform, which the dictionary says means "identical or consistent, as from example to example" or "without variations in detail".
+::::::::: I do like "scaled", thank you I will use it! I'm good with "nearest scaled edomappings". The phrase is admittedly a bit intimidating, but I could see it working. The newcomer should first learn about edomappings, then nearest edomappings, then scaled edomappings, then nearest scaled edomappings. We could call them NSEs or something, unless we call them proper/uniform. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 00:47, 30 September 2021 (UTC)
+:::::::::: I'm glad we're on the same page now re: GPVs. I agree "proper" is a reasonable choice. I probably like it better than "generalized". But I still prefer "uniform". Of course, the fact that I need to provide extra explanation for "uniform" to you doesn't bode well for my case :) But let me give it a shot, leaning on the dictionary definition you provided. Please glance back up at my charts I pasted above. Again, the perfectly straight vertical lines I draw through the chart represent uniform maps. I suppose you could think of these lines, as you follow them vertically through the chart, as "choosing" the mapping for each prime. The fact that I require the line to be perfectly straight up-and-down is what makes it work. So if I had not uniformly scaled the lines per each of the primes, the line wouldn't be perfectly straight, and I wouldn't have a uniform map. That's the uniform part: uniform per prime, no variations in scale between them, identical and consistent scaling per prime. Does that work? As I explain it, I'm realizing that "straight map" might work just as well or better. What are your thoughts on that?
+:::::::::: I'm glad you like "scaled". But I still prefer uniform map. I don't know what you mean by a "scaled edomapping" (one that's not a "nearest scaled edomapping"... what is scaled ''of'', then?). In my opinion a newcomer would first learn about maps, then uniform maps, then integer uniform maps. That's the order I present the ideas in my RTT How-To at present. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 01:36, 30 September 2021 (UTC)
+::::::::::: A scaled edomapping is a mapping for a scaled edo, e.g. 16.9-edo. There are many possible edomappings for 16.9. One of them is the nearest scaled edomapping. The definition of proper/uniform edomapping is that it is also a nearest scaled edomapping for some scaling.
+::::::::::: Oh I just had a horrible thought. When calculating tuning errors for unscaled edos, there's never an exact tie, because that would imply a JI comma of exactly 0 cents, which contradicts the unique factorization theorem. Because there's never an exact tie, there is only 1 nearest edomapping. BUT if we allow non-integral edos, ties are possible, and there can be two nearest edomappings!! For example there exists a number N near 12 such that 11/8 falls exactly midway between 5\N and 6\N. 11/8 = 5.5\N, and 551.3¢/1200¢ = 5.5 / N, and N = 5.5 * (1200 / 551.3) = about 11.97. This corresponds to the vertical line passing through the boundary between prime 11's 41 block and 42 block. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 07:35, 2 October 2021 (UTC)
+== alternative proposal: add new page for uniform map ==
+I am wondering how people here would feel about me adding a new page for "uniform map". Through discussion on this Talk page here, I have realized that my concerns about the current page go beyond merely terminological. My terminological concerns can be addressed by adding some parenthetical statements here and there. But my main concern is on a conceptual level, and I don't think it could be properly addressed without turning the page completely inside-out, which I don't think is reasonable.
+The main problem is that I think the two topics are presented inside-out from the way that would be best. To be clear, I think it would be more logical to first present the version of this concept which uses real numbers as the basic kind ("uniform map"), and then introduce the integers-only version as a specific kind of that ("integer uniform map"). The current page does it the other way around, presenting the integer version as the basic kind ("patent val"), and then the reals version as a generalized kind of it ("generalized patent val").
+I think both ways of presenting the concept are reasonable. And I think one could even make the case that these opposite perspectives on the concept are actually tantamount to two different conceptualizations of the shared mathematical reality — two conceptualizations which are each justified in having their own respective page to be documented on. I do think there are many people who would significantly benefit from my conceptualization, who are currently missing out on it.
+So what would people think if I added a parallel page? This proposal assumes that the two pages should be firmly linked to each other, and be very clear and up-front about their synonymies. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 01:42, 4 October 2021 (UTC)
+: Okay, I've gone ahead and done this now: [[uniform map]]. Comments and criticism welcome, of course. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:23, 12 December 2021 (UTC)
+== Thoughts on changing "patent val," and other terminology changes in general ==
+I just want to chime in that I also strongly disagree with changing "patent val" to "uniform map." If Doug + Dave want to do that for their pages then that's alright, but to the extent this is really a recommendation to make a general change to the Wiki then I strongly disagree with it. My thoughts pretty are much on the same page as FloraC on the matter, who has probably articulated it better than I could.
+In general, if you have some proposal to change core RTT terminology, please also bring it to the attention of the [https://www.facebook.com/groups/xenwiki/permalink Facebook Xenwiki] group. [[User:Mike Battaglia|Mike Battaglia]] ([[User talk:Mike Battaglia|talk]]) 21:49, 16 November 2021 (UTC)
+: Yes, strong agree on bringing proposals to the attention of that Facebook group. I would go even further and say that it's also important to run stuff like this by the very active XA Discord server's channel for the wiki. I was certainly planning on doing both of those before I would make any actual changes like this. I merely ''began'' here on the wiki discussion pages themselves, which seemed like a good place to test the waters before wasting wider audiences' time. And as you can see there hasn't been a lot of activity over the past month as we've been focusing on other things.
+: Looking back on it, I can see that the original language with which I posted stuff here (which was pasted in September, but originally composed back in May!) was from a time when I felt a lot more bold about reforming this stuff. So yeah, I certainly don't think anymore that I could manage to demote "patent val" to a secondary term for this concept. I would be happy enough to be able to include links from this page to our work that say "Dave Keenan and Douglas Blumeyer use the term 'uniform map' for this," or whatever. Maybe one day it will earn the right to be listed with the main words, such as how Kite's "nearest edomapping" gets to be listed. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 22:11, 16 November 2021 (UTC)
+:: That sounds good - it would really be nice if we could get a "Douglas + Dave Theory" main page of some kind so we could see this all organized at some point. (And I thought you went by Doug or is it always Douglas?) [[User:Mike Battaglia|Mike Battaglia]] ([[User talk:Mike Battaglia|talk]]) 23:00, 16 November 2021 (UTC)
+::: I'm trying to go with "Douglas". Thanks for asking. Dave writes little on the wiki himself. Here's my work: https://en.xen.wiki/w/Douglas_Blumeyer#Some_of_his_work_here_on_the_wiki --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 23:38, 16 November 2021 (UTC)
+=== Concern about the confusingness of nearest edomapping ===
+It strikes me that the "nearest edomapping" would be the [[direct approximation]], so that the name is exactly a wrong self-description. Contrast with something like "nearest edomapping val" where the presence of the word "val" makes the meaning clearer. I really do not think it is a good idea to have this as a synonym for "patent val"; I don't think I've ever even seen it used. If it stays on the page at all, the name needs to be changed to something less confusing. --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 21:56, 31 January 2025 (UTC)