back to list

h72 = h31 + h41

🔗monz <joemonz@yahoo.com>

2/11/2002 12:35:55 AM

hi Gene,

in an old post, you wrote:

/tuning-math/message/1168

> tuning-math Message 1168
> From: genewardsmith@j...
> Date: Fri Oct 5, 2001 6:18 am
> Subject: Re: 3rd-best 11-limit temperament
>
>
> . . . I've been meaning to suggest that Manuel
> consider putting into Scala a routine to calculate
> Gen(m, n, p) and Mos(n,m,p) for two ets m and n and
> a prime limit p; in case m and n are not relatively
> prime this needs to be adjusted by working inside of
> the interval of repetition. Of course one can also
> think of this in terms of the ets generated by linear
> combinations of hm and hn, as for instance
> h53 = h22 + h31 and h72 = h31 + h41.

by "h72 = h31 + h41", do you mean the following?

72-udo (unequal division of the octave),
the combination of 31edo and 41edo

~cents

(1200)
1170.731707
1161.290323
1141.463415
1122.580645
1112.195122
1083.870968
1082.926829
1053.658537
1045.16129
1024.390244
1006.451613
995.1219512
967.7419355
965.8536585
936.5853659
929.0322581
907.3170732
890.3225806
878.0487805
851.6129032
848.7804878
819.5121951
812.9032258
790.2439024
774.1935484
760.9756098
735.483871
731.7073171
702.4390244
696.7741935
673.1707317
658.0645161
643.902439
619.3548387
614.6341463
585.3658537
580.6451613
556.097561
541.9354839
526.8292683
503.2258065
497.5609756
468.2926829
464.516129
439.0243902
425.8064516
409.7560976
387.0967742
380.4878049
351.2195122
348.3870968
321.9512195
309.6774194
292.6829268
270.9677419
263.4146341
234.1463415
232.2580645
204.8780488
193.5483871
175.6097561
154.8387097
146.3414634
117.0731707
116.1290323
87.80487805
77.41935484
58.53658537
38.70967742
29.26829268
0

and can you explain a little more fully what
you wrote there?

-monz

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

🔗graham@microtonal.co.uk

2/11/2002 1:44:00 AM

In-Reply-To: <004101c1b2d7$1f67e5a0$af48620c@dsl.att.net>
monz wrote:

> by "h72 = h31 + h41", do you mean the following?
>
>
> 72-udo (unequal division of the octave),
> the combination of 31edo and 41edo

No, that's "the nearest-prime mapping of 72edo which is consistent with
the nearest-prime mappings of 31edo and 41edo." If you know how many
steps an interval approximates to in 31edo and 41edo, you can add them
together to get the approximation to 72edo where this equation holds.

Graham

🔗genewardsmith <genewardsmith@juno.com>

2/11/2002 2:06:40 AM

--- In tuning-math@y..., "monz" <joemonz@y...> wrote:
> by "h72 = h31 + h41", do you mean the following?
>
>
> 72-udo (unequal division of the octave),
> the combination of 31edo and 41edo

Not at all. I start by assuming the temperaments I am looking at are both regular and consistent, and regard them as defined by mappings from JI to abstract "notes" consisting of generator steps, and the tuning of the temperament by a mapping in turn of the "notes" to "tones" which are real numbers. In the case of the 11-limit,
"h31" is the mapping defined b sending 2 to 31, 3 to 49, 5 to 72,
7 to 87 and 11 to 107. BY definition h31(a*b) = h31(a) + h31(b), so this defines a mapping from any 11-limit interval to an integer. This one-dimensional mapping I call a "val"; it is in a sense the dual concept to interval. There is likewise a [41,65,95,115,142] mapping I call h41, and a [72,114,167,202,249] mapping I call h72. Denoting by
"g+h" the mapping which sends a to g(a)+h(a), we have h72=h31+h41; in terms of the mappings above regarded as column vectors, this is vector addition.

🔗monz <joemonz@yahoo.com>

2/11/2002 11:32:37 AM

hi Graham and Gene,

> From: <graham@microtonal.co.uk>
> To: <tuning-math@yahoogroups.com>
> Sent: Monday, February 11, 2002 1:44 AM
> Subject: [tuning-math] Re: h72 = h31 + h41
>
>
> In-Reply-To: <004101c1b2d7$1f67e5a0$af48620c@dsl.att.net>
> monz wrote:
>
> > by "h72 = h31 + h41", do you mean the following?
> >
> >
> > 72-udo (unequal division of the octave),
> > the combination of 31edo and 41edo
>
> No, that's "the nearest-prime mapping of 72edo which is consistent with
> the nearest-prime mappings of 31edo and 41edo." If you know how many
> steps an interval approximates to in 31edo and 41edo, you can add them
> together to get the approximation to 72edo where this equation holds.

> From: genewardsmith <genewardsmith@juno.com>
> To: <tuning-math@yahoogroups.com>
> Sent: Monday, February 11, 2002 2:06 AM
> Subject: [tuning-math] Re: h72 = h31 + h41
>
>
> --- In tuning-math@y..., "monz" <joemonz@y...> wrote:
>
> > by "h72 = h31 + h41", do you mean the following?
> >
> >
> > 72-udo (unequal division of the octave),
> > the combination of 31edo and 41edo
>
> Not at all. I start by assuming the temperaments I am looking
> at are both regular and consistent, and regard them as defined
> by mappings from JI to abstract "notes" consisting of generator
> steps, and the tuning of the temperament by a mapping in turn
> of the "notes" to "tones" which are real numbers. In the
> case of the 11-limit, "h31" is the mapping defined b sending
> 2 to 31, 3 to 49, 5 to 72, 7 to 87 and 11 to 107. BY definition
> h31(a*b) = h31(a) + h31(b), so this defines a mapping from any
> 11-limit interval to an integer. This one-dimensional mapping
> I call a "val"; it is in a sense the dual concept to interval.
> There is likewise a [41,65,95,115,142] mapping I call h41, and
> a [72,114,167,202,249] mapping I call h72. Denoting by "g+h"
> the mapping which sends a to g(a)+h(a), we have h72=h31+h41;
> in terms of the mappings above regarded as column vectors,
> this is vector addition.

so, then does this express what you're saying? :

[ 31 41 72] [2 3 5 7 11]
[ 49 65 114]
[ 72 95 167]
[ 87 115 202]
[107 142 249]

if it does, then i think i understand what you're doing.

and can you explain what you mean by 'a "val" ... is in
a sense the dual concept to interval' ? i don't get it.

-monz

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

🔗graham@microtonal.co.uk

2/12/2002 4:49:00 AM

In-Reply-To: <00cb01c1b332$dcdd1e60$af48620c@dsl.att.net>
monz wrote:

> so, then does this express what you're saying? :
>
> [ 31 41 72] [2 3 5 7 11]
> [ 49 65 114]
> [ 72 95 167]
> [ 87 115 202]
> [107 142 249]

Not really. The multiplication's the wrong way round. It should be

[2 3 5 7 11][ 31 41 72]
[ 49 65 114]
[ 72 95 167]
[ 87 115 202]
[107 142 249]

And then, you shouldn't be multiplying frequency integers like that, so
change it to

[log(2) log(3) log(5) log(7) log(11)][ 31 41 72]
[ 49 65 114]
[ 72 95 167]
[ 87 115 202]
[107 142 249]

And you still aren't saying anything about nearest approximations or how
they add up.

> and can you explain what you mean by 'a "val" ... is in
> a sense the dual concept to interval' ? i don't get it.

It helps if you understand wedge products. But yes, it's something like
that. I think the definition is that the wedge product of a val and an
integer will always be a scalar.

Graham

🔗monz <joemonz@yahoo.com>

2/12/2002 10:29:31 AM

> From: <graham@microtonal.co.uk>
> To: <tuning-math@yahoogroups.com>
> Sent: Tuesday, February 12, 2002 4:49 AM
> Subject: [tuning-math] Re: h72 = h31 + h41
>
>
> In-Reply-To: <00cb01c1b332$dcdd1e60$af48620c@dsl.att.net>
> monz wrote:
>
> > so, then does this express what you're saying? :
> >
> > [ 31 41 72] [2 3 5 7 11]
> > [ 49 65 114]
> > [ 72 95 167]
> > [ 87 115 202]
> > [107 142 249]
>
> Not really. The multiplication's the wrong way round. It should be
>
> [2 3 5 7 11][ 31 41 72]
> [ 49 65 114]
> [ 72 95 167]
> [ 87 115 202]
> [107 142 249]

hmmm . . . i had a hunch that that was the case.
i only wrote it that way so that the Yahoo interface
would put the bigger matrix in proper columns.
but why does it make a difference?

> And then, you shouldn't be multiplying frequency integers like that, so
> change it to
>
> [log(2) log(3) log(5) log(7) log(11)][ 31 41 72]
> [ 49 65 114]
> [ 72 95 167]
> [ 87 115 202]
> [107 142 249]

i had a hunch about that too. can't that be written
more easily as:

log([2 3 5 7 11]) [ 31 41 72]
[ 49 65 114]
[ 72 95 167]
[ 87 115 202]
[107 142 249]

> And you still aren't saying anything about nearest approximations or how
> they add up.

why not? please clarify, because that's exactly what i'm
trying to understand here.

> > and can you explain what you mean by 'a "val" ... is in
> > a sense the dual concept to interval' ? i don't get it.
>
> It helps if you understand wedge products. But yes, it's something like
> that. I think the definition is that the wedge product of a val and an
> integer will always be a scalar.

ok, thanks . . . i still haven't learned what a wedgie is.
still studying.

-monz

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

🔗graham@microtonal.co.uk

2/12/2002 1:20:00 PM

Me:
> > Not really. The multiplication's the wrong way round. It should be
> >
> > [2 3 5 7 11][ 31 41 72]
> > [ 49 65 114]
> > [ 72 95 167]
> > [ 87 115 202]
> > [107 142 249]
>

Monz:
> hmmm . . . i had a hunch that that was the case.
> i only wrote it that way so that the Yahoo interface
> would put the bigger matrix in proper columns.
> but why does it make a difference?

Try multiplying it out in Excel, using MMULT. You'll get different
results.

> i had a hunch about that too. can't that be written
> more easily as:
>
> log([2 3 5 7 11]) [ 31 41 72]
> [ 49 65 114]
> [ 72 95 167]
> [ 87 115 202]
> [107 142 249]

There is a definition of the logarithm of a matrix, but I don't think this
is it.

Me:
> > And you still aren't saying anything about nearest approximations or
> > how they add up.

Monz:
> why not? please clarify, because that's exactly what i'm
> trying to understand here.

There's nothing in the formula to say "take the nearest approximation" or
"this column plus this other one makes that column".

You can expend h31+h41=h72 to

[ 31] [ 41] [ 72]
[ 49] [ 65] [114]
[ 72] + [ 95] = [167]
[ 87] [115] [202]
[107] [142] [249]

If you want to understand it, try setting up a spreadsheet that calculates
the last column from the first two. Then get it to generate those columns
from their top entries, and the list of prime numbers.

> > It helps if you understand wedge products. But yes, it's something
> > like that. I think the definition is that the wedge product of a val
> > and an integer will always be a scalar.
>
>
> ok, thanks . . . i still haven't learned what a wedgie is.
> still studying.

The thing you have here as h72 is a val:

[ 72]
[114]
[167]
[202]
[249]

for an interval, take the comma 81:80. That's 2**-4 * 3**4 * 5**-1 or [-4
4 -1 0 0]. You get the representation of comma in h72 from the wedge
product comma^h72. That expands to give the matrix product

`[-4 4 1 0 0][ 72] = [1]
` [114]
` [167]
` [202]
` [249]

If you want to play with wedge products, you'll have to get my Python
library from <http://x31eq.com/temper.html>. Then you can do
things like

>>> import temper
>>> comma = temper.WedgableRatio(81,80)
>>> h72 = temper.PrimeET(72, temper.primes[:4])
>>> comma^temper.Wedgable(h72).complement()
{(0, 1, 2, 3, 4): 1}

I think my complement() method is doing what Gene calls the "dual" so I'll
rename it sometime.

Graham

🔗monz <joemonz@yahoo.com>

2/13/2002 2:13:56 PM

hi Graham,

> From: <graham@microtonal.co.uk>
> To: <tuning-math@yahoogroups.com>
> Sent: Tuesday, February 12, 2002 1:20 PM
> Subject: [tuning-math] Re: h72 = h31 + h41
>
>
> The thing you have here as h72 is a val:
>
> [ 72]
> [114]
> [167]
> [202]
> [249]
>
> for an interval, take the comma 81:80. That's 2**-4 * 3**4 * 5**-1 or [-4
> 4 -1 0 0]. You get the representation of comma in h72 from the wedge
> product comma^h72.

ahh . . . so now we have to use ** instead of ^ for
"raise to the power of", because now ^ is the wedge product.
yes?

> That expands to give the matrix product
>
> `[-4 4 1 0 0][ 72] = [1]
> ` [114]
> ` [167]
> ` [202]
> ` [249]

there's a typo in the row matrix on the left. the exponent of 5
should be -1 not 1, so that matrix should read `[-4 4 -1 0 0].

so then if ^ is the wedge product, is (81/80)^h72 = 1
the proper way to notate this?

-monz

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

🔗genewardsmith <genewardsmith@juno.com>

2/13/2002 2:46:12 PM

--- In tuning-math@y..., "monz" <joemonz@y...> wrote:

> so then if ^ is the wedge product, is (81/80)^h72 = 1
> the proper way to notate this?

It's certainly *possible* to interpret this in a way which makes sense, and notate it thusly, but I think it would be much preferable to write this as h72(81/80) = 1.

🔗monz <joemonz@yahoo.com>

2/13/2002 9:20:59 PM

> From: genewardsmith <genewardsmith@juno.com>
> To: <tuning-math@yahoogroups.com>
> Sent: Wednesday, February 13, 2002 2:46 PM
> Subject: [tuning-math] Re: h72 = h31 + h41
>
>
> --- In tuning-math@y..., "monz" <joemonz@y...> wrote:
>
> > so then if ^ is the wedge product, is (81/80)^h72 = 1
> > the proper way to notate this?
>
> It's certainly *possible* to interpret this in a way which
> makes sense, and notate it thusly, but I think it would be
> much preferable to write this as h72(81/80) = 1.

well, ok . . . now t h a t notation looks familiar, and
i understand it.

but i've seen ^ used in connection with wedgies, so my
question is still not really answered: do we have to use **
now to represent "raise to the power of"? apparently,
whatever ^ is being used for, it's something else other
than that.

-monz

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

🔗genewardsmith <genewardsmith@juno.com>

2/13/2002 11:03:59 PM

--- In tuning-math@y..., "monz" <joemonz@y...> wrote:

> but i've seen ^ used in connection with wedgies, so my
> question is still not really answered: do we have to use **
> now to represent "raise to the power of"? apparently,
> whatever ^ is being used for, it's something else other
> than that.

The "^" symbol is well-established as a notation both for exponentiation and wedge product; I would use it for either myself so long as there seemed no potential for confusion. Fortran gave us
"**" for exponentiation also, which is fine, and not used for anything else to my knowledge.