4000 4050 4100 4150 4200 4250 4300 4350 4400 4450 4500 4550 4600 4650 4700 4750 4800 4850 4900 4950 5000 5050 5100 5150 5200 5250 5300 5350 5400 5450 5500 5550 5600 5650 5700 5750 5800 5850 5900 5950 6000 6050 6100 6150 6200 6250 6300 6350 6400 6450 6500 6550
5050 - 5075 -
![]()
![]()
Message: 5075 Date: Sat, 24 Nov 2001 19:59:21 Subject: Re: Survey From: genewardsmith@xxxx.xxx --- In tuning-math@y..., Graham Breed <graham@m...> wrote: > <input vectors *> input vectors 49:50 4374:4375 calculated vectors 17496:16807 9765625:9565938 Yipe! How are these being calculated?
![]()
![]()
![]()
Message: 5076 Date: Sat, 24 Nov 2001 21:01 +0 Subject: Re: Survey From: graham@xxxxxxxxxx.xx.xx genewardsmith@xxxx.xxx () wrote: > --- In tuning-math@y..., Graham Breed <graham@m...> wrote: > > > <input vectors *> > > input vectors > 49:50 > 4374:4375 > > calculated vectors > 17496:16807 > 9765625:9565938 > > Yipe! How are these being calculated? I've included the code below. It looks at the mapping, finds a unison involving each prime interval, and then tries to simplify it. The results here in vector form are [3, 7, 0, -5] and [-1, -14, 10, 0]. However it combines them, even apparently if it used an LLL algorithm, it couldn't get rid of the common factors of 7, 10 and 5 in the last three columns. I can't even work out how to simplify the original vectors of [-1, 0, -2, 2] and [1, 7, -4, -1]. I'm worryingly close to deciding that it can't be done. def getUnisonVectors(self): # find some vectors that work H = [1]+self.primes hcf = self.mapping[0][0] fifthIndex = 1 while self.mapping[fifthIndex][1]==0: fifthIndex = fifthIndex + 1 #okay, so this won't index the fifth any more fifth = self.mapping[fifthIndex] denom = -hcf*fifth[1] vectors = [] for index in range(1,len(self.mapping)): if index == fifthIndex: continue m, n = self.mapping[index] vector = [0]*len(H) vector[0] = fifth[1]*m-fifth[0]*n vector[fifthIndex] = hcf*n vector[index] = denom vectors.append(normalizeInterval(vector, H)) # now simplify them nOthers = len(vectors)-1 cmpfn = intervalCompare(H) while nOthers: # loop until broken if there are alternatives vectors.sort(cmpfn) worst = vectors[nOthers] for index in range(nOthers): alternative = normalizeInterval( map(operator.add, vectors[index],worst)) if cmpfn(alternative, worst)<0: vectors[nOthers]=alternative break alternative = normalizeInterval( map(operator.sub, vectors[index],worst), H) if cmpfn(alternative, worst)<0: vectors[nOthers]=alternative break else: # can't be improved break; return vectors
![]()
![]()
![]()
Message: 5077 Date: Sat, 24 Nov 2001 06:08:12 Subject: Survey VI From: genewardsmith@xxxx.xxx <225/224, 4000/3969> Minkowski reduction: <335/224, 3125/3087> Ets: 12, 29, 41, 53, 94 Map: [ 1 2] [ 2 3] [-1 6] [-3 8] Reduced map: [ 0 1] [-1 2] [ 8 -1] [14 -3] Generators: a = .4148831986 (~4/3) = 38.99902067 / 94; b = 1 Septimal schismic system; effectively this is 53+41 Errors and 94-et: 3: .185 .173 5: -3.44 -3.33 7: 1.21 1.39 <4375/4374, 225/224> Minkowski reduced Ets: 19, 53, 72 Map: [ 3 1] [ 6 0] [ 8 1] [13 -3] Adjusted map: [ 0 1] [ 6 0] [ 5 1] [22 -3] Generators: a = .2639365655 (~6/5) = 19.00343272 / 72; b = 1 This is pretty much the 53+19 system of the 72 et, but a bit better in tune; in particular the long string of generators to 7 helps to get it in better tune. Errors and 72-et: 3: -1.61 -1.96 5: -2.69 -2.98 7: -0.90 -2.16 Because the 7's are so inacessible, it's tempting to treat this as a purely 5-limit system, in which case it's closer to the 53 et, with a generator of 14.00435/53, and triads which are very good; this version is the kleismic temperament. Another possibility would be a planar temperament. <1728/1715, 81/80> Minkowski reduction: <1029/1024, 81/80> Ets: 5, 26, 31, 57 Map (no adjustment) [ 0 1] [ 3 1] [ 12 0] [-1 3] Generators: a = .1934362896 (~8/7) = 5.996524978 / 31; b = 1 Errors and 31-et 3: -5.58 -5.18 5: -0.83 0.78 7: -0.95 -1.08 Pretty much the 26+5 system of the 31-et. <64/63, 686/685> Minkowski reduced Ets: 10, 27 Map: [1 -1] [1 -3] [5 4] [4 0] Adjusted map: [ 0 1] [ 2 1] [-9 5] [-4 4] Generators: a = .2969233588 (~11/9) = 8.016930688 / 27; b = 1 Errors and 27-et 3: 10.66 9.15 5: 6.91 13.68 7: 5.94 8.95 This is one version of a neutral third temperament, though Graham does not even mention the 27-et in connection to neutral thirds, so it's hardly canonical.
![]()
![]()
![]()
Message: 5078 Date: Sat, 24 Nov 2001 08:06:19 Subject: Re: Survey VI From: Paul Erlich --- In tuning-math@y..., genewardsmith@j... wrote: > <225/224, 4000/3969> > > Minkowski reduction: <335/224, 3125/3087> That 335 should really be 225, right? > > <64/63, 686/685> Minkowski reduced That 685 should be 675, right?
![]()
![]()
![]()
Message: 5079 Date: Sat, 24 Nov 2001 08:10:03 Subject: Re: Survey VI From: genewardsmith@xxxx.xxx --- In tuning-math@y..., "Paul Erlich" <paul@s...> wrote: > --- In tuning-math@y..., genewardsmith@j... wrote: > > <225/224, 4000/3969> > > > > Minkowski reduction: <335/224, 3125/3087> > > That 335 should really be 225, right? > > > > <64/63, 686/685> Minkowski reduced > > That 685 should be 675, right? Yes to both. Bad fingers, bad!
![]()
![]()
![]()
Message: 5080 Date: Sat, 24 Nov 2001 12:24:45 Subject: Survey From: Graham Breed I've caught up with this. Scripts are at <############################################################################### *> <#!/usr/local/bin/python *> <#!/usr/local/bin/python *> <Gene, it looks, from your post on the tuning list, that a basis need *> And results at <input vectors *> There's still a problem with calculating the containing MOS. I've managed to work around that by not calculating the containing MOS. It looks right as far as I can tell. Unison vectors aren't LLL reduced, and some might be very wrong. If you want other combinations done, it's very easy to feed it a different input file. Only 7-limit currently. Graham
![]()
![]()
![]()
Message: 5082 Date: Sun, 25 Nov 2001 21:00:16 Subject: Survey VII From: genewardsmith@xxxx.xxx <1029/1024, 245/243> Minkowski reduced Ets: 5, 41, 46, 87 Map: [ 1 1] [ 1 4] [-1 16] [ 3 2] Adjusted map: [ 0 1] [ 3 1] [ 17 -1] [-1 3] Generators: a = .1953420071 (~8/7) = 16.99475462 / 87; b = 1 Error and 87-et: 3: 1.28 1.49 5: -1.34 -0.11 7: -3.24 -3.31 This is pretty nearly the 46+41 system of the 87-et, which fails to take much advantage of the excellent thirds, but does have a lot of 1--3/2--7/4 chords to play with. <4375/4374, 2401/2400> Minkowski reduced Ets: 27, 72, 99, 171, 270, 441, 612 Map: [ 0 9] [-2 -1] [-3 -2] [-2 10] Adjusted map: [ 0 9] [-2 15] [-3 22] [-2 26] Generators: a = .04083262537 (~36/35) = 24.98956673 / 612; b = 1/9 (~27/25) = 68/612 Alternative adjusted map: [0 9] [2 13] [3 19] [2 24] a' = 43.01043329/612 (~21/20) as generator Errors vs 441 and 612 ets: 3: .0467 .0858 .0058 5: .0222 .0808 -.0392 7: -.1575 -.1184 -.1985 In case anyone cares about errors that small, it can be seen that both 441 and 612 do a fine job with this system, which is another familiar face, the ennealimmal temperament. I'd remark that it's good enough even for Harry Partch but for the fact that it would get me in trouble, so I'll point out that it's good enough even for Harry Potter. Good enough for what I leave to Hogwarts to figure out, but tempering the 72 notes remains one possibility. <875/864, 50/49> Minkowski reduced Ets: 22, 26, 48 Map: [2 2] [1 -3] [3 0] [4 1] Adjusted map: [0 2] [4 1] [3 3] [3 4] Generators: a = .2713428065 (~6/5) = 13.0244547 / 48; b = 1/2 Errors and the 48-et: 3: 0.49 -1.96 5: -9.48 -11.31 7: 8.01 6.17 Here's another system with very flat major thirds, and Paul, I suppose, would prefer it in the 18+4 version of the 22-et, or 22+4 of the 26 et, over 26+22 in the 48-et. <4000/3969, 2048/2025> Minkowski reduction: <3136/3125, 2048/2025> Map (no adjustment) [ 0 4] [-1 8] [ 2 6] [ 5 3] Generators: a = .4118714296 (~4/3) = 28/00725721 / 68; b = 1/4 Errors compared to 68: 3: 3.80 3.93 5: 2.18 1.92 7: 2.40 1.76 Effectively the 56+12 system of the 68-et.
![]()
![]()
![]()
Message: 5083 Date: Sun, 25 Nov 2001 02:20:24 Subject: Re: Survey From: genewardsmith@xxxx.xxx --- In tuning-math@y..., graham@m... wrote: > I can't even work out how to simplify the original vectors of > [-1, 0, -2, 2] and [1, 7, -4, -1]. I'm worryingly close to deciding that > it can't be done. I get that <49/48, 4375/4374> is already Minkowski reduced, and when I LLL reduced it, I got <49/48, 5103/5000> which hardly seems like an improvement. Why don't you write something to Minkowski reduce a pair of 7-limit intervals according to Tenney height? There may not be an intelligent algorithm, but the problem is so small you don't need one. You can calculate bounds on how far you need to search, and simply search that region. It's been working well for me.
![]()
![]()
![]()
Message: 5084 Date: Sun, 25 Nov 2001 08:12:54 Subject: Re: Survey From: Paul Erlich --- In tuning-math@y..., genewardsmith@j... wrote: > --- In tuning-math@y..., graham@m... wrote: > > > I can't even work out how to simplify the original vectors of > > [-1, 0, -2, 2] and [1, 7, -4, -1]. I'm worryingly close to > deciding that > > it can't be done. > > I get that <49/48, 4375/4374> is already Minkowski reduced, and when > I LLL reduced it, I got <49/48, 5103/5000> which hardly seems like an > improvement. Haven't I convinced you that Minkowski is that way to go rather than LLL? In either case, could you please explain the mathematical criterion that defines "Minkowski reduced", as you did for LLL?
![]()
![]()
![]()
Message: 5085 Date: Sun, 25 Nov 2001 12:24:17 Subject: Re: Survey From: genewardsmith@xxxx.xxx --- In tuning-math@y..., "Paul Erlich" <paul@s...> wrote: > Haven't I convinced you that Minkowski is that way to go rather than > LLL? Sure. In either case, could you please explain the mathematical > criterion that defines "Minkowski reduced", as you did for LLL? Let p/q be reduced to lowest terms; then T(p/q) = pq. A pair of intervals {p/q, r/s} with p/q>1, r/s>1, T(p/q) < T(r/s) and p/q and r/s independent is Minkowski reduced iff the only numbers in the set {(p/q)^i (r/s)^j} such that T(t/u) < T(r/s) are powers of p/q.
![]()
![]()
![]()
Message: 5086 Date: Mon, 26 Nov 2001 17:12 +0 Subject: Re: Tormented by Torsion again From: graham@xxxxxxxxxx.xx.xx In-Reply-To: <memo.663318@xxx.xxxxxxxxx.xx.xx> I wrote: > Incidentally, you did say 256:243 and 65536:59049 before, but my > comments were for 256:243 and 16807:15552, although I didn't point that > out. 65536:59049 is (256:243)^2. So 256:243 and 16807:15552 aren't > Minkowski reduced, but there's no particular reason why they should be. Aaaaaaaaargh! 256:243 and 16807:15552 are Minkowski reduced. 256:243 and 65536:59049 are not (they reduce to 256:243 and 1:1). Graham
![]()
![]()
![]()
Message: 5087 Date: Mon, 26 Nov 2001 17:54 +0 Subject: Re: Tormented by Torsion again From: graham@xxxxxxxxxx.xx.xx In-Reply-To: <9tttj7+v8k6@xxxxxxx.xxx> Paul wrote: > > Okay, we'll assume 256:243 and 16807:15552 are Minkowski reduced > then. > > 63:64 and 49:48 describe the same temperament. > > Hmm . . . so this is one of the torsion-spawning cases? Can you show > how this works? How I generated <input vectors *>: I went through each pair of unison vectors in your list. (Some list, Gene seems to have a longer one.) I worked out the linear temperament consistent with each pair of unison vectors, and optimized it. Then I used the method that Temperament objects already have to return the simplest unison vectors I could find. That's what <#!/usr/local/bin/python *> does. Unfortunately, that method sometimes throws up unisons that are way too complex, and it's related to torsion. So I went through and listed them. 256:243 and 16807:15552 are [8, -5, 0, 0] and [-6, -5, 0, 5] in vector form. 63:64 and 49:48 become [-6, 2, 0, 1] and [-4, -1, 0, 2]. Both pairs give the same mapping by period and generator: [(5, 0), (8, 0), (10, 1), (14, 0)]. We can verify this [ 8 -5 0 0][ 5 0] [0 0] [-6 -5 0 5][ 8 0] = [0 0] [-6 2 0 1][10 1] [0 0] [-4 -1 0 2][14 0] [0 0] We can also transform the first pair into the second pair ([-6, -5, 0, 5]-3*[8, -5, 0, 0])/5 = [-6 2 0 1] This would be i=-3/5, j=1/5 (2*[-6, -5, 0, 5]-[8, -5, 0, 0])/5 = [-4 -1 0 2] Which is i=-1/5, j=2/5. However, the Minkowski criterion as we currently understand it, and my reduction method, don't allow for fractional values of i and j. The practical difficulty in implementing this is that the vectors have to get bigger before they can be simplified by dividing through by a common factor. That makes the search harder. A brute force approach would work, trying every possible vector and seeing if it approximates to a unison. I'll look at this if I find the time. Another idea would be to list all members of the second-order odd limit that approximate to be the same. Any more complex unison vectors probably won't be that interesting anyway. Graham
![]()
![]()
![]()
Message: 5088 Date: Mon, 26 Nov 2001 01:07:34 Subject: Survey VIII From: genewardsmith@xxxx.xxx <4375/4374, 3136/3125> Minkowski reduced Ets: 19, 80, 99, 118 Map: [3 -2] [2 3] [4 2] [1 11] The adjusted mappings are pretty horrendous, and this might be used instead, with generators a' = 46.9967/99 and b' = 20.9953/99. Adjusted map: [ 0 1] [-13 5] [-14 6] [-35 12] Generators: a = .2626420944 (~6/5) = 26.00156735 / 99; b = 1 Errors and 99 et: 3: 0.828 1.975 5: 1.299 1.565 7: 0.206 0.871 <2048/2025, 50/49> Minkowski reduced Ets: 10, 12, 22 Map (no adjustment) [ 0 2] [-1 4] [ 2 3] [ 2 4] Generators: a = .4093213919 (~4/3) = 9.995070622 / 22; b = 1/2 Errors and 22 et: 3: 6.86 7.14 5: -3.94 -4.50 7: 13.55 12.99 This is, of course, paultone, and it can be seen that we don't get much milage out of using anything but 12+10 in the 22-et for it. <3136/3125, 64/63> Minkowski reduction <3125/3087, 64/63> Ets: 12,13,25,37,49 Map (no adjustment) [ 0 1] [-5 2] [ 4 2] [ 10 2] Generators: a = .08140287107 = 3.01190623 / 37; b = 1 Errors and 37-et 3: 9.63 11.56 5: 4.42 2.88 7: 2.81 4.15 A 12-tone temperament for the adventurous <4375/4374, 2048/2025> Minkowski reduced Ets: 46, 80, 126 Map (no adjustment) [ 0 2] [ 1 3] [-2 5] [15 3] Generators: a = .08730149627 (~17/16) = 10.99998853 / 126 Errors and 126-et 3: 2.81 2.81 5: 4.16 4.16 7: 2.60 2.60 The difference between this and the 126-et is far below the limits of perceptibility, so this may as well be called 80+46. Of course the version in the 46-et is perfectly fine, and 17/16 is so close to 2^(11/126) that it can be used also.
![]()
![]()
![]()
Message: 5089 Date: Mon, 26 Nov 2001 17:19:35 Subject: Re: Tormented by Torsion again From: Paul Erlich --- In tuning-math@y..., graham@m... wrote: > In-Reply-To: <9ttq3j+5tck@e...> > Me: > > > Well, that's up to you. I don't see what we gain by enforcing the > > square > > > rule. > > Paul: > > It's not a square rule. But what we gain is simplicity. > > How? Because instead of the rule for Minkowski reduction, we use an even simpler rule. > And why is this worth losing perfectly valid results? You can also get additional valid results by increasing the number of unison vectors in our list. But shouldn't there be some "reasonableness" criteria applied? Otherwise, you'll get an infinite list of linear temperaments! > > Me: > > > What's a contrapositive? I've given an example that's fine when > > the rule > > > isn't satisfied, and lots that are fine even though it isn't. > > Paul: > > Right -- but I'm claiming you won't find an example that's _not_ fine > > when the rule is satisfied. > > Sorry, typo. > > Me: > > > {(p/q)^i (r/s)^j} > > > > > > assuming i and j are integers. > > Paul: > > Yes, they are integers -- I thought you said 49:48 and 63:64 was > > equivalent to this, and I took "your" word for it. So what _do_ you > > get when you Minkowski-reduce this system? Gene? > > Okay, we'll assume 256:243 and 16807:15552 are Minkowski reduced then. Let's call this statement G. See below. > 63:64 and 49:48 describe the same temperament. Hmm . . . so this is one of the torsion-spawning cases? Can you show how this works? > Incidentally, you did say 256:243 and 65536:59049 before, but my comments > were for 256:243 and 16807:15552, although I didn't point that out. I know, my typo. > 65536:59049 is (256:243)^2. OK, forget my typo, please. > So 256:243 and 16807:15552 aren't Minkowski > reduced, Now you're saying not G. You've claimed both G and not G, but you haven't given evidence for either. > but there's no particular reason why they should be. > > The vectors are > > [8, -5, 0, 0] > [-6, -5, 0, 5] > > How could you combine them to get anything simpler? My program's already > checking the simplest cases. [14, 0, 0, -5] being the obvious one. > > >>> 16384*16807 > 275365888 > >>> 16807*15552 > 261382464 > > I'm certain these are Minkowski reduced, if I've got the definition right. OK, so now you're saying G again, and you've given a reason why.
![]()
![]()
![]()
Message: 5090 Date: Mon, 26 Nov 2001 21:52:00 Subject: Re: Tormented by Torsion again From: genewardsmith@xxxx.xxx --- In tuning-math@y..., graham@m... wrote: > We can also transform the first pair into the second pair > > ([-6, -5, 0, 5]-3*[8, -5, 0, 0])/5 = [-6 2 0 1] > > This would be i=-3/5, j=1/5 > > (2*[-6, -5, 0, 5]-[8, -5, 0, 0])/5 = [-4 -1 0 2] > > Which is i=-1/5, j=2/5. Which gets rid of the 5-torsion. > However, the Minkowski criterion as we currently understand it, and my > reduction method, don't allow for fractional values of i and j. That's because it gives a different lattice--however, if we have torsion then we *want* a different lattice.
![]()
![]()
![]()
Message: 5091 Date: Mon, 26 Nov 2001 08:00:09 Subject: Re: Survey VIII From: Paul Erlich --- In tuning-math@y..., genewardsmith@j... wrote: > <2048/2025, 50/49> Minkowski reduced > > Ets: 10, 12, 22 > > Map (no adjustment) > > [ 0 2] > [-1 4] > [ 2 3] > [ 2 4] > > Generators: a = .4093213919 (~4/3) = 9.995070622 / 22; b = 1/2 > > Errors and 22 et: > > 3: 6.86 7.14 > 5: -3.94 -4.50 > 7: 13.55 12.99 > > This is, of course, paultone, I thought the minkowski reduced basis for paultone was <64/63, 50/49>. How can there be two minkowski reduced bases for paultone?
![]()
![]()
![]()
Message: 5092 Date: Mon, 26 Nov 2001 17:20:10 Subject: Re: Tormented by Torsion again From: Paul Erlich --- In tuning-math@y..., graham@m... wrote: > In-Reply-To: <memo.663318@c...> > I wrote: > > > Incidentally, you did say 256:243 and 65536:59049 before, but my > > comments were for 256:243 and 16807:15552, although I didn't point that > > out. 65536:59049 is (256:243)^2. So 256:243 and 16807:15552 aren't > > Minkowski reduced, but there's no particular reason why they should be. > > Aaaaaaaaargh! > > 256:243 and 16807:15552 are Minkowski reduced. > > 256:243 and 65536:59049 are not (they reduce to 256:243 and 1:1). > > > Graham Oh, OK, gotcha.
![]()
![]()
![]()
Message: 5093 Date: Mon, 26 Nov 2001 22:00:35 Subject: Re: Tormented by Torsion again From: genewardsmith@xxxx.xxx --- In tuning-math@y..., "Paul Erlich" <paul@s...> wrote: > > Okay, we'll assume 256:243 and 16807:15552 are Minkowski reduced > then. > Let's call this statement G. See below. It's true. > > 63:64 and 49:48 describe the same temperament. > > Hmm . . . so this is one of the torsion-spawning cases? Indeed it is. I just wrote a wedge product routine, and here is what I get: 16807/15552^256/243 = [70, 0, -40, 0, 25, 0] 64^63^49/48 = [-14, 0, 8, 0, -5,0] The first has coefficients with a gcd of 5, telling us there is 5-torsion; the second has a gcd of 1, telling us there is no torsion.
![]()
![]()
![]()
Message: 5094 Date: Mon, 26 Nov 2001 08:13:01 Subject: Tormented by Torsion again From: genewardsmith@xxxx.xxx --- In tuning-math@y..., "Paul Erlich" <paul@s...> wrote: > I thought the minkowski reduced basis for paultone was <64/63, > 50/49>. How can there be two minkowski reduced bases for paultone? I was just about to post using the above subject line when I saw this. I'm bummed :) The reason is that 2048/2025 * 50/49 = (64/64)^2, but no product of 2048/2025 and 50/49 makes 64/63. Neither LLL nor Minkowski got rid of this problem, so I will need to check all the results and see how to cure this disease.
![]()
![]()
![]()
Message: 5095 Date: Mon, 26 Nov 2001 22:08:29 Subject: Re: Tormented by Torsion again From: genewardsmith@xxxx.xxx --- In tuning-math@y..., graham@m... wrote: > > > Ah, but how about 64:63 and 3125:3087? > > > > > > [0, -2, 5, -3] > > > [6, -2, 0, -1] > > > > > > Lots of common factors, but (64:63)^2 = 4096:3969. > Paul: > > So this is a good one. Why do you bring this example up? Isn't it > > just a normal example? > > I don't know, what is "normal"? You can't combine these vectors to get a > 1 in any column but the last. That has something to do with torsion, but > I don't think it's the real problem. I get 64/63^3125/3087 = [-12, 30, -18, -10, 4, 5], and so no torsion. I'm with Paul--this seems quite normal to me.
![]()
![]()
![]()
Message: 5096 Date: Mon, 26 Nov 2001 08:38:54 Subject: Wedge products and the torsion mess From: genewardsmith@xxxx.xxx Perhaps wedge products are the best way of cleaning this up. If we write 2^a 3^b 5^c 7^d as a e2 + b e3 + c e5 + d e7 we can take wedge products by the following rule ei^ei = 0, and if i != j, then e1^ej = - ej^ei. In the 5-limit case, the wedge product will be, in effect, the correspodning val. In the 7-limit case, we get something six dimensional, which if we added another interval would give us a val. However, it still can be used to test for torsion. 50/49 = e2+2e5-2e7, 2048/2025 = 11e2+4e3-2e5. Taking the wedge product gives us 50/49^2048/2025 = 4e2^e3 - 24e2^e5 - 8 e3^e5 - 4 e5^e7. This has a common factor of 4. On the other hand 50/49^54/63 = -2 e2^e3 - 12 e2^e5 + 5 e2^e7 + 4 e3^e5 + 2 e3^e7 - 2 e5^e7, with a gcd of 1 for the coefficients. All is, therefore, not lost, I think. I'll ponder the question further.
![]()
![]()
![]()
Message: 5097 Date: Mon, 26 Nov 2001 08:54:59 Subject: Re: Wedge products and the torsion mess From: genewardsmith@xxxx.xxx --- In tuning-math@y..., genewardsmith@j... wrote: >I'll ponder the question > further. One way to see what is going on is this: if the wedge product has a common factor, then whatever we pick as another basis interval in order to compute the corresponding val will also have a common factor when we take determinants, and hence show torsion according to our usual test of the gcd of the coefficients of the val. Therefore the torsion is already present in the two elements we started with. 2048/2025 and 50/49 cannot be extended in a non-torsion way to three 7-limit intervals, in other words, which would be suitable for a block. This is the same problem as before, in a more insidious form.
![]()
![]()
![]()
Message: 5098 Date: Mon, 26 Nov 2001 08:58:23 Subject: Re: Wedge products and the torsion mess From: Paul Erlich --- In tuning-math@y..., genewardsmith@j... wrote: > 2048/2025 and 50/49 cannot be extended in a non-torsion way to three > 7-limit intervals, in other words, which would be suitable for a > block. Well that's a nice clarification. So perhaps it would have been better to focus on scales, rather than linear temperaments, after all!
![]()
![]()
![]()
Message: 5099 Date: Mon, 26 Nov 2001 09:02:05 Subject: Re: Wedge products and the torsion mess From: genewardsmith@xxxx.xxx --- In tuning-math@y..., "Paul Erlich" <paul@s...> wrote: > So perhaps it would have been better to focus on scales, rather than > linear temperaments, after all! Not really--we will still get uniqueness after booting out the torsion crud, and some of the things I am getting this way it would not have occured to look at. I still plan on seeing if we are missing something we shouldn't by looking at it from the other side also. Of course this is one more piece of weirdness it probably would be a pain to explain to a non-mathematical readership. :(
4000 4050 4100 4150 4200 4250 4300 4350 4400 4450 4500 4550 4600 4650 4700 4750 4800 4850 4900 4950 5000 5050 5100 5150 5200 5250 5300 5350 5400 5450 5500 5550 5600 5650 5700 5750 5800 5850 5900 5950 6000 6050 6100 6150 6200 6250 6300 6350 6400 6450 6500 6550
5050 - 5075 -