consistent Sagittal 37-Limit

User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: consistent Sagittal 37-Limit

Post by Dave Keenan »

Re: Comma lists
From George Secor 19/04/2007


--- Dave Keenan <d.keenan@bigpond.net.au> wrote:

> Hi George,

Hi Dave. I've been very busy lately, so have had to work on this off
and on -- but I *have* been diligently working on it.

> At 05:56 AM 13/04/2007, you wrote:
>> --- Dave Keenan <d.keenan@bigpond.net.au> wrote:
>>
>>> .~|('
>>> ')~|..
>>> seem to be in the wrong order.
>>
>> Yep, it would seem so. However, I again determined both a SoCA
(using
>> 455n or 65:77n) and an alternate SoCA (using 4375n or 13:125n) for
the
>> 3 possible symbols in the 27th mina, which gives the following
figures:
>>
>> )~|'' as 12.897c or 12.883c
>> .~|(' as 13.199c or 13.172c
>> ')~|.. as 13.186c or 13.200c
>>
>> Averaging out the figures for each symbol, .~|(' comes out lower
than
>> ')~|.., but I don't remember exactly why I split this mina into 3
>> parts. Since ')~|.. is more complicated than the other two symbols,
>> and since it's so close in size to .~|(', I now see that it would be
>> better not to use it. (Thanks for spotting that.)
>
> Trying the alternative values of the right accents is something I
> haven't been doing, but I agree it is a good thing to do and I plan
> to modify my spreadsheet to accommodate it.

Okay.

>> So here's how I would now assign the symbols.
>>
>> The five least complex commas for this mina are (in order of size):
>>
>> Cents Name Complex Pop. Rank
>> ------ ------- ------- ---------
>> 12.943 19:121C 49.462 962
>> 13.066 11:133C 44.456 817
>> 13.074 1715C 46.916 110
>> 13.189 35:247C 44.117 924
>> 13.269 11:23C 34.857 129
>
> I think we can ignore those with popularity rank above about 500.

Remember that you said this, because I'll bring it to your attention
below.

>> Taking both complexity and popularity rank into account, 11:23C gets
>> priority for a symbol assignment, with 1715C in 2nd place. They
both
>> compete for .|(', but 11:23C gets it, since it's closer. The choice
>> for )~|'' is clearly 19:121C. With these two symbol definitions,
the
>> symbol boundary would be at 13.106c, which puts 1715C in the )~|''
>> range, giving the two most important commas in the 27th mina
separate
>> symbols.
>>
>> Now I'll look at your spreadsheet selections and comment.
>>
>> You assigned ')~|.. to 1715C, so if we eliminate that symbol, we can
>> delete that assignment.
>
> If we eliminate that symbol then I'd end up assigning it as a
> secondary comma for .~|(' 11:23C. I don't think that considering
> alternate right flags would change that.

That's not what I had in mind. If at all possible, I would want
different symbols for 1715C and 11:23C, the two commas most worthy of
notating. I don't think this is an unreasonable expectation,
considering that they're ~0.195c apart.

> That's because I haven't accepted your practice of assigning commas
> to symbols with the same mina irrespective of whether they are closer
> to that symbol's SoCA.

Irrespective of whether they are closer than what? -- than another,
less popular / more complex comma? If so, then all symbols would have
to be SoCA, otherwise there would always be another less popular / more
complex comma that's closer to SoCA.

> I don't feel that minas are relevant to superolympian at all.

They're relevant if members of the tuning list think that they are.
There's been a lot of discussion on the main list recently in looking
for octave divisions that are both high-limit consistent and divisible
by 12, for the purpose of defining useful logarithmic units of pitch
measurement. See messages 71110, 71115, 71160, 71166, 71249, and
71256. (No, I didn't start that thread!)

I'm working out both olympian (with about 12 minas up to 1/2-apotome
split in two parts) and superolympian (with most minas split in two,
and many in three parts) notations, both of which observe strict
233-EDA boundaries in order that: 1) they be compatible with one
another, 2) the 27-limit consistency offered by 2460-ET be guaranteed,
and 3) symbols may be converted directly to minas, which provide a
quick and convenient unit of measure for integer calculations.

> Or at
> least not _that_ relevant that they could allow a symbol to shift so
> far from its SoCA.

I agree that these shifts should not be large.

What is it in this example that you think gets too far from its SocA?
Here's what I'm proposing, using two symbols for the 27th mina:

Pop.
Cents Name Complex Rank Symbol Dev.1 Dev.2 Comments
------ ------- ------- ---- ------ ------ ------ ---------------
12.897 5:847C 47.654 814 .~|( +0.120 SoCA for )~|''
12.930 27-mina lower boundary )~|'' +0.033 +0.047 ===============
12.943 19:121C 49.462 962 )~|'' +0.046 +0.060 Primary role
13.066 11:133C 44.456 817 )~|'' +0.169 +0.183
13.074 1715C 46.916 110 )~|'' +0.177 +0.191 7-limit default
13.106 symbol boundary ====== )~|'' +0.209 +0.223 ===============
13.106 symbol boundary ====== .~|(' -0.094 -0.067 ===============
13.166 19:23C 56.739 448 .~|(' -0.033 -0.006
13.189 35:247C 44.117 924 .~|(' -0.010 +0.016
13.269 11:23C 34.857 129 .~|(' +0.069 +0.096 Primary role
13.399 71825C 91.989 284 .~|(' +0.200 +0.227 5-limit default
13.418 27-mina upper boundary .~|(' +0.218 +0.245 ===============

The primary roles for the two 27-mina symbols are <0.07c from the
principal SoCA, and no symbol boundary is farther than 1/2 mina
(0.244c) from a symbol's principal SoCA. I've disallowed 5:847C for
)~|'', since it's not atomically correct, substituting 19:121C, which
is of comparable popularity and complexity, and only 0.046c from SoCA.

>> You assigned .~|(' to 78125C -- whoa, that's 5^7, which is much more
>> complicated and less popular than 11:23C. (However, if you cut the
>> prime limit below 19, then this one would get it.)
>
> 78125C was on Gene's list so I thought it should at least be listed
> as a secondary (or tertiary) comma (we need to list these to reduce
> possibilities for Gene to complain). You would have noticed I did not
> put it in the column where all the primary commas are.

Yes, I see now.

>> You assigned )~|'' to 5:847C (SoCA); however, this is 26 minas,
which
>> is not atomically correct. Since there are at least 3 or 4 commas
less
>> complex and/or more popular than 5:847C in the 26th mina, we
shouldn't
>> be obligated to give it a symbol, which would then allow )~|'' to be
>> used in the 27th mina.
>
> 5:847C is another Geneism.

That one has enough badness and low enough popularity that I'd be
content to make it a secondary role for .~|( (primary role 5:17C),
particularly since it gets that symbol when you cut the prime limit to
11.

> Why not use all available 27 mina symbols even though some are very
> close to each other, since we have a lot of commas in this region.

There are only 3 possible symbols, including )~|'':

)~|'' as 12.897c or 12.883c
.~|(' as 13.199c or 13.172c
')~|.. as 13.186c or 13.200c

The overlapping SoCA's for .~|(' and ')~|.. make it very messy (or at
the very least ambiguous as to which is larger), in addition to the
fact that ')~|.. is ugly, and I'd prefer to omit it, providing that no
deserving comma is slighted. Remember what you said above, about
ignoring those with popularity rank above about 500 -- I would say the
same thing about rank approaching 500 if the complexity is also above
45 or 50. Here are the four 23-limit 27-mina commas that rank in the
top 500, in order of size:

Cents Name Complex Pop. Rank
------ ------- ------- ---------
13.074 1715C 46.916 110
13.166 19:23C 56.739 448
13.269 11:23C 34.857 129
13.399 71825C 91.989 284

11:23C and 71825C are both larger than the SoCA of all 3 possible
symbols, so it's impossible not to assign them the same symbol, either
.|(' or ')~|.. (preferably the former, since it's simpler) -- 11:23C
would take precedence over 71825C for a symbol assignment (on the basis
of all 3 considerations: complexity, pop. rank, and size).

19:23C could get ')~|.., but its low popularity rank and high
complexity are IMO not enough to insist that we provide a separate
symbol.

That leaves only 1715C, which shouldn't get the same symbol as 11:23C
and 71825C. If we assign .~|(' to 11:23C and )~|'' to 19:121C, the
boundary would be set at 13.106c, allowing )~|'' to default to 1715C.

>> I'll be looking at the rest of your spreadsheet over the next
several
>> days to see what else needs attention.
>
> Probably a lot. You could just flag what we agree on so far, e.g.
> with a green background, and send it back, and I'll do the alternate
> right accent thing.

Okay, but first I want to continue reviewing whatever differences I
see. If I agree with something you have, then I'm changing what I
have, which will save us some time.

--George
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: consistent Sagittal 37-Limit

Post by Dave Keenan »

Re: Comma lists
From George Secor 21/04/2007


Hi Dave,

I'm answering 2 out of 3 messages today.

--- Dave Keenan <d.keenan@bigpond.net.au> wrote:

> At 07:20 AM 19/04/2007, you wrote:
>> --- Dave Keenan <d.keenan@bigpond.net.au> wrote:
> ...
>>> Trying the alternative values of the right accents is something I
>>> haven't been doing, but I agree it is a good thing to do and I
plan
>>> to modify my spreadsheet to accommodate it.
>>
>> Okay.
>
> Still not done. Sorry.

No problem. Take your time.

>>> I think we can ignore those with popularity rank above about 500.
>>
>> Remember that you said this, because I'll bring it to your attention
>> below.
>
> A foolish consistency is the hobgoblin of little minds.

Here's something to which you can pay little mind:

Q: What is mind?
A: No matter.
Q: What is matter?
A: Never mind.

> ...
>>> That's because I haven't accepted your practice of assigning
commas
>>> to symbols with the same mina irrespective of whether they are
closer
>>> to that symbol's SoCA.
>>
>> Irrespective of whether they are closer than what? -- than another,
>> less popular / more complex comma?
>
> No. Closer than the other adjacent symbol's SoCA.

But suppose that we've agreed to use only one of two symbols in a
particular instance for superolympian, and the symbol with SoCA closer
to the ratio to be notated is more complicated than the farther one?
What then?

1) Must we use the more complicated symbol and discard the simpler one?


2) Or must we define the simpler symbol with a less popular / more
complex (LPMC) ratio and then have the symbol default to the more
popular / less complex (MPLC) ratio at the current level of precision
(even if that's superolympian)?

3) Or should we disregard the more complicated symbol and simply assign
the simpler symbol to the MPLC ratio. If someone later decides to take
Sagittal up to a higher level of precision that requires both symbols,
then the superolympian symbol assignment becomes the superolympian
default, and the two symbols may then be redefined according to commas
that are closer to their SoCA's.

> ...
>>> I don't feel that minas are relevant to superolympian at all.
>>
>> They're relevant if members of the tuning list think that they are.
>> There's been a lot of discussion on the main list recently in
looking
>> for octave divisions that are both high-limit consistent and
divisible
>> by 12, for the purpose of defining useful logarithmic units of pitch
>> measurement. See messages 71110, 71115, 71160, 71166, 71249, and
>> 71256. (No, I didn't start that thread!)
>
> I don't see how that makes minas relevant to a level of Sagittal
> specifically intended to go beyond them. Olympian is the domain of
> minas.

We have a few issues to deal with in this situation, where there aren't
anywhere near enough symbols to notate all of the degrees in whatever
finer unit of measure you intend to replace the mina.

From what you're saying, I'm concluding that if a comma doesn't come
within a unit or so (tina, or whatever) of the SoCA of any symbol, then
it can't be assigned to a symbol, and we must look for something LPMC.

What symbol does the MPLC symbol then default to, or (in other words),
will *all* of the boundaries between symbols be set halfway between
their defining commas (or between their SoCA's, as I see you're doing
it), or will the tina (or whatever unit) boundaries have any relevance?

If EDA-unit boundaries have no relevance, or if you're allowing that
symbols may be assigned to adjacent tinas, then in superolympian we can
no longer guarantee the 27-limit consistency we already have with
minas.

> A lot of other numbers were tossed around there besides 2460. In any
> case there is already a slight discrepancy between the 2460_EDO
> degree and the mina we are using, that is bound to cause problems for
> commas near the boundaries anyway.

The consistency of 2460-EDO guarantees that these problems will be
encountered only with very complicated commas. The whole point of the
discussion was to find divisions of the octave where this would be the
case.

> So I don't think we should allow
> ourselves to be constrained by what may well be a momentary fad.

This subject has come up before on the list (on several occasions), so
I don't thinks it's a passing interest.

> Did you mention on the list that the pronunciation is "meena"?

No, I was more concerned with explaining its excellent properties.

> If, after defining athenian as 21-EDA, we had insisted that higher
> precision notations must have boundaries that correspond exatly to
> those, we would not now be using 233-EDA for olympian. We must allow
> the possibility that someone in future may define a new accent or
> something that will take Sagittal to new extremes of ridiculousness
> of resolution and should not do anything that would make that
> difficult.

Yes, that's a worthy goal.

> One way to make sure of that would be to invent it ourselves (but no
> need to tell anyone).

Tee hee!

> I've mentioned 2151-EDA in the past. That has a
> little over 9 times the resolution of 233-EDA (call them ninas or
> tinas?)

For that, I may prefer ninas (see below).

> and probably distinguishes the standard and alternative
> values for the right accents (although I haven't checked).
>
> Why not consider superolympian as an incomplete notation for 2151-EDA
> and set boundaries accordingly?

I did a quick consistency check for 2151-EDA. This is the virtual
equivalent of 22704-ET, which is 27-limit consistent. So far, so good.

To see how 2151-EDA compares with other EDO's of interest, I made some
consistency checks and came up with the following figures:

Consis error of odd harmonic (% of 1 deg of EDO)
EDA EDO Limit 3 5 7 min / max at 27-limit
---- ----- ------ ---- ---- ---- --------------------
233 2460 27 -0.8 +5.7 -9.3 -20.2 / +11.4
275 2901 17 +2.4 +8.7 13.7 -23.8 / +27.0
576 6079 29 +1.3 -0.1 +8.9 +31.3 / -15.1
809 8539 27 +0.5 +5.6 -0.4 +30.4 / -8.7
1105 11664 27 -0.3 +3.1 +1.2 +19.0 / -16.7
2151 22704 27 +1.1 -5.5 18.6 +24.4 / -18.6

The lower the 3-error, the more closely the EDO will agree with the
EDA. The lower the 5- and 7-errors, the higher the allowable
prime-exponent will be in a comma without encountering an
inconsistency. (Notice that 2901-EDO is not very good.)

One problem I have with 2151-EDA/22704-EDO is that 7 deviates by -18.6%
of 1deg22704. This indicates that a comma containing 7^3 will have a
cumulative error of -55.8% of a degree and probably won't be a
consistent number of tinas with respect to one containing a lower power
of 7.

1105-EDA/11664-EDO looks like a better choice across the board. I just
noticed that the maximum error of the 15-limit consonances (expressed
in actual cents!) in 11664-EDO (0.0200c, for 11/9) is less than that of
22704-EDO (0.0213c, for 13/7). It not only has 455n and 4375n *easily*
falling within the same (4-unit) |' boundaries, but also 65:77n and
13:125n *easily* within the same (8-unit) |'' boundaries, so it's a
fourfold division of the mina. (11664 is also divisible by 12, which
was one of the requirements on the tuning list for a measuring unit.)
I already suggested the name "quartina", so this is my nomination for
the "tina".

Will the real "Tina" please stand up?

>> I agree that these shifts should not be large.
>>
>> What is it in this example that you think gets too far from its
SocA?
>
> 1715C is significantly closer to the SoCA of .~|( than it is to the
> SoCA of )~|''

1715C is 13.074c. I'm repeating this from a previous message:

There are only 3 possible symbols, including )~|'':
)~|'' as 12.897c or 12.883c
.~|(' as 13.199c or 13.172c
')~|.. as 13.186c or 13.200c

I think you mean closer to SoCA of .~|(' than of )~|'' -- okay!
However, to get that, we would have to use all 3 symbols. (You've
convinced me.)

If we assign the two MPLC commas to .~|(' and ')~|.., then we get
option 1:

Pop.
Cents Name Complex Rank Symbol Dev.1 Dev.2 Comments
------ ------- ------- ---- ------ ------ ------ ---------------
12.897 5:847C 47.654 814 .~|( +0.120 SoCA for )~|''
12.930 27-mina lower boundary= )~|'' +0.033 +0.047 ===============
12.943 19:121C 49.462 962 )~|'' +0.046 +0.060 Primary role
13.008 symbol boundary ======= )~|'' +0.111 +0.125 ===============
13.008 symbol boundary ======= .~|(' -0.191 -0.164 ===============
13.066 11:133C 44.456 817 .~|(' -0.133 -0.106
13.074 1715C 46.916 110 .~|(' -0.126 -0.099 Primary role
13.166 19:23C 56.739 448 .~|(' -0.033 -0.006
13.171 symbol boundary ======= .~|(' -0.028 -0.001 ===============
13.171 symbol boundary ======= ')~|.. 0.015 -0.029 ===============
13.189 35:247C 44.117 924 ')~|.. +0.003 -0.011
13.269 11:23C 34.857 129 ')~|.. +0.083 +0.069 Primary role
13.399 71825C 91.989 284 ')~|.. +0.213 +0.199 5-limit default
13.418 27-mina upper boundary= ')~|.. +0.232 +0.218 ===============

Only 2 commas on our list would get )~|'': 19:121C and 47C, since it
would get only about 1/6 mina of territory. The olympian-level symbol
for the 27th mina would be the simplest one, .~|(', which gets 1/3
mina. The ugly symbol ')~|.. not only gets slightly more than 1/2
mina, but also the least complex comma, 11:23C -- not as good as I had
hoped for.

If we use both principal values for the SoCA's, then .~|(' > ')~|..,
giving option 2:

Pop.
Cents Name Complex Rank Symbol Dev.1 Dev.2 Comments
------ ------- ------- ---- ------ ------ ------ ---------------
12.897 5:847C 47.654 814 .~|( +0.120 SoCA for )~|''
12.930 27-mina lower boundary= )~|'' +0.033 +0.047 ===============
12.943 19:121C 49.462 962 )~|'' +0.046 +0.060 Primary role
13.008 symbol boundary ======= )~|'' +0.111 +0.125 ===============
13.008 symbol boundary ======= ')~|.. 0.177 -0.191 ===============
13.066 11:133C 44.456 817 ')~|.. -0.120 -0.134
13.074 1715C 46.916 110 ')~|.. -0.112 -0.126 Primary role
13.166 19:23C 56.739 448 ')~|.. -0.019 -0.033
13.171 symbol boundary ======= ')~|.. 0.015 -0.029 ===============
13.171 symbol boundary ======= .~|(' -0.028 -0.001 ===============
13.189 35:247C 44.117 924 .~|(' +0.010 -0.016
13.269 11:23C 34.857 129 .~|(' +0.069 +0.096 Primary role
13.399 71825C 91.989 284 .~|(' +0.200 +0.227 5-limit default
13.418 27-mina upper boundary= .~|(' +0.218 +0.245 ===============

Again, the same 2 commas on our list get )~|'' in the lowest 1/6 mina.
The ugly symbol ')~|.. now gets 1/3 mina. The olympian-level symbol
would still be .~|(', but now it gets slightly more than 1/2mina and
the least complex comma, 11:23C, in addition to making 71825C (from
Gene's list) easier to notate.

> ...
> Why does 19:121C deserve a symbol primary role?

It doesn't. It's just that )~|'' deserves to be used. In promethean,
the most natural place for a boundary is between )~| and ~|( is between
27 and 28 minas (same place as an athenian boundary), so DAFLR is
promoted by devoting as much 27-mina territory as possible to )~|-cored
symbols.

> I don't think it
> does. So do we need to use )~|'' at all? If we use it, it seems to me
> that 5:847C deserves it more than 19:121C does, as 5:847C is SoCA and
> ever so slightly more popular and lower prime limit, though more
> complex according to your rating.
>
> You may remember that my only real criticism of your complexity
> rating was that it seemed to introduce higher primes too soon.
>
> So maybe we only need one 27 mina symbol.

Yes, maybe. Using only .~|(' (defined as 1715C) would minimize the
territory given to ')~|.. by completely eliminating it.

I'll have to give this some thought.

> But if we have two, why
> must the boundary be at 13.106. My approach ignores minas and puts
> the boundary midway between symbol SoCAs (assuming only the standard
> definitions of the right accents at this stage). How is your boundary
> calculated?

I put the boundaries halfway between the commas that define the
symbols.

--George
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: consistent Sagittal 37-Limit

Post by Dave Keenan »

Re: Comma lists
From George Secor 25/04/2007


Hi Dave,

I'm going to reply to the off-comma-topic stuff in a separate message,
as a new subject, so the comma lists material continues here:

> ...
>> 3) Or should we disregard the more complicated symbol and simply
assign
>> the simpler symbol to the MPLC ratio. If someone later decides to
take
>> Sagittal up to a higher level of precision that requires both
symbols,
>> then the superolympian symbol assignment becomes the superolympian
>> default, and the two symbols may then be redefined according to
commas
>> that are closer to their SoCA's.
>
> That certainly seems consistent with the way we've been going from
> athenian to olympian.

Okay!

>> We have a few issues to deal with in this situation, where there
aren't
>> anywhere near enough symbols to notate all of the degrees in
whatever
>> finer unit of measure you intend to replace the mina.
>>
>> From what you're saying, I'm concluding that if a comma doesn't
come
>> within a unit or so (tina, or whatever) of the SoCA of any symbol,
then
>> it can't be assigned to a symbol, and we must look for something
LPMC.
>>
>> What symbol does the MPLC symbol then default to, or (in other
words),
>> will *all* of the boundaries between symbols be set halfway between
>> their defining commas (or between their SoCA's, as I see you're
doing
>> it), or will the tina (or whatever unit) boundaries have any
relevance?
>>
>> If EDA-unit boundaries have no relevance, or if you're allowing that
>> symbols may be assigned to adjacent tinas, then in superolympian we
can
>> no longer guarantee the 27-limit consistency we already have with
>> minas.
>
> That's correct. I'm assuming that some symbols will cover multiple
> tinas. Superolympian must be accepted as incomplete in a sense. But
> then again if we don't tell anyone anything about the relationship
> between superolympian and tinas they wouldn't _expect_ any kind of
> consistency of adding up tina numbers. Remember that the top level of
> Sagittal is _not_ supposed to be based on any equal division. It is
> strictly JI. We use the equal divisions as a ladder to climb up, but
> then we must throw away the ladder.

Must we, now? That doesn't seem appropriate to me, if we're
entertaining the thought of developing the semantics (if not the
symbols) of a still higher level of resolution.

> I see that there are two different sets of boundaries needed here
> during the process. Initially we need boundaries to help us decide
> what commas to assign to what symbols. These could be tina
> boundaries. Then once we have our set of symbols and their primary
> commas we can throw away those boundaries and place them midway
> between primary commas.

Hmmm, that's not what I had in mind, because it throws 27-limit
consistency out the door.

> Currently _I_ am using boundaries midway beween SoCAs for the initial
> boundaries and _you_ are apparently somehow trying to use boundaries
> midway between primary commas as the initial boundaries, before you
> have primary commas! Although I understand you are using mina
> boundaries to bootstrap this process.

Yes, and no. Inasmuch there aren't at present enough symbols to notate
all of the steps of a finer-than-mina division, I'm keeping *all* of
the mina boundaries, both before and after assigning primary commas,
for the simple reason that they're meaningful. It's only between two
commas *within the same mina* that I assign a boundary based on those
commas. This preserves the guarantee of 27-limit consistency based on
mina numbers, while still enabling one to make distinctions between
commas falling within the same mina boundaries. All minas are split
into 2 parts, excepting 1) those at 0, 44, 55, and 56 minas (where it's
not feasible), and 2) those that, for various reasons, are split into 3
parts.

As I've described it, this really shouldn't be called superolympian,
but rather atomic. It retains the boundaries (and therefore the
27-limit consistency) of olympian and, at the same time, allows greater
precision *within* most minas. In olympian, I also split 12 minas (in
2 parts) under 1/2-apotome, in those instances where two fairly popular
commas fall within the same mina boundaries.

> Or alternatively we could say that the superolympian level is not a
> level designed for approximation at all.

Symbol boundaries would then be meaningless.

> If you have a comma that
> doesn't have a superolympian symbol then you should go to the
> olympian level and use the symbol for the nearest mina.

As I've outlined it above, split-mina approximation can do better than
that.

> In theory, if someone extended the notation so every tina could be
> notated, then the superolympian level would become a level that could
> be used for approximation. But we would then undoubtedly have
> multiple symbols for many tinas and therefore there would also be a
> super-superolympian level which was not for approximation.

Could we now call levels by the following names?

Olympian: Minas of 233-EDA, with most unsplit, some split in 2;
Atomic: Minas of 233-EDA, with most split in 2, a few unsplit, some
split in 3;
Superolympian: Tinas of ?-EDA, with most unsplit, some split in 2;
Ultraolympian: Tinas of ?-EDA, with most split.

The mina boundaries could probably be adjusted by small amounts to
coincide with tina boundaries without compromising 27-limit
olympian/atomic consistency.

>> The consistency of 2460-EDO guarantees that these problems will be
>> encountered only with very complicated commas. The whole point of
the
>> discussion was to find divisions of the octave where this would be
the
>> case.
>
> I hadn't appreciated that before. You're quite right. Thanks.
>
> But the errors will change slightly and so the maximum consistent
> powers of low primes may change.

What do you mean? Between the EDO and the EDA? I pointed out on
tuning-math that the differences are very slight (as long as the
3-error is very low), and I think you agreed with that.

>> This subject has come up before on the list (on several occasions),
so
>> I don't thinks it's a passing interest.
>
> OK. But I don't think we should allow EDO divisibility by 12 to
> influence us too much.

I think we can have it, as well. >27-limit consistency is the greater
challenge.

>> I did a quick consistency check for 2151-EDA. This is the virtual
>> equivalent of 22704-ET, which is 27-limit consistent. So far, so
> good.
>>
>> To see how 2151-EDA compares with other EDO's of interest, I made
some
>> consistency checks and came up with the following figures:
>>
>> Consis error of odd harmonic (% of 1 deg of EDO)
>> EDA EDO Limit 3 5 7 min / max at 27-limit
>> ---- ----- ------ ---- ---- ---- --------------------
>> 233 2460 27 -0.8 +5.7 -9.3 -20.2 / +11.4
>> 275 2901 17 +2.4 +8.7 ­13.7 -23.8 / +27.0
>> 576 6079 29 +1.3 -0.1 +8.9 +31.3 / -15.1
>> 809 8539 27 +0.5 +5.6 -0.4 +30.4 / -8.7
>> 1105 11664 27 -0.3 +3.1 +1.2 +19.0 / -16.7
>> 2151 22704 27 +1.1 -5.5 ­18.6 +24.4 / -18.6
>>
>> The lower the 3-error, the more closely the EDO will agree with the
>> EDA. The lower the 5- and 7-errors, the higher the allowable
>> prime-exponent will be in a comma without encountering an
>> inconsistency. (Notice that 2901-EDO is not very good.)
>
> I think 3 error needs to be below 2%, 5 error below 7%, 7 error below
> 10% and 11 error below 25%.
>
> My method of finding such things is clearly wrong.
>
> Can you do the calculations for the actual EDA's, or at least show
> the 11 error too? 275 and 2151-EDA's are definietely out.

I thought you knew about my consistency spreadsheet, but if not, then
enter the EDO# in the cyan cell to see all of the odds up to 51:
http://tech.groups.yahoo.com/group/tuni ... nstncy.xls

Constncy.xlsx
(17.05 KiB) Downloaded 362 times

I haven't taken the trouble to adjust any of this for EDA's, but the
differences in the boundaries are very small. The apotome will change
by 7 times the 3-error, for 2460-ET <-> 233-EDA a shift of 0.02647c.
The half-apotome will shift by half that amount, or 0.01323c, and the
smaller minas by even less; e.g., in the 5C region the shift is ~0.005c
(about 1% of the width of a mina).

For EDO's that have a relative 3-error greater than that of 2460
(-0.8%), the relative shift will be somewhat more. But I don't think
that will be the case in whatever EDA we decide on for the tina.

> 576, 809 and 1105 are all very good. Is there no 31-limit consistent
> ET in this region? I keep thinking of the fact that Ben Johnston once
> composed in 31-limit.

That's a tough one. 20203-EDO (8539+11664, 1914-EDA) is 45-limit
consistent, with 0.3% 3-error, 0.9% 7-error, and 10.3% 11-error, but
its 5-error is 8.7% -- a little more than we would like. (Also, the
23-error, at 47.8%, though consistent, is rather excessive.)

I don't have any systematic way of looking for very many of these, so I
hope Gene will come up with some more suggestions.

>> One problem I have with 2151-EDA/22704-EDO is that 7 deviates by
-18.6%
>> of 1deg22704. This indicates that a comma containing 7^3 will have
a
>> cumulative error of -55.8% of a degree and probably won't be a
>> consistent number of tinas with respect to one containing a lower
power
>> of 7.
>
> Not probably, certainly. I agree 2151-EDA is out.
>
>> 1105-EDA/11664-EDO looks like a better choice across the board. I
just
>> noticed that the maximum error of the 15-limit consonances
(expressed
>> in actual cents!) in 11664-EDO (0.0200c, for 11/9) is less than that
of
>> 22704-EDO (0.0213c, for 13/7). It not only has 455n and 4375n
*easily*
>> falling within the same (4-unit) |' boundaries, but also 65:77n and
>> 13:125n *easily* within the same (8-unit) |'' boundaries, so it's a
>> fourfold division of the mina. (11664 is also divisible by 12,
which
>> was one of the requirements on the tuning list for a measuring
unit.)
>> I already suggested the name "quartina", so this is my nomination
for
>> the "tina".
>>
>> Will the real "Tina" please stand up?
>
> So which of the above properties _don't_ 576 and 809 have. An actual
> columnar comparison of the properties you mention would be good.

One shortcoming of 576 and 809-EDA is non-divisibility of the EDO by
12.

One undesirable thing about 576-EDA that I didn't spot in the 6079-EDO
consistency figures is that some commas are dangerously close to
boundaries. For example, 5C is only 0.0070c below the 109th degree
upper boundary, and 4375n barely makes it above the 2nd degree |' lower
boundary (with only 0.0010c to spare). This seems too close for
comfort.

While assigning commas to symbols, I used a spreadsheet that allows me
to compare the boundaries for 1105, 809, 576, 233, 58, 47, and 21-EDA,
and this is what alerted me to the dangers of 576-EDA.

Both 809 and 1105-EDA look a lot more "secure", particularly the
latter. Since 809-EDA splits minas into 1/3's, a single mini-accent
up/down pair is all that's needed to notate it. I'd be a little wary
about that 8.9% 7-error, however. If we're going into more precision,
then we're going to see higher 7-exponents: 7^5 takes you close to 45%
error, so only a miniscule additional amount contributed by some other
prime (e.g., 3^4 would add another 5.2%) would send it over the 50%
mark.

For 1105 you'd need both single and double mini-accents, since it
divides the mina into 1/4's, just as the mina divides the 5-schisma.
Its ET (11664) really delivers low error: -0.3% for 3, 3.1% for 5, 1.2%
for 7, and 19.0% for 11 (each of these figures is better than for
2460-ET). Plus it's 12-divisible. Unless we can find something
suitable that has a higher consistency limit, I'd say we go with this
one.

The rest of this message is about the 27th mina:

>> 1715C is 13.074c. I'm repeating this from a previous message:
>>
>> There are only 3 possible symbols, including )~|'':
>> )~|'' as 12.897c or 12.883c
>> .~|(' as 13.199c or 13.172c
>> ')~|.. as 13.186c or 13.200c
>>
>> I think you mean closer to SoCA of .~|(' than of )~|'' -- okay!
>
> Yeah. Sorry. Well spotted.
>
>> However, to get that, we would have to use all 3 symbols. (You've
>> convinced me.)
>
> But have I convinced me?

(Groan!) See below.

>> Again, the same 2 commas on our list get )~|'' in the lowest 1/6
mina.
>> The ugly symbol ')~|.. now gets 1/3 mina. The olympian-level symbol
>> would still be .~|(', but now it gets slightly more than 1/2mina and
>> the least complex comma, 11:23C, in addition to making 71825C (from
>> Gene's list) easier to notate.
>
> I'm afraid I just can't muster the concentration to follow this at
> the moment. But it sounds OK.
>
>>> Why does 19:121C deserve a symbol primary role?
>>
>> It doesn't. It's just that )~|'' deserves to be used. In
promethean,
>> the most natural place for a boundary is between )~| and ~|( is
between
>> 27 and 28 minas (same place as an athenian boundary), so DAFLR is
>> promoted by devoting as much 27-mina territory as possible to
)~|-cored
>> symbols.
>
> I see the problem.

Do you mean: 1) you see a problem with this, or 2) you now see the
problem (concern) that I've been attempting to address, or 3) both?

>>> I don't think it
>>> does. So do we need to use )~|'' at all? If we use it, it seems to
me
>>> that 5:847C deserves it more than 19:121C does, as 5:847C is SoCA
and
>>> ever so slightly more popular and lower prime limit, though more
>>> complex according to your rating.
>>>
>>> You may remember that my only real criticism of your complexity
>>> rating was that it seemed to introduce higher primes too soon.
>>>
>>> So maybe we only need one 27 mina symbol.
>>
>> Yes, maybe. Using only .~|(' (defined as 1715C) would minimize the
>> territory given to ')~|.. by completely eliminating it.
>>
>> I'll have to give this some thought.
>
> OK

I've given it some thought, and I've concluded that if it's a matter of
choosing between splitting into 3 or not splitting at all, then I'd go
for 3, because this is supposed to be higher resolution than olympian.
I'd avoid splitting minas only where it's not feasible.

I hope we're getting somewhere.

--George
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: consistent Sagittal 37-Limit

Post by Dave Keenan »

And you already have the next and last message from George that contains "11:23", here.
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: consistent Sagittal 37-Limit

Post by cmloegcmluin »

Thanks for sharing all this @Dave Keenan !

The 2nd page of it is all the 11:23C, so we don't have to worry about that stuff.
75 .(|(. 11:23S instead of ~|)''
This seems to confirm your theory that:
But which of the two valid (by mina arithmetic) symbols was assigned to the whole 75th mina before it was split? I can only assume it must have been :``::~|): because if it had been :,::.::(|(: there would not have been any DAFLL violation, which George clearly states as the reason for the split.

Then we must ask, why was George so resistant to assigning :,::.::(|(: to 47S? Surely the pre-existing boundary at the VH precision level (one level down), between :~|): and :.::(|(: would have either been at 18.5/58 of an apotome, or midway between their commas 49S and 11S, which you have shown amount to practically the same thing, which is very near 74.5 minas, which should have predisposed George to using :,::.::(|(: for the 75th mina.
But the real paydirt you hit, I think, is this bit:
>>> 2. Since there's such a thing as a Herculean default (58-EDA) for a symbol,
>>> which may be different from its once-and-for-all primary role, then might
>>> there not also be Olympian defaults (233-EDA) that are different from
>>> primary roles derived from considering all possible accented symbols.
>>
>> I hope not. But I do think that there should be promethean defaults
>> for symbols that are different from their primary roles.
>
> I can accept that there might be a few promethean defaults that differ from
> their primary roles, but there had better be a simple rule explaining why,
> not a bunch of random exceptions.

I already replied:
<< There will be -- with no exceptions! >>
but that was without thinking that we had tentatively agreed that all
primary ratios would be 23-limit. If the most popular ratio for a
particular number of minas is >23-limit, then that would be the
olympian default, but the primary ratio would be the most popular
23-limit ratio.

Here are the instances in which I think that this principle can be
applied without controversy:

# of   default  primary
minas  ratio    ratio
-----  -------  -------
  1    31:49n   455n
  2    13:37n   65:77n
 11    11:31k   605k
 22    5:53k    5:161k
 31    5:47C    7:143C
 42    19:73C   19:169C
 59    13:47C   605C
 66    53C      19:49C
 69    29S      13:17S
 75    47S      11:23S
 91    499S     17:49S
 98    83M      5:187M
108    7:29M    2375M
110    47M      11:85M

Here is evidence of a historical difference between default and primary values(/commas/ratios). I thought we had discussed this somewhere and decided there was no meaningful difference between default and primary. But it would seem at some point there was!

I understand the concept of default values per precision level which potentially deviate from the "once-and-for-all" primary comma... but I really don't like it. And it would seem it wasn't retained in the end.

If, at least at some point, 47S was to be merely the default value in Olympian, while 11:23 was the "once-and-for-all" primary comma, I feel like our confidence in dismissing the splitting of the 75th mina to include the 47S has grown that much stronger.

Perhaps we (well, you know, Dave) could now find evidence of where/when/how exactly the concept of precision level default values was eliminated. Then we'd be that much closer to simplifying this bit of the Extreme precision level notation.
Last edited by Dave Keenan on Fri May 29, 2020 8:36 am, edited 1 time in total.
Reason: Restored the formatting of George's table
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: consistent Sagittal 37-Limit

Post by cmloegcmluin »

I'm not quite sure what I mean by "58/59 eda". It's possible I'm simply mistaken about there being any 59-EDA aspect to the VHP Herculean level at all. I may have been seduced by the fact that both 612edo and 624edo have highly-accurate JI approximations. I'm pretty sure 624edo corresponds to 59-EDA. You might check the VHP boundaries to see if any of them are closer to odd half steps of 59 than odd half steps of 58.
My methodology was not airtight. A lot of these schisma-sized steps are split, since there are 54 symbols in the space of just 35 schisma steps. So I only checked the lower bounds of whole-numbered steps. Of these 35, 23 of them were closer to 58-EDA and 12 were closer to 59-EDA. So I wouldn't say there's a clear winner; we don't even quite have a 2/3rds majority.
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: consistent Sagittal 37-Limit

Post by Dave Keenan »

Cml wrote: Perhaps we (well, you know, Dave) could now find evidence of where/when/how exactly the concept of precision level default values was eliminated. Then we'd be that much closer to simplifying this bit of the Extreme precision level notation.
Sigh. Too hard. When you just said, "Search on <x> in your [George] email", I could cope with that.

I don't understand why you excluded the "splits". It seems like that would be more work. not less. Were they split 58-EDA buckets or split 59-EDA buckets (rhetorical)? There's a bias right there. Which is, I guess, what you meant by "not airtight".
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: consistent Sagittal 37-Limit

Post by cmloegcmluin »

Dave Keenan wrote: Thu May 28, 2020 6:05 pm I don't understand why you excluded the "splits". It seems like that would be more work. not less. Were they split 58-EDA buckets or split 59-EDA buckets (rhetorical)? There's a bias right there. Which is, I guess, what you meant by "not airtight".
It wasn't more work. Maybe I'm not being clear, or maybe I don't understand something about the step names I inherited from George's work. What I meant was that on the Boundaries tab of the JI calculator spreadsheet that some of the 58-EDA step names are whole and some are not. I considered the ones with decimal places to be "split" 58-/59- EDA and thus those boundaries would not even be trying to fall on a 58- / 59- EDA midpoint, thus wouldn't help make this call.
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: consistent Sagittal 37-Limit

Post by cmloegcmluin »

Dave Keenan wrote: Thu May 28, 2020 6:05 pm
Cml wrote: Perhaps we (well, you know, Dave) could now find evidence of where/when/how exactly the concept of precision level default values was eliminated. Then we'd be that much closer to simplifying this bit of the Extreme precision level notation.
Sigh. Too hard. When you just said, "Search on <x> in your [George] email", I could cope with that.
Maybe there's some relevant stuff on the Yahoo Tuning Group backup. I'll hunt soon.
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: consistent Sagittal 37-Limit

Post by Dave Keenan »

cmloegcmluin wrote: Fri May 29, 2020 6:03 am What I meant was that on the Boundaries tab of the JI calculator spreadsheet that some of the 58-EDA step names are whole and some are not. I considered the ones with decimal places to be "split" 58-/59- EDA and thus those boundaries would not even be trying to fall on a 58- / 59- EDA midpoint, thus wouldn't help make this call.
The ones with decimal places are split 58-EDA buckets, and thus not trying to fall on a 58-EDA midpoint, but some of them might fall near a 59-EDA midpoint due to invisible forces of mathematics. I suspect this because I think of both 612edo and 624edo as "good" divisions.
Post Reply