Talk:Normal lists

This page also contains archived Wikispaces discussion.

Smith normal form

I noticed "Smith normal form" was added to this page as a name for the form of the normal val list. I've done a couple examples and I'm pretty sure that Smith normal form is not equivalent to this process; e.g. meantone's normal val list would be [⟨1 0 -4] ⟨0 1 4]] while I suppose you could say meantone's val list in Smith normal form (taking the first k rows only, as is demonstrated in the penultimate paragraph of the page on saturation) would be [⟨1 0 4] ⟨0 1 -4]]. If this is an attempt to name this other form for Gene Ward Smith, I think it's not a great idea, because of the preexistence of the linked Smith normal form which was named for Henry John Stephen Smith. --Cmloegcmluin (talk) 18:24, 23 June 2021 (UTC)

I saw it somewhere and thought this was what it referred to. I was really sorry about that. FloraC (talk) 07:31, 24 June 2021 (UTC)

Oh, no big deal at all. Thanks for updating the page. --Cmloegcmluin (talk) 15:17, 24 June 2021 (UTC)

How best to handle the new canonical form for RTT matrices w/r/t normal form

I recently published a page on the xen wiki proposing a canonical form for RTT mappings (or comma bases). This new page of mine solves a problem that this page seems to have set out to solve but not finished the job: establishing a form for RTT matrices which uniquely identifies them, for a definition of uniqueness that is appropriate to the RTT domain. And so my page refers to this page in several places, mostly critiquing it.

I note that this page doesn't even present a unified front. It presents both HNF and IRREF as potential normal forms. But it is not clear whether a given matrix on a temperament page marked as "normal" is its HNF or IRREF (sometimes they are the same, other times different).

But in particular I note that neither the HNF nor IRREF methods discussed here reliably defactor matrices (or in other words, saturate them, or remove contorsion, though those are confusing terms for the issue that my new page sets out to eliminate). This is what I'm referring to when I speak of a definition of uniqueness that is appropriate to the RTT domain. The HNF of a matrix is unique, yes, as is the IRREF. But these definitions of uniqueness treat e.g. ⟨12 19 28] and ⟨24 38 56] as distinct, when from a strict RTT perspective the latter is not distinct insofar as how it tempers JI from the former. At least when enfactoring is found in mappings, it has musical reality, but in comma bases it's meaningless and confusing (I can still play music in 24-ET that sounds different than 12-ET, but I can't pump the comma [-8 8 -2⟩ any differently than the comma [-4 4 -1⟩)). So: enfactored matrices are pathological. (If you're interested in this issue, my new page discusses it in detail.)

My concern is that the normal forms for RTT matrices which are discussed here have proliferated widely, but I believe that now that a canonical form has been developed (by Dave Keenan, in collaboration with myself, Douglas Blumeyer, inspired in no small part by many insights from Gene Ward Smith) should be the primary form of RTT matrices used throughout the wiki. Of course I don't plan to do this myself immediately, for numerous reasons. For starters, that'd be a Herculean task. But mostly I wouldn't do something that impactful without soliciting input from the community first.

And as for this page itself: I am not saying that it is harmful or that there is nothing of value on it. Far from it! There's some good thinking here. But I do wonder what people here think about what the best approach should be for recognizing its relationship with the new canonical form. --Cmloegcmluin (talk) 18:10, 27 September 2021 (UTC)

First of all we must make clear what purposes these pages serve. Imo this page should always be kept up to date and used as the canonical reference. I'm not sure about your view of your canonical form article. To me it acts more like a development note thereof.

Currently the form in all temp pages is the form defined in the normal val list section, and they are in canonical form already since they are not enfactored to start with. (More precisely, there is not a start but only the end and the end is correct.) So they are in canonical form and we don't need to do anything about them.

The important part is the amendment of the definition in the normal val list section so that we'll convert the form to the canonical form, to ensure the correct end even if we start with an enfactored map. It can be a one-liner amendment, as simple as "defactor it", or rewritten to focus on the new reduction method.

Finally, the irref form should be removed as it's almost never used. We cover it in another page i.e. generator size manipulation, just like other forms. FloraC (talk) 15:07, 28 September 2021 (UTC)

My view of my new canonical form article is that it is mostly about defactoring, or in other words, the main element that is missing from the existing normal form and its wiki page. It is only partially about a canonical form for matrices which uses defactoring. I certainly agree with you that the extreme level of detail I included on my page, and in particular the documentation of failed experiments and tangential information, gives it a "development notes" character. Totally fair. :) You may have noticed that I also initiated similar discussion on the page for saturation/contorsion here: https://en.xen.wiki/w/Talk:Saturation, i.e. discussion re: how best to integrate this material about defactoring and canonical form in with what already exists on the wiki.

I think that at the end of the day, only two pages are necessary: one page about defactoring, and one page about the matrix form which uses defactoring along with Hermite normalization in order to achieve a unique identifier for a temperament. Due to recent freaky experiences proposing changes to the wiki on Facebook, my confidence about making major contributions directly to existing pages has been shaken. That's why I added all my new material to one new page: perhaps only as a staging ground. If I were to have felt more confident, I would have directly:

1. added most of that new material to the page for saturation/contortion, added redirect pages to it for "enfactored", "defactoring", etc., and then in the Talk page drawn people's attention to the parts of the new material explaining the major flaws in the existing terminology for the concept and recommending that the primary name of the page be updated to "defactoring".
2. added a small amount of material to this existing normal lists page, added a redirect page to it for "canonical form", and then in the Talk page drawn people's attention to the parts of the new material explaining the preference for "canonical" over "normal" as the term for this form and recommend that the primary name of the page be updated to "canonical form".

I believe that there are some people who will never accept proposals to rename concepts like "saturation" and "contorsion", nor would they appreciate the reworking and relegation of most of the existing material on that page to a "mathematical theory" subsection of it as I would prefer. So I think I'll never accomplish the consolidation of the defactoring material into the saturation/contorsion page. However, I do think we can migrate relevant information from my page into the existing normal lists page. In other words, extract all the information from my page about canonical form into the normal lists until I can rename my new page to be focused exclusively on "defactoring" independent of the canonical form it's used for, and then rename the normal lists page to "canonical form". The amount of migrated material to accomplish that may indeed literally be a one-liner, as you suggest. :)

You make an excellent point that while people exploring on their own are likely to encounter enfactored temperaments, probably most of those that have managed to get documented here are not enfactored. And also if you think that the IRREF form is almost never used, then there's not that risk of mismatch either. Therefore I agree that we probably could simply override the existing normal form with the new canonical form, or in other words, conflate the two while keeping the name "normal form", without causing a ton of inaccuracies across the wiki.

However, I don't think that's a good idea. While I personally agree that there may be little value in maintaining "normal form" as a term which refers to an RTT matrix which has been normalized but not also defactored, I think it is smarter and safer to allow for the possibility that there are people for whom the existing normal form w/o defactoring does hold some importance which we don't see ourselves at this time. Just for backwards compatibility's sake, I mean. There's also an argument that switching to the new term "canonical form" would be important because it helps signal to the community that the form has changed conceptually.

I agree that the IRREF form should be removed from this page. It's not mentioned in my new page for "generator size manipulation" though, so I'm not sure what you mean by that. Perhaps you mean that we should extract it to its own dedicated page? --Cmloegcmluin (talk) 17:42, 28 September 2021 (UTC)

So we've basically reached agreement that this page should be updated first. We definitely want to keep the original normal form (for both val list and monzo list), with the new canonical form added probably as a separate section. I'll try taking care of this.

Hmmm I remember at one point seeing irref in the page generator size manipulation. If not, let's move it there or somewhere else (like Mathematical theory of regular temperaments). FloraC (talk) 00:50, 29 September 2021 (UTC)

That sounds good to me so far. Re: IRREF, I know it's not anywhere on the page generator size manipulation, because I created that page myself only a week or two ago, and it doesn't really have anything to do with IRREF. Around the same time as I was creating that page, though, I was working on the canonical form page, and I do have a section about IRREF there: canonical form#IRREF I believe my section contains every bit of information re: IRREF and its relationship to HNF that is presently on the normal list page, and supplements it with visual diagrams that make comparison easy. So I think we could simply remove the IRREF stuff from this page. --Cmloegcmluin (talk) 02:21, 29 September 2021 (UTC)

Thanks for making your latest changes to the page. I'm glad to have learned about the Databox template and syntax highlighting! I've gone ahead and used it myself on other pages now.

I think the technique to link out to the canonical form page works fine. Maybe I'll keep it the way it is, i.e. not work to rename it to simply "defactoring" (I did add a redirect page for that, though).

Re: the beep example. I recently fixed that example myself. But I've since noticed it's not quite perfect. Normal form (and canonical form) require the pivots to be positive. And you find the pivots for comma bases by anti-transposing them, i.e. flipping them across the anti-diagonal, between top-right and bottom-left, so that when the HNF tries to put all the zeros in the bottom-left corner, it gravitates them toward where we want them: the higher primes, and commas earlier in the list. Technically, then, the canonical commas for beep should be 25/27 and 35/36, even though with n < d those are negative in pitch and that's not the typical way we write commas. It looks less off-putting when the canonical form is presented as a matrix, i.e. ⟨[0 -3 2 0⟩ [2 2 -1 -1⟩], so I suggest we write them like that. Or I'm open to other suggestions.

Speaking of lists vs. matrices, I would like to rename the page from "normal lists" to "normal form". I see that this reflects my preference to think of RTT structures as matrices rather than lists of vectors or covectors. Because we are using linear algebra extensively here, I think this is the natural and appropriate way to think of them. What do you think?

Re: the new "Tenney minimal" section. I think it's an interesting idea to present a comma list in a different normal form than HNF (or defactored + HNF = canonical form), namely, some definition of the simplest possible ratios. However, I have several questions.

1. You state that this is already the case that temperament pages use this form. I have no reason to believe they're not. But I didn't know that was the case. How do you know this?
2. Do you have a definition for this normal form somewhere? If you don't yet, I would recommend excluding it from this page until it's better developed. I can easily see how the product complexity of ratios can be easily calculated individually, but minimizing the simplicity of multiple ratios may be somewhat subtle.
3. Why name it "Tenney minimal"? I do not see that this term has wide use on the wiki or Discord already. It seems like an unnecessary eponym. If it is related to the Tenney height of the ratios, wouldn't it be equivalent and simpler to just refer to their product complexity?

That's all for now. Thanks for helping with this. --Cmloegcmluin (talk) 18:54, 29 September 2021 (UTC)

I would also like to see across the wiki places where "normal list", "normal comma list", "normal interval list", "normal val list", "normal list basis", etc. standardized to "canonical mapping" or "canonical comma basis", linking here. What do you think? --Cmloegcmluin (talk) 19:54, 29 September 2021 (UTC)

Sounds like a lot of work to be done!

Re: the beep example. We've adopted an additional step for positive generator in Hermite normal form. Analogously, we can add one to flip the monzo if it turns out negative. So [[0 3 -2 0⟩, [2 2 -1 -1⟩] instead.

Re: rename and standardization. I don't think renaming this page and/or "standardize" the terms in other pages is a priority. Until some data from other users are collected, I can't exclude that what we project as standardization may actually be prescriptivism.

Re: Tenney minimal. 1. By examining some comma lists. For septimal meantone, the normal form would be {81/80, 59049/57344}. Yet the comma list shown in the temp page is {81/80, 126/125}. 2. I've worked out a lot of comma bases and haven't encountered a single example where the definition shown in this page leads to ambiguous results. Now I definitely can't assert there's no exceptions, I'm afraid it'd better be there since all the comma bases shown in the temp pages need an explanation. 3. It's attested in the Genesisplus page. We can call it ratio-product simplest form, but that's longer and still needs explanation. You know, you can also remove Benedetti height in favor of ratio-product, and remove Tenney height in favor of logarithm of ratio-product. I just don't think that's how human language works. Benedetti height is one of many types of heights. In the topic of heights, each type is equally distinct despite one of them being simpler in formula, so each type equally deserves a name. From there is derived Tenney-minimal as one of many possible minimal forms. FloraC (talk) 23:55, 29 September 2021 (UTC)

Re: flipping the sign of a row for a positive generator or comma. I hadn't thought about that last step given there in a while. You're right; the normal form as defined here ensures positive generators. So it would be consistent with that for the commas to also be flipped to be positive using a similar process. That said, as discussed on the canonical form page, Dave and I iterated on and ultimately decided to explicitly reject any stipulations of that sort from our definition. So in that case, canonical form is not necessarily equivalent to normal form in all defactored cases. This a perfect example of why it was a good decision for us not to conflate the two or override one with the other! Certainly some people may prefer to normalize to positive commas and generators, while Dave and I prefer the simplicity and purity of our canonicalization method. For instance, I have no intention or desire to complicate the functions I implemented in my RTT library for Wolfram Language by incorporating this sort of comma or generator positivity. So, this leads me to think that we should keep the two pages more separate than we originally planned.

Re: rename and standardization. Good point. Okay. The paint's still wet. Let's give it some time. Because even this seemingly innocuous issue that cropped up for beep is throwing me for a loop, so I am no position to propose such widespread changes yet. Never mind.

Re: Tenney minimal. Yes, I am aware that "Benedetti height" is xen jargon for "product complexity" and "Tenney height" is xen jargon for "log product complexity". In fact I recently added notes about that to their wiki pages here. I prefer descriptive names over eponymous ones, and established ones over new coinages, whenever possible. I agree that there are many distinct types of height that deserve names and that some are simpler than others, but I'm not sure what your point by that is. Anyway, because "simple" and "complex" are antonyms, we might be able to get away with "product-simplest form" then. --Cmloegcmluin (talk) 01:07, 30 September 2021 (UTC)

Re: positive generator. If you don't want the canonical form normalized to positive generators, many mappings shown in the temp pages aren't in canonical form. I, for one, expect that the canonical form should be normalized to positive generators. After all, we've been using this form for so many years, and it wouldn't be there in the first place if it's undesirable. Anyway, we seem to be in a really awkward position now :).

Re: Tenney-minimal. My point is that some heights being simpler in formula doesn't imply they don't deserve a name – if you accept Wilson height and Kees height you may well accept Benedetti height and Tenney height, even tho these are much simpler. And since Tenney-minimal derives direct from Tenney height, and since it's been attested, I think it's a quite standard way to convey the idea of ratio-product simplicity. FloraC (talk) 02:53, 30 September 2021 (UTC)

Re: positive generator. Here's a bit more color on Dave and I's experience working on canonical form. We thought that the way it's done in Graham Breed's temperament finder was probably the most familiar and well-liked form in the community, i.e. that generators should always be positive and less than half the size of the previous generator (that's the "mingen" form that I ended up documenting somewhere on that new page I made re: generator size manipulation). But we found it problematic to extend this constraint past rank-2, and then heard from Graham that he'd never managed to find a way to do it himself either. Dave and I decided that probably preferences about generator forms would come and go over time like flavors of the month, and that if we wanted our proposal to be taken most seriously, we should laser-focus it on the main element of importance — defactoring — and leave the rest to well-established mathematical precedents like HNF that are already implemented in many code libraries. And it was right about this time I discovered the chroma-positive generator form that some folks on Discord seem to be using now, which to me was perfect evidence of changing preferences for generator form, and therefore the nail in the coffin for involving generator size considerations in the form we advocate for the express and primary purpose of uniquely identifying temperaments AKA canonicalization.

I note that it's misleading to include the final steps in the "normal val list" and "normal interval list" in sections titled "Hermite Normal Form" because those are not part of the definition of HNF. That's part of the reason why I forgot those steps were there; the last time I read those lists, many months ago, I suppose I had written them off as tediously worded but probably ultimately accurate descriptions of how to reach HNF. But those final steps deviate them from HNF. So I think we should extract the "For any number q < 1 on this list, replace q with 1/q" and the "Find the Moore–Penrose pseudoinverse..." steps to another section, which we might call "positive comma form" and "positive generator form". This has the other benefit of allowing us to maintain the integration of canonical form into this page, as the canonical form Dave and I defined will be in a state where it extends the HNF as defined here. If you agree this is a reasonable solution, I am happy to implement it (esp. since you did the work for the previous edit).

As a result of this change, there would now be several options for normal forms documented on this page: Hermite normal form, positive comma/generator form, Tenney-minimal form, and canonical form. At this point we may even want to tilt the other way, i.e. rather than toward a consolidated effort into a single form, a survey of all relevant forms, and therefore additionally include the chroma-positive form and mingen form, and any others you're aware of. Across the wiki many temperaments have a normal form (or "normal lists" or whatever) documented; it may be to our advantage that most of these places are given generically. Surely whatever's given in most of those places is at least one of these normal forms. I suppose over time people may revise individual pages to be more specific about which one it is, and possibly include more than one.

Re: Tenney-minimal. I think Benedetti, Tenney, Wilson, and Kees height are all ideas that deserve names. Maybe we have a different definition of "name" here? I think "product complexity" is a name. It's not a person's name, but I prefer that it's not eponymous. Of these four heights, only Kees does not have a preexisting name in mathematics. Just now I had to look up what Wilson height was again, but if you had just used "sum of prime factors with repetition" which is often abbreviated "sopfr" I would have immediately known what you're talking about. "Tenney" is used in xen jargon as a synonym for "log", and because logarithms are so basic to xen, "Tenney" ends up in an excessive number of things' names. That it is attested in a .scl file that was uploaded to the wiki is not very persuasive to me. The old Scala file archives have tons of junk in them, as I can attest after doing an audit of them for some Sagittal-related reason recently: https://forum.sagittal.org/viewtopic.php?p=1515#p1515 I would be looking for a much stronger precedent than a single mention in a .scl file to justify "Tenney-minimal form" over "product-simplest form".

I see that you commented out the information about IRREF. Do you mind if I simply delete it? I just noticed during a search across the wiki for misinformation re: torsion that it is one of the few places that contains it. --Cmloegcmluin (talk) 17:20, 30 September 2021 (UTC)

Re: positive generator. Good to hear that you're willing to have all the recognized forms included in this page. That seems like the best solution we currently have.

Down to some details. 1. first of all, I must inform you that the chroma-positive form isn't a specification of generator in a temperament, but in a MOS. For example, meantone[7] (diatonic) and meantone[12] (m-chromatic) have different chroma-positive generators since they have different chromas. 2. I feel like mentioning again the musician's form – I suggest supplying it with an alternative name: equave-reduced generator form, and accordingly have the definition revised to reflect that. In this take, meantone's generator is ~3/2 and porcupine's generator is ~10/9 (not ~9/5). 3. I can't expect the mappings in the temp pages are to be changed to another form, but we do need to find out a form to be used consistently in the POTE generator(s) lines.

So if you accept my proposal, we'll include Hermite normal form, canonical form, positive generator form, equave-reduced generator form / musician's form, and minimal generator form.

Re: Tenney-minimal. I'd rather not see sopfr since it requires the same amount, if not more, of explanation as Wilson height. As I said earlier, the Benedetti height, whatever the formula is, manifests itself as a type of height. Height is an immediately recognizable tag which carries not only the meaning of a measure of interval complexity but also implies all the properties. So we acquire the relevant knowledge without checking the formula. On the other hand, product complexity only demonstrates the formula, that is, it emphasises the computation aspect, but omits the aspects of properties and significance. That to me is penny wise and pound foolish.

In this case, however, I admit that Tenney-minimal form is not the best term since it's equivalent to Benedetti-minimal form. I guess minimal is still good. I hope to drop product as both the numerator and the denominator correlates strongly with the product in any good commas. So how about minimal comma form or minimal ratio form? You coined minimal generator form and mingen after all. (I guess I won't be using mingen if there isn't mincom as well.) FloraC (talk) 18:53, 30 September 2021 (UTC)

Re: chroma-positive generators. Thank you for correcting me. Yes, that makes complete sense why they're a different matter.

Re: "musician's form": Sorry, but I haven't heard back from Dave yet about what he means when he uses that term. I searched the old tuning list archives and didn't find anything there either.

Re: "equave-reduced generator form", could you define it please? I can't guess at what that means from its name, association w/ the name musician's form, and the examples you give.

Re: the POTE generator lines: those aren't the only places on temperament pages where a specific form of a generator is chosen which may or may not be the one in the mappings shown, are they? Or is there a specific concern you have re: POTE generators that I'm not ascertaining?

Re: your proposal of which forms to include. That list looks fine though we still need to define equave-reduced and musician's forms.

Re: height. You make an interesting point about "height" as a tag, of membership in a suite of similarly useful measurements. In fact, for what it's worth, I had started typing something to that effect myself, anticipating your likely reply, but I couldn't figure out how to say it without muddying the points I was already making. So I'm glad to see that you went ahead and made the point, and I think you put it a lot more clearly than I was going to. :) So while I personally disagree that sopfr requires any explanation, I concur that there is value in a domain such as xenharmonics rebranding established mathematical operations in order to underline important interrelations such as this. I would still prefer that these rebrands be descriptive. Why not "product height", "log product height", and "factor-sum height", I mean?

Re: product. When you say, "I hope to drop product as both the numerator and the denominator correlates strongly with the product in any good commas," what do you mean exactly? The "product" here as I understand is the product (as in multiplication) of the numerator and denominator. So of course both the numerator and the denominator correlate strongly with the product. And why would this be a reason to drop the word "product"? Sorry if I missed something obvious here.

Re: mingen coinage. For the record that was Dave's coinage, not mine, and I have some qualms about it, but I have been promulgating it, so your point stands. Of your suggestions, I like "minimal ratio form" the best; "minimal comma form" leaves open for me the interpretation that the comma be smallest in cents, which is more akin to the sense in which "minimal generator form" uses "minimal", but I think it is more appropriate to deal with commas as ratios but generators as cents values. --Cmloegcmluin (talk) 20:27, 30 September 2021 (UTC)

Re: equave-reduced generator form. This is defined as follows. The mapping is normalized such that each generator is reduced by the formal prime represented by the first column (which is formally regarded as the equave). It's usually the octave but can be others, depending on the subgroup. That's my understanding of musician's form but I'm aware it's up to Dave to determine what musician's form is.

Re: height and product. Look, I presented you equave-reduced generator form which I reckon is straightforward enough, yet you still asked me about the definition. I think that's an exemplar case to show that a name isn't anything but a sign, and the relatability between the signifier and the signified can't be expected due to semiotic arbitrariness. Specifically, even if we go with product height, the reader will wonder it's the product of what. The answer "numerator and denominator" isn't emergent, with so many existing measures of intervals. Therefore, I reserve that it requires about the same amount of explanation.

Since "product of what" isn't emergent, it's questionable whether there's any substance in the word product. I'd rather use ratio or comma instead in our name of the matrix form because that contains some stuff at least. So I'll go with minimal ratio form. Ok?

Re: POTE generator(s) line. Problem is the generators in this line in all the temp pages don't consistently come from a certain form. My plan is to regulate them to the equave-reduced generator form. Not related but I'll also revise this line to Optimal tuning (POTE). FloraC (talk) 16:59, 1 October 2021 (UTC)

Re: equave-reduced generator form. You had said "In this take ... porcupine's generator is ~10/9 (not ~9/5)." But both 10/9 and 9/5 are octave-reduced (the equave is the octave here). In what way does your definition select 10/9 over 9/5? That's what I was confused about earlier, but this definition you've now shared has not resolved my confusion. Because this is the definition of a normal form, not a canonical form, I understand that it's not necessary that the results be unique; i.e. it might be the case that both 10/9 and 9/5 were options for a equave-reduced generator (normal) form. But you specifically claimed that 9/5 did not qualify, and I expect you do wish for this form to uniquely identify. So maybe there's something about your definition that I'm missing, that should be included explicitly.

Re: names. The job of a name is not to unambiguously and completely specify the thing it names; sure, "equave-reduced" wasn't enough to convey the entire definition of that form to me, but I wouldn't expect it to have done that. So a name shouldn't contain all the information about a thing, but a name does a good job if it contains some of the most important info about it. For a newcomer, "product complexity" vs "Benedetti height" have the same cost: there's not enough information in either name to understand the thing, so you must look it up to learn it. But in the case of people like me who have already learned the thing but, say, use it only once every couple months or something, "product complexity" would have a clear advantage because of its descriptiveness: it doesn't contain the entire definition, but it's the right amount to jog my memory and let me feel confident about using it without requiring another look up. On the other hand, I have to look up "Benedetti height" every freaking time just to remind myself which person's name got associated with which complexity metric. I agree that the term "product complexity" leaves out the information about what exactly gets its product taken, and so while for me that's plenty to remember that it's the numerator and denominator, other people might not be so certain based on that name. But that's an acceptable cost. No one name could be perfect for everyone. By pushing for "product complexity" I'm pushing for the name I think should work the best for the most people, is all.

That all said! Yes, I think "minimal ratio form" is good and I would be happy if you used it. --Cmloegcmluin (talk) 20:59, 1 October 2021 (UTC)

Re: equave-reduced generator form. You're aware that 3/1 octave-reduces to 3/2 and not 4/3? Porcupine's generator, in the positive generator form, is 10/9. 10/9 octave-reduces to 10/9 and not 9/5. I think the part we both missed is that the positive generator form should be used as a starting point to derive this form.

Re: names. You're totally right that including product in the name is a helpful mnemonic. Good point. However, by using descriptive names its distinctiveness is lost in return. Here's an extension of the "product of what" problem: what if there's another "product complexity"? I just came up with one, which is a product of numerator, denominator, and interval size, in the hope of punishing larger intervals so that 77/1 is measured more complex than 11/7. Not to seriously use it, what I mean to show is how easy for the phrase to be neutralized and turned into an empty signifier.

Anyway, I'mma work on this page. FloraC (talk) 01:04, 2 October 2021 (UTC)

Re: equave-reduced generator form. Good stuff, totally got it now. Thanks.

Re: names. You've done it again, i.e. in my previous comment I began to anticipate a point I thought you might make, but ended up cutting it. In this case the point was about how "Benedetti" is at least a word you don't hear every day. So I could imagine for people with other learning styles, who can do a one-time match of "Benedetti height" with the concept and retain it strongly, then the distinctiveness of "Benedetti" could be superior. Anyway. Naming is hard. I expect you're familiar with the adage about the two hardest things in computer science being cache invalidation, naming things, and off-by-one errors. Heh. Looking forward to your edits. --Cmloegcmluin (talk) 01:20, 2 October 2021 (UTC)

I've reworked it and pls give it a review. FloraC (talk) 14:39, 2 October 2021 (UTC)

W00t! That's basically exactly how I was going to do it: for the mapping side, build them cumulatively on top of each other: HNF, canonical, positive generator, equave-reduced, mingen. Then a similar progression for the comma basis side. Great work.

I just layered on an edit myself which came out bigger than I was expecting as I added some context that I think is helpful and some further explanations and examples. Let me know what you think. I didn't disagree with anything you had put on the page, so if in my edit I screwed up anything you cared about, please go right ahead and rework/redo. --Cmloegcmluin (talk) 00:51, 4 October 2021 (UTC)

I like these additions of contexts and details. Hopefully they will give readers easier time. FloraC (talk) 11:06, 4 October 2021 (UTC)

Thank you. I did a little more work on it this morning based on random things that popped in my head last night. The main thing being that there were some inaccuracies re: canonical form (defactoring removes rows of zeros, so the third step to do so again after HNF was pointless). Also, I thought it was better to separate the issue re: converting intervals between ratio and vector format from discussions of the normal forms, since the format they're written in is independent from the different normal forms. Again, let me know if there's any problem with it and feel free to further adjust yourself. --Cmloegcmluin (talk) 18:17, 4 October 2021 (UTC)

IRREF

The footnote criticizes IRREF for making enfactored mappings. But I originally proposed IRREF for the comma list, not the mapping. I agree that IRREF mappings are a horrible idea! From my last edit of this page: "For a monzo list, it has the advantage of limiting the appearance of the N highest primes to only one comma each (where N is the codimension), isolating each prime's effect on the pergen, but has the disadvantage that the commas tend to have high odd limits, and the comma list may have torsion." I think IRREF is valuable as a sort of secondary comma list. It would be nice if x31eq listed the IRREF comma list as well as the usual one, so that one could see all the various restrictions at a glance. It also helps compare two different temperaments to see what they have in common. For example consider (81/80 36/35) and (2048/2025 64/63), two comma lists defined by ascending prime limit, least odd limit and no enfactoring. Their IRREF forms are (81/80 64/63) and (2048/2025 64/63). The IRREFs show that they have 64/63 in common. --TallKite (talk) 22:55, 13 October 2021 (UTC)

Thanks for this Kite. I'm sorry that I misrepresented your writing. I didn't do it intentionally; I think I just wasn't being careful to mind possible importance that you may have placed on distinguishing between mappings and comma lists. As far as I was concerned IRREF was no good for either mappings or comma lists, because I was concerned about enfactoring (what you refer to here as "torsion", but as Dave and I determined in our recent research, torsion is the name for a related problem which only pertains to periodicity blocks, not temperaments; I can refer to you our findings again if you like).

I've simply removed that part of the footnote, because I realized not only did it misrepresent your writing, what it says otherwise is no longer really relevant at all.

Okay. So I see your point that IRREF can provide a different sort of value here. And at this point I can't see any reason why it wouldn't qualify as a "normal form". So if you want, feel free to add it back to the page. Flora politely commented it out but I was brash and straight up deleted your stuff. So here it is, dug up from the change logs:

Another important normalized form for integral matrices is what Kite Giedraitis has dubbed the IRREF, the integral reduced row echelon form. It is the reduced row echelon form made integral by multiplying each row of the matrix by the least common multiple of all denominators in that row. It differs from the Hermite normal form in that each pivot is the only nonzero entry in its column. For a monzo list, it has the advantage of limiting the appearance of the N highest primes to only one comma each (where N is the codimension), isolating each prime's effect on the pergen, but has the disadvantage that the commas tend to have high odd limits, and the comma list may have torsion. Sometimes the IRREF is identical to the Hermite normal form.

I had forgotten that the name IRREF was coined by you! Well, I think Dave and I did find one or two other academic sites which came up with the same term. But I believe you did so independently :)

Right! So, however, if you want to add it back to the page, there is a slight issue. As you can see, at the moment, HNF is up top, because it's part of every normal form presently on the page. So if you want to add IRREF back, you would have to rework the page a bit to accommodate that. I got us into this mess so I'm happy to help with that. Perhaps we could do it together next week. Let me know. --Cmloegcmluin (talk) 01:04, 14 October 2021 (UTC)

Yes, I would like it back in the article. BTW I thought of another use for IRREFs. Makes it easy to compute meets and joins if you have the IRREF for both temperaments. I don't know if it always makes it easier but it certainly makes it easier some times. --TallKite (talk) 20:59, 16 October 2021 (UTC)

Revision to the equave-reduced generator form

Actually, the equave reduction need not start with the positive generator form, but may start with the canonical form, which means a step of manipulation is saved. The result of course can be different, but sometimes perferable.

My proposed revision changes the old "equave-reduced generator form" to the "positive equave-reduced generator form", which signifies that its starting point is the positive generator form. And it has the new "equave-reduced generator form" derived from the canonical form.

Sensi is a great example to show how all these will differ from each other:

1. Canonical form: [⟨1 6 8 11], ⟨0 7 9 13]] with generators ~2, ~9/14
2. Positive generator form: [⟨1 6 8 11], ⟨0 -7 -9 -13]] with generators ~2, ~14/9
3. Equave-reduced generator form: [⟨1 -1 -1 -2], ⟨0 7 9 13]] with generators ~2, ~9/7
4. Positive equave-reduced generator form: [⟨1 6 8 11], ⟨0 -7 -9 -13]] with generators ~2, ~14/9
5. Minimal generator form: [⟨1 -1 -1 -2], ⟨0 7 9 13]] with generators ~2, ~9/7

My expectation is that the positive equave-reduced generator form should be left largely obsolete since musicians will work with the new equave-reduced generator form. FloraC (talk) 08:00, 16 January 2023 (UTC)

I like it. Well-motivated and well-executed. Yes, I agree that positive-ization and equave-reduction should not have been bound together as they were, and that canonical form is the baseline form. They are independent interests. And I also agree with you that their combination will likely be less popular than simple equave-reduction (or simple positive-ization). I expect after your revision, the combo form "Positive equave-reduced generator form" will be left with a very brief section, saying only that you equave-reduce the generator from the positive gen form, and that's all. Again, good thinking and good work; thanks for looking into this. --Cmloegcmluin (talk) 16:51, 16 January 2023 (UTC)

Great! I'll work on it soon. FloraC (talk) 18:43, 16 January 2023 (UTC)