Xenharmonic Wiki talk:Things to do: Difference between revisions
→Comma tables in EDO pages: re 2x |
|||
| Line 215: | Line 215: | ||
: I'm in favor of monzos for every comma. I don't like having to factor e.g. 352/351 into component primes. Hurts my head :). There should be a ratio column too, but for large ratios, it should be blank or else just say e.g. "9 digits". I also really like having the color name in there, but I'm biased :) The cents is useful too. Don't see the point of deleting all this info. I think if a comma needs a comment, that comma should be discussed in the theory section of the edo page. That will avoid a mostly empty column that takes up lots of room horizontally. I agree with Godtone (cool name BTW) that the theory section shouldn't merely list commas, since the table does that. The prime limit column can be dropped if for each prime limit we have a gray header row that is one big merged cell going clear across the table. The first row says "3-limit commas", next row is the one 3-limit comma, next row says "5-limit commas", next come all the 5-limit commas, etc. This makes the table narrower. That's good because there's always more room vertically, but not horizontally. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 02:50, 12 January 2021 (UTC) | : I'm in favor of monzos for every comma. I don't like having to factor e.g. 352/351 into component primes. Hurts my head :). There should be a ratio column too, but for large ratios, it should be blank or else just say e.g. "9 digits". I also really like having the color name in there, but I'm biased :) The cents is useful too. Don't see the point of deleting all this info. I think if a comma needs a comment, that comma should be discussed in the theory section of the edo page. That will avoid a mostly empty column that takes up lots of room horizontally. I agree with Godtone (cool name BTW) that the theory section shouldn't merely list commas, since the table does that. The prime limit column can be dropped if for each prime limit we have a gray header row that is one big merged cell going clear across the table. The first row says "3-limit commas", next row is the one 3-limit comma, next row says "5-limit commas", next come all the 5-limit commas, etc. This makes the table narrower. That's good because there's always more room vertically, but not horizontally. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 02:50, 12 January 2021 (UTC) | ||
: Slightly off topic, but I would rather patent vals be octave reduced, so that ⟨41 65 95 115 142...] becomes ⟨41 24 13 33 19...]. Less mathematician- | : Slightly off topic, but I would rather patent vals be octave reduced, so that ⟨41 65 95 115 142...] becomes ⟨41 24 13 33 19...]. Less mathematician-friendly, but more musician-friendly. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 03:11, 12 January 2021 (UTC) | ||
:: Duplication of information is a severe problem we discussed. The tendency to copy&past from table to table raises the danger of spreading errors and making much more work... That's the problem I have with all that information. I had much hope in your comments, @Kite, but to be honest, I still don't see in how far this information will be helpful for you. Just saying I like it is not enough in my opinion. Can you please explain your personal use of comma information? --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 06:31, 12 January 2021 (UTC) | :: Duplication of information is a severe problem we discussed. The tendency to copy&past from table to table raises the danger of spreading errors and making much more work... That's the problem I have with all that information. I had much hope in your comments, @Kite, but to be honest, I still don't see in how far this information will be helpful for you. Just saying I like it is not enough in my opinion. Can you please explain your personal use of comma information? --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 06:31, 12 January 2021 (UTC) | ||
| Line 228: | Line 228: | ||
::: I'd also like to point out that wikipedia has tons of duplication. To pick a random example, the page for Barack Obama has a lengthy section on his presidency. It has an even longer page solely about his presidency. Plus another page solely about his first 100 days. Lots and lots of duplication. I mention this because I figure wikipedia knows what they're doing, and obviously they have decided that duplication is not a problem. I also question your use of "severe" to describe the issue. How many actual reduplicated errors have you seen recently? --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 01:01, 15 January 2021 (UTC) | ::: I'd also like to point out that wikipedia has tons of duplication. To pick a random example, the page for Barack Obama has a lengthy section on his presidency. It has an even longer page solely about his presidency. Plus another page solely about his first 100 days. Lots and lots of duplication. I mention this because I figure wikipedia knows what they're doing, and obviously they have decided that duplication is not a problem. I also question your use of "severe" to describe the issue. How many actual reduplicated errors have you seen recently? --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 01:01, 15 January 2021 (UTC) | ||
:::: Okay, seems we have to find another way to do reduce duplication or ensure correctness. In my opinion, we then should leave it for now as it is. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 07:32, 15 January 2021 (UTC) | |||
:: The octave reduced version of (patent) vals can easily be added in EDO pages, but in this case the first value would be zero. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 06:31, 12 January 2021 (UTC) | :: The octave reduced version of (patent) vals can easily be added in EDO pages, but in this case the first value would be zero. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 06:31, 12 January 2021 (UTC) | ||
::: The first value needn't be zero if you define octave-reduction appropriately. Which we should, because the zero doesn't convey any useful information. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 01:01, 15 January 2021 (UTC) | ::: The first value needn't be zero if you define octave-reduction appropriately. Which we should, because the zero doesn't convey any useful information. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 01:01, 15 January 2021 (UTC) | ||
:::: This kind of argumentation does not convince me at all. We don't need to redefine a well-known concept to justify a non-zero cell in a table. If we have the tables about prime intervals (and we have and will have even more of it) all that information will be obvious. I'm planning a layout which has two separate rows (original values and octave-reduced ones i.e. <code>v % edo</code>), it's somewhat like the table in [[User:Xenwolf/Fifthspan#Separate mod steps]] (without the ''fifthspan explained'' rows). It's possible to produce tables like this automatically. The only thing (after implementing fifthspan calculation in Lua, after having it done in Python) is to figure out appropriate coloring or border styles for better orientation in the then bigger table. IOW: let the [[patent val]]s be as they are: we will have a more obvious presentation of the information you wish. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 07:32, 15 January 2021 (UTC) | |||