Talk:Defactoring terminology proposal
Some thoughts
Torsion indeed does not have much relevance to music, as you note. While it is possible to produce a temperament that tempers out (81/80)^2 and not 81/80 by going to a subgroup that doesnt include 81/80 (e.g.: 4.9.25), this is extremely dubious, in my opinion. (The wiki talk about this here, see my note in the talk page.) However, torsion is simply a fact of life: torsion modules capture exactly how Z-modules are different from vector spaces, and why we need to be very careful when porting over ideas that apply to vector spaces. In most cases things will simply work out, but modules are weird. This is why temperaments should be defined as maps between free Z-modules. So torsion is something that should definitely be discussed on the wiki, since it will come up when trying to build a temperament calculator or some other app that tries to deal with temperaments automatically. It is my view that if you are building such a program, the gritty maths should be hidden from the user, and dealt with accordingly. However, if you want to do that, you (the developer) need to know about all this in the first place!
Contorsion is slightly less problematic, because by increasing the rank of the subgroup, it usually gets fixed (or you can just defactor them). So I like the idea of calling them temperoids!
As for terminology: torsion is an established term in module theory, so I think it's fine. And contorsion might be a bit of a stretch, but it does fit the idea of using co- as the dual thing. (Enfactored seems good too, but contorsion might be hard to get rid of at this point. I don't really care how you want to call it.) I do think it's a bad idea to use enfactored to cover both torsion and contorsion, if that's what's being proposed here.
Finally, I strongly disagree with this:
- While it can be argued that it is theoretically possible to interpret RTT using mathematical structures like quotient subgroups, lattices, and free abelian groups, [...]
In my mind, those things are *exactly* the kind of objects RTT deals with, and there's no way around it. You are very pragmatic and I respect that, but I don't see how else you can precisely define all these notions, let alone make provable statements about them.