Talk:Patent val: Difference between revisions
Line 85: | Line 85: | ||
:::: 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) | :::: 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) |