Xenharmonic Wiki talk:Conventions: Difference between revisions
m →EDO vs. edo (and MOS vs. mos): Fixed link to page TAMNAMS |
{{High priority}} |
||
(10 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
{{High priority}} | |||
== [[List model]] == | == [[List model]] == | ||
Line 57: | Line 59: | ||
Similarly, I would suggest "mos" instead of "MOS" for common usage on the Wiki, while preserving the main variants in strategic places like page intros. The page [[TAMNAMS]] is an example of a case where "mos" is used both as a standalone word and within new terms like mosstep. [[User:Fredg999|Fredg999]] ([[User talk:Fredg999|talk]]) 20:35, 4 July 2021 (UTC) | Similarly, I would suggest "mos" instead of "MOS" for common usage on the Wiki, while preserving the main variants in strategic places like page intros. The page [[TAMNAMS]] is an example of a case where "mos" is used both as a standalone word and within new terms like mosstep. [[User:Fredg999|Fredg999]] ([[User talk:Fredg999|talk]]) 20:35, 4 July 2021 (UTC) | ||
: Here is a short extract of arguments (I already sent it to FloraC via PM) that may add to the discussion:<syntaxhighlight lang="text"> | |||
* the XenWiki is open to the public so it should be maximally readable | |||
* some people prefer 123EDO which obfuscates the number boundary | |||
* in 12345edo the number is also much harder to read than in 12345-EDO | |||
* the 123 EDO convention leads to lots of confusing line breaks | |||
* 123edo is easier to type, maybe only this caused the old convention | |||
* 123abe, the val notation, is optical close to it, bad for skimming | |||
Yes, changing a convention causes a lot of work. But why should the old | |||
convention stay, is it really that helpful? | |||
Yes, the 123-EDO rule will complicate typing: you need the shift key. | |||
But isn't easy-to-read text always hard to write?</syntaxhighlight> | |||
: Now I think we should not forget about the format <code>"%d-edo"</code> (''number''+''hyphen''+''edo'') which I could also live with and which I'd prefer to the current convention <code>"%dedo"</code> (''number''+''edo''). The reason why I like the hyphenated version(s) is that the parts can be distinguished easily and line breaks in the middle don't look too bad (in comparison to <code>"%d edo"</code> or <code>"%d EDO"</code>). On the ''EDO'' page itself (section [[EDO #Adding EDOs]]), we have ''n-edo MOS'' and ''m-edo MOS'' which reads much easier than ''nedo MOS'' and ''medo MOS''. I think a writing convention should benefit the reader first and the writer second. In any case, this should apply to texts intended for publication: they are aimed at as many readers as possible, and thus the writing effort is well spent. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 16:31, 12 July 2021 (UTC) | |||
:: Those are interesting points indeed. I agree with you that the convention should benefit the reader first. In that spirit, readers are more likely to recognize the spelling if they have seen it used elsewhere frequently, such as in the titles or descriptions of the music they listen to. | |||
:: By the way, I updated the [[EDO]] page today. I'm using "edo" and "<span><math>n</math></span>edo" for now, where the variable <span><math>n</math></span> is written using the math tag, which makes it stand out better. As for numbered edos, I use "12edo" for now, which I think is not that hard to read since digits are taller than lowercase letters, and having no spaces or hyphens prevents any line breaking from happening. In any case, I'm willing to change it later if we decide on another convention. [[User:Fredg999|Fredg999]] ([[User talk:Fredg999|talk]]) 03:18, 13 July 2021 (UTC) | |||
:: I think multiple formats can coexist, each one used when most appropriate. For example, I generally prefer "19edo", but "n-edo" is clearer than "nedo", as you've brought up. I don't see the problem with using a hyphen in some cases and not others. I think "<span><math>n</math></span>edo" is a bit visually jarring, and not as clear as using the hyphen. | |||
:: Beyond article titles, I don't think there's a particular need for standardization of formats, as long as it's clear. Different writers have different preferences, and may write things differently in different contexts. I'll also add that lowercasing "edo" or "mos" doesn't inherently erase their meanings as acronyms. [[User:SupahstarSaga]] 2021-07-18 | |||
::: Yeah, "19th" and "''i''-th" co-exist perfectly and this style is very common in math textbooks. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 16:33, 18 July 2021 (UTC) | |||
:: On readability (I realized this when I tried unifying the style in the page ''Prime EDO''): if you read a larger text block, you'll notice how the capital style break the flow of text and results in worse readability. You know why small capitals are common in novels? It's to avoid capital letters so as to ease reading. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 16:33, 18 July 2021 (UTC) | |||
:: I'm starting to think "edo" and "n-edo" represent a good compromise, especially considering [[User:FloraC|FloraC]]'s argument. I'm also thinking of a compromise: presenting "EDO or edo" in that order on the [[EDO]] page to insist on the fact that it's an acronym, but choosing "edo" and "n-edo" as a convention for readability on the Wiki. That might seem contradictory, but it allows one to pass from the full term to the acronym to the anacronym more smoothly, from my point of view. [[User:Fredg999|Fredg999]] ([[User talk:Fredg999|talk]]) 18:10, 19 July 2021 (UTC) | |||
== Math conventions == | |||
There are currently no real conventions for mathematical notation. Since a lot of math pages involve linear algebra, I propose the following: | |||
: Open up any introductory linear algebra textbook. Follow the notation that is used there. | |||
In practice this means: | |||
* Matrices are uppercase Roman letters: <math>M</math>. | |||
* Vectors (whether column or row) are usually lowercase Roman letters: <math>u</math>. | |||
* When there is potential confusion with scalars, they can be made boldface: <math>\mathbf{u}</math>, or get an arrow: <math>\overrightarrow{u}</math>. | |||
* Inner product can be notated: <math>u^\mathsf{T}v</math> or <math>\left\langle u,v \right\rangle</math>. | |||
* The p-norm is: <math>\| u \|_p</math>, when no p is given, 2-norm is assumed. | |||
* When writing a column vector inside text, just transpose it: <math>w =\begin{bmatrix} | |||
w_1 & w_2 & w_3 | |||
\end{bmatrix}^{\mathsf{T}}</math>. | |||
The wiki has Mathjax support, use it! | |||
: EDIT: This also means getting rid of bra-ket notation, by the way. They are used to denote quantum states in complex Hilbert spaces. We are not doing quantum physics here so let's stop pretending. | |||
- [[User:Sintel|Sintel]] ([[User talk:Sintel|talk]]) 20:00, 18 December 2021 (UTC) | |||
== 2 or 3 digits == | |||
Giving two options for the number of digits isn't really useful if we want consistency... I just changed the [[15edo#Commas]] table's values to 3 digits because I had checked [[17edo#Commas]] and that table used 3 digits, but apparently that one was the exception, not the reverse? Would it make sense to use 3 digits everywhere? Of course it's not urgent, but I'd rather stick to one standard rather than two, so that at least when we're making decisions, they're not arbitrary or random. --[[User:Fredg999|Fredg999]] ([[User talk:Fredg999|talk]]) 02:25, 7 July 2023 (UTC) | |||
: I would be in favour of using 3 digits everywhere. --[[User:BudjarnLambeth|BudjarnLambeth]] ([[User talk:BudjarnLambeth|talk]]) 02:38, 7 July 2023 (UTC) |