Excessively-precise Approximation Of 12-edo

Application of dozenal to musical notation

Excessively-precise Approximation Of 12-edo

Dan
Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM

Apr 12 2017, 05:13 AM #1

Here is the "exact" tuning of one particular octave, calculated to the full default precision of Python's Decimal type. (Unfortunately, it does not have a dedicated Dozenal type; I suppose I should write one.) But suppose that the practical constraints of instrument making require you to approximate the frequency by a rational number (with a smaller denominator than the 10^25 implied by the above decimal approximations). What then? [url=http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1715&st=0]Continued fractions[/url] to the rescue! [i]To be continued... (Pun not intended)[/i]
Quote
Like
Share

Dan
Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM

Apr 20 2017, 04:34 AM #2

But why limit our calculations to one octave? Here are the frequencies for all 88 notes on a standard grand piano: [i]To be continued...[/i]
Quote
Like
Share

Dan
Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM

Apr 21 2017, 03:23 AM #3

What if we simply rounded each note frequency to the nearest integer number of hertz? As you would, for example, if your musical "instrument" were the Win32 [url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms679277(v=vs.85).aspx]Beep[/url] function? All but one of the A's are exact, as is expected from assigning an exact 440 Hz to one of them. The two highest C's are [i]almost[/i] exact, off by a mere 1/26733 of a semitone. Overall, this whole-hertz tuning is very good in the middle-to-upper range, with tones being consistently accurate to with a cent. But the bottom couple of octaves have some notes that are noticeably out of tune, by as much as 31 cents. (In this respect, the whole-hertz tuning is the opposite of period-based integer encoding, e.g., as used in the POKEY chip on [url=http://www.atariarchives.org/c3ba/page045.php]Atari 8-bit machines[/url], in which the [i]high[/i] notes are out of tune). If you want to be "all about that bass", you need fractional frequencies. [i]To be continued...[/i]
Quote
Like
Share

Dan
Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM

Apr 21 2017, 05:16 AM #4

One possibility is to represent the frequencies as [url=https://en.wikipedia.org/wiki/Double-precision_floating-point_format]double-precision floating-point numbers[/url], good to 53 significant bits. As a [i]binary[/i] floating-point representation, this approach has the advantage that an octave is [i]always[/i] an exact 2:1 frequency ratio. The fractions are unwieldy, though, with denominators as high as 2^47. [i]To be continued...[/i]
Quote
Like
Share

Dan
Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM

Apr 22 2017, 11:45 PM #5

Back to my original idea of using continued fractions. Take, for example, note 60 (Middle C), which has a frequency of 261.6255653005986346778499935 Hz. [261, 1, 1, 1, 2, 27, 3, 1, 3, 2, 1, 2, 5, 4, 1, 1, 6, 1, 1, 3, 17, 2, 1, 6, 4, 1, 2, 5, 2, 2, 1, 1, 2, 1, 1, 20, 3, 4, 3, 3, 3, 5, 1, 2, 1, 29, 1, 7, 3, 1, 1, 1, 1, 3, 3].

We could truncate this list at any point, getting the sequence of approximations 261, 262, 523/2, 785/3, 2093/8, 57296/219, 173981/665, 231277/884, 867812/3317, 1966901/7518, 2834713/10835, 7636327/29188, 41016348/156775, 171701719/656288, 212718067/813063, 384419786/1469351, 2519236783/9629169, 2903656569/11098520, 5422893352/20727689, 19172336625/73281587, 331352615977/1266514668, 681877568579/2606310923, 1013230184556/3872825591, 6761258675915/25843264469, 28058264888216/107245883467, 34819523564131/133089147936, 97697312016478/373424179339, 523306083646521/2000210044631, 1144309479309520/4373844268601, 2811925042265561/10747898581833, 3956234521575081/15121742850434, 6768159563840642/25869641432267, 17492553649256365/66861025714968, 24260713213097007/92730667147235, 41753266862353372/159591692862203, 859326050460164447/3284564524391295, 2619731418242846713/10013285266036088, 11338251723431551299/43337705588535647, 36634486588537500610/140026402031643029, 121241711489044053129/463416911683464734, 400359621055669659997/1530277137082037231, 2123039816767392353114/8114802597093650889, 2523399437823062013111/9645079734175688120, 7169838692413516379336/27404962065445027129, 9693238130236578392447/37050041799620715249, 288273744469274289760299/1101856174254445769350, 297966982599510868152746/1138906216054066484599, 2374042622665850366829521/9074199686632911161543, 7420094850597061968641309/28361505275952799969228, 9794137473262912335470830/37435704962585711130771, 17214232323859974304112139/65797210238538511099999, 27008369797122886639582969/103232915201124222230770, 44222602120982860943695108/169030125439662733330769, 159676176160071469470668293/610323291520112422223077, 523251130601197269355699987/2000000000000000000000000.

Or we could add 1 to the last element of the list, rounding the final denominator up instead of down. This gives us a different (but partially overlapping) sequence: 262, 523/2, 785/3, 1308/5, 2878/11, 59389/227, 231277/884, 405258/1549, 1099089/4201, 2834713/10835, 4801614/18353, 10471040/40023, 48652675/185963, 212718067/813063, 384419786/1469351, 597137853/2282414, 2903656569/11098520, 5422893352/20727689, 8326549921/31826209, 24595229977/94009276, 350524952602/1339796255, 1013230184556/3872825591, 1695107753135/6479136514, 7774488860471/29716090060, 34819523564131/133089147936, 62877788452347/240335031403, 132516835580609/506513327275, 621003395662999/2373634223970, 1667615562956041/6374054313232, 3956234521575081/15121742850434, 6768159563840642/25869641432267, 10724394085415723/40991384282701, 24260713213097007/92730667147235, 41753266862353372/159591692862203, 66013980075450379/252322360009438, 901079317322517819/3444156217253498, 3479057468703011160/13297849790427383, 13957983141674398012/53350990854571735, 47972738311969051909/183364107620178676, 157876198077581553739/603443313715107763, 521601332544713713126/1993694048765501965, 2523399437823062013111/9645079734175688120, 4646439254590454366225/17759882331269339009, 9693238130236578392447/37050041799620715249, 16863076822650094771783/64455003865065742378, 297966982599510868152746/1138906216054066484599, 586240727068785157913045/2240762390308512253949, 2672009605265361234982267/10213105902686977646142, 9794137473262912335470830/37435704962585711130771, 17214232323859974304112139/65797210238538511099999, 27008369797122886639582969/103232915201124222230770, 44222602120982860943695108/169030125439662733330769, 71230971918105747583278077/272263040640786955561539, 203898778281054330414363401/779353416959775155553846, 682927306761268738826368280/2610323291520112422223077.

Or we could ignore the continued fraction stuff altogether and just brute-force the denominators. To avoid any base-specific bias, I'll set the upper bound of the brute-forcing to 2520.

Code: Select all

def approximations(x):
    x = Fraction(x)
    result = {x}
    # Continued fraction approximations.
    cf = frac_to_contfrac(x)
    for i in range(1, len(cf)):
        cf_trunc = cf[:i]
        result.add(contfrac_to_frac(cf_trunc))
        cf_trunc[-1] += 1
        result.add(contfrac_to_frac(cf_trunc))
    # Brute force
    for denominator in range(1, 2521):
        numerator = int(denominator * x)
        result.add(Fraction(numerator, denominator))
        result.add(Fraction(numerator + 1, denominator))
    return result

def error_ratio(x, y):
    x = Fraction(x)
    y = Fraction(y)
    return max(x / y, y / x)

def best_approximations(x):
    x = Fraction(x)
    # Get a list of approximations and sort by denominator,
    # then by numerator if there are ties
    approx = list(approximations(x))
    approx.sort(key=lambda q: (q.denominator, q.numerator))
    # Build the list of best approximations
    result = []
    best_error = float('inf')
    for q in approx:
        err = error_ratio(q, x)
 &nbsp; &nbsp; &nbsp; &nbsp;if err < best_error&#58;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;best_error = err
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# Only allow one &#40;the best&#41; of each denominator.
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if result and q.denominator == result&#91;-1&#93;.denominator&#58;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;result&#91;-1&#93; = q
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;else&#58;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;result.append&#40;q&#41;
 &nbsp; &nbsp;return result
So, for Middle C, that gives us the sequence of approximations 262, 523/2, 785/3, 1308/5, 2093/8, 30087/115, 32180/123, 34273/131, 36366/139, 38459/147, 40552/155, 42645/163, 44738/171, 46831/179, 48924/187, 51017/195, 53110/203, 55203/211, 57296/219, 116685/446, 173981/665, 231277/884, 636535/2433, 867812/3317, 1966901/7518, 2834713/10835, 4801614/18353, 7636327/29188, 41016348/156775, 171701719/656288, 212718067/813063, 384419786/1469351, 2519236783/9629169, 2903656569/11098520, 5422893352/20727689, 19172336625/73281587, 331352615977/1266514668, 681877568579/2606310923, 1013230184556/3872825591, 6761258675915/25843264469, 28058264888216/107245883467, 34819523564131/133089147936, 62877788452347/240335031403, 97697312016478/373424179339, 523306083646521/2000210044631, 1144309479309520/4373844268601, 2811925042265561/10747898581833, 3956234521575081/15121742850434, 6768159563840642/25869641432267, 10724394085415723/40991384282701, 17492553649256365/66861025714968, 24260713213097007/92730667147235, 41753266862353372/159591692862203, 859326050460164447/3284564524391295, 2619731418242846713/10013285266036088, 11338251723431551299/43337705588535647, 36634486588537500610/140026402031643029, 121241711489044053129/463416911683464734, 400359621055669659997/1530277137082037231, 2123039816767392353114/8114802597093650889, 2523399437823062013111/9645079734175688120, 7169838692413516379336/27404962065445027129, 9693238130236578392447/37050041799620715249, 288273744469274289760299/1101856174254445769350, 297966982599510868152746/1138906216054066484599, 2374042622665850366829521/9074199686632911161543, 7420094850597061968641309/28361505275952799969228, 9794137473262912335470830/37435704962585711130771, 17214232323859974304112139/65797210238538511099999, 27008369797122886639582969/103232915201124222230770, 44222602120982860943695108/169030125439662733330769, 159676176160071469470668293/610323291520112422223077, 523251130601197269355699987/2000000000000000000000000. That's a lot of fractions; which one do we pick?

For my "overly precise" approximation, I will use the first one that, when converted to a float, has the same float representation as the true value.

Code: Select all

def overly_precise&#40;x&#41;&#58;
 &nbsp; &nbsp;x = Fraction&#40;x&#41;
 &nbsp; &nbsp;for q in best_approximations&#40;x&#41;&#58;
 &nbsp; &nbsp; &nbsp; &nbsp;if float&#40;q&#41; == float&#40;x&#41;&#58;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return q
For Middle C, it's 2519236783/9629169.

To be continued...
Quote
Like
Share

Dan
Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM

Apr 23 2017, 11:22 PM #6

Doing this gives the fractions The largest denominator is 90545469 (approximately 2**26.43), which is much better than the 2**47 obtained from using the [font=Courier]float[/font] representation directly. One problem though is that not all of the octaves are an exact 2:1 ratio. The ratio between notes 12 semitones apart ranges from 6787424391224759/3393712195612380 (1.999999999999999705337417447) to 8351705719714069/4175852859857034 (2.000000000000000239472039260). Though this is difference is so small that nobody would ever be able to hear it, I would like to exactly preserve the one "just" ratio that this irrational tuning has. [i]To be continued...[/i]
Quote
Like
Share

Dan
Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM

Apr 24 2017, 02:43 AM #7

Let's scale down everything to MIDI octave 0 (just below the threshold of human hearing). We need to pick [i]one[/i] tuning of each note in this octave. Then all other octaves can be obtained by multiplying by 2. But since this will cancel out the factors of 2 in the denominator, we don't necessarily want to use the smallest denominator. For this purpose, I'll use an "octave-neutral" measure of complexity from another thread about Just Intonation, where "complexity" is defined as the product of [i]odd[/i] factors in the numerator and denominator. I wonder if we can do better, though. [b]Feel free to chime in.[/b]
Quote
Like
Share

Piotr
Piotr

May 12 2017, 05:46 PM #8

Another option is to base on a just ratio for 1, 5, 7 or 11 steps. Here is a version with 18/17 for 1 step:

1/1
18/17
324/289
5832/4913
104976/83521
1889568/1419857
24137569/17006112
1419857/944784
83521/52488
4913/2916
289/162
17/9
2/1

Of course, using 4/3 for 5 steps or 3/2 for 7 steps gives us Pythagorean tuning.

Another option is to don't want equal-temperament. Here are ratios of a well-temperament:
C 1/1
C# 256/243
D 28/25
D# 32/27
E 5/4
F 4/3
F# 45/32
G 3/2
G# 128/81
A 375/224
A# 16/9
B 15/8
C 2/1

F#-C# is tempered by schisma down. Therefore the remaining Pythagorean comma becomes syntonic comma. This comma is distributed between G-D, D-A and A-E, about 7 cents down each. This ensures that C-E-G is pure, as well as G-B. Since EDOs are commonly used to approximate just ratios (and not the other way around), this well-temperament can be approximated by 171edo. Schisma is tempered, and syntonic/Pythagorean comma is mapped to 3 steps (about 21 cents). This interval is simply split in 3 to give 1 step (about 7 cents) of tempering to G-D, D-A and A-E. This is equal to 19-edo fifth as a coincidence.

Okay, enough explanation, here are Hz values in my custom fixed point format with 1 sign bit, 31 integer bits and 32 fractional bits:

C 264
C# 278.12345679
D 295.68
D# 312.88888889
E 330
F 352
F# 371.25
G 396
G# 417.18518519
A 441.96428571
A# 469.33333333
B 495
C 528

Note that I used C264/G396 instead of A440. Why? I wanted to choose an audio frequency so that G tone (my favorite one) could be represented exactly periodically (therefore giving exact square wave) with any octave. In other words, G tone * power of 2. I picked 396Hz because it still gives integer Hz 2 octaves lower and it's also divisible by 3 so you could conveniently get C value as 264 if C-G is 3/2.

EDIT: If you want to calculate fractional approximations, you can also use this tool:https://www.dropbox.com/s/4x5mggp4y1ykp ... c.sb2?dl=0
Open this file inhttps://scratch.mit.edu/projects/editor/?tip_bar=home
Quote
Share

davidk
Casual Member
davidk
Casual Member
Joined: Oct 25 2015, 01:24 PM

Nov 15 2017, 06:47 PM #9

Piotr

do you realise you posted the imperial system?
https://hypertextbook.com/facts/2003/DanielleDaly.shtml

using Pi as 22/7

C 264 84
D 295.68 94.08
E 330 105
F 352 112
G 396 126
A 441.9642857 140.625
B 495 157.5
C 528 168
Quote
Like
Share

Harold
Casual Member
Harold
Casual Member
Joined: Dec 25 2016, 09:47 PM

Nov 21 2017, 11:10 PM #10

davidk @ Nov 15 2017, 06:47 PM wrote: Piotr

do you realise you posted the imperial system?
https://hypertextbook.com/facts/2003/DanielleDaly.shtml

using Pi as 22/7

C 264 84
D 295.68 94.08
E 330 105
F 352 112
G 396 126
A 441.9642857 140.625
B 495 157.5
C 528 168
Hertz is an imperial unit? Since when? As far as I've ever known it has always been SI. There is no imperial unit of frequency. Since frequencies are not given in radian per second, the value of &#960; does not play a role.
Quote
Like
Share

Kodegadulo
Obsessive poster
Kodegadulo
Obsessive poster
Joined: Sep 10 2011, 11:27 PM

Nov 22 2017, 12:59 AM #11

Harold @ Nov 21 2017, 11:10 PM wrote: There is no imperial unit of frequency.
RPM, anyone?
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Base-neutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
Quote
Like
Share

davidk
Casual Member
davidk
Casual Member
Joined: Oct 25 2015, 01:24 PM

Nov 24 2017, 10:12 AM #12

The numbers will decimalise

For Harold

C 264 1000
E 330 1250
F 352 1333.333333
G 396 1500
B 495 1875
C 528 2000

left out the two tricky ones

528 is a naturally occurring number the foot is just a unit of conversion.

Nothing is more natural and harmonic to us than musical scales.

Ever seen anyone play the spreadsheet?
https://www.youtube.com/watch?v=q7l1QJWLWXE

sorry about the ad, can't get rid of it.
Quote
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Nov 24 2017, 10:24 AM #13

Since when did frequencies measured in hertz have anything to do with lengths measured in feet, even if the actual numerical values happen to be a factor of ten from each other?
Quote
Like
Share

davidk
Casual Member
davidk
Casual Member
Joined: Oct 25 2015, 01:24 PM

Nov 24 2017, 12:28 PM #14

They are both naturally occurring numbers, it must be just a coincidence,these numbers 528 264 13.333

It's just that 528 and 13.333 occur in the imperial when you use 100/99 as an adjustment factor and this happens in the musical numbers as well.
it seems a rather unlikely coincidence.
Quote
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Nov 24 2017, 12:34 PM #15

A rather likely coincidence, if you ask me, considering how Piotr did not use the of A4 = 440 Hz (and thus G4 ~ 392 Hz), but instead tinkered with it to give G4 = 396 Hz (which, being 11-smooth, provides ample opportunity for the sorts of numbers you are interested in to pop up). So all that needed to be done was a quick multiplication by 4/3 to get a just perfect fourth up to 528 Hz, some blithe disregard for units, and there you have an extremely likely and extremely meaningless coincidence.
Quote
Like
Share

davidk
Casual Member
davidk
Casual Member
Joined: Oct 25 2015, 01:24 PM

Nov 24 2017, 02:23 PM #16

https://hypertextbook.com/facts/2003/DanielleDaly.shtml

which is why i looked for some corroboative evidence

it was not hard to find.

I never knew C could be 264 Hz

it could be meaningless but I just find it very interesting since 5280 crops up all over the place, especially in eclipse calculations and natural number calculations.
Quote
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Nov 24 2017, 03:07 PM #17

davidk @ Nov 24 2017, 02:23 PM wrote: I never knew C could be 264 Hz
It could, but the pitch of Middle C has varied so much throughout history (examples from 223.75 Hz to 338.35 Hz are listed at that page, ranging from about modern Middle A to Middle E-half-sharp) that I don't see why 264 is any more interesting as a value than 256, 261.625 (the modern standard), or 250.65 (Mozart's pitch).
Quote
Like
Share

davidk
Casual Member
davidk
Casual Member
Joined: Oct 25 2015, 01:24 PM

Nov 24 2017, 07:16 PM #18

Double sharp

So if we have 264 hz is an octave higher going to be 528 hz?

and in decimal notation will F be `1333.333r?

using this notation Dylan's 'blowing in the wind' first line

How many roads must a man walk down, before you call him a man

in 4/4 time would be for the chords

4000, 5333.33r, 4000, 5333.33r, 4000, 5333.33r, 6000.

where 4000 is 4 beats of 1000.

and in imperial notation

3960,5280,3960,5280,3960,5280,5940.

i have always had a sort of 'feeling' that these numbers, in particular 5280 are naturally occurring not invented. i can't explain it rationally yet but the evidence is building up.


Some coincidences going on here.

5940/60 = 99

so base 100 =6000. sexigesimal
Quote
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Nov 24 2017, 11:01 PM #19

Yes, since 528 = 2 * 264, and because the perfect fourth is 4/3 in just intonation. In 12-tone equal temperament it is 2^(5/12) ~ 1.33484 instead. But you can't simply multiply 4 beats of "1000" to make "4000", because multiplying a frequency that way just means a note two octaves higher, and furthermore these chords are surely not individual notes but perfect triads.
Quote
Like
Share

davidk
Casual Member
davidk
Casual Member
Joined: Oct 25 2015, 01:24 PM

Nov 26 2017, 09:56 AM #20

yes musically it does not work, i see what you mean.

It would be great if 4000 resolved into a triad that works but it does not seem to.

Mathematically it does as a pythagorean triple but not musically that i can see but it is close.

Not sure what note 1666.666r 440hz is in the Piotr system but he seems to have deliberately excluded it but C 1000 and F 1333.333 are there.

C 1000 264
F 1333 352
? 1667 440
Total 4000 1056

Mathematically the whole thing is very harmonious but not sure it would be worth listening to!!

Piotr has also used fractional notation,.

Is fibonacci in the musical scale?

Piotr said 'Another option is to base on a just ratio for 1, 5, 7 or 11 steps. Here is a version with 18/17 for 1 step:'

This option must be close to fibonacci because 34 and 55 turn up in it although 55 needs a bit of finding.

This is how the construction of the system I am talking about appears as fractional notation - decimals are very impressive when they appear but ancient maths did not do decimals. The system goes further, and is more complex, than the imperial using primes to 17. It is 3,5,7,11,13,17, using 2 to the power 10 as the spine of the system.

The imperial finishes at prime 11 with prime 7 removed via Pi as 22/7.

22/7 works with Piotr system even if musically it is meaningless.

Dan's calculations

'One possibility is to represent the frequencies as double-precision floating-point numbers, good to 53 significant bits.

As a binary floating-point representation, this approach has the advantage that an octave is always an exact 2:1 frequency ratio'

This seems to have been the ancient way - floating point numbers - very complex but they used it.

Dan's calculations reveal the imperial system across the whole scale, it is quite remarkable to me, at any rate.

The problem is that although the Babylonian's left evidence they used a base 60 floating point system how could they have designed such a complex system. The obvious answer is - well they just couldn't have.

Not unless it is a naturally occurring system and they discovered bits of it, they don't seem to be using base 17 but base 11 seems to be probable. This thread is giving me some hope.
Quote
Like
Share

davidk
Casual Member
davidk
Casual Member
Joined: Oct 25 2015, 01:24 PM

Nov 27 2017, 10:59 AM #21

Using Dan's analysis it is possible to demonstrate the system that seems to be working at Stonehenge.

Line 105 99 3520 (1760 x 2) Two miles in yards

3520/99 = 35.55555556 A

3520/105 = 33.52380952 B

A-B = 2.031746032

A/2.031746032 = 17.5

B/2.031746032 = 16.5

The unit between is 17 and this translates to 102.This is what Thom discovered.

At Stonehenge the Aubrey circumference is 89760 not my numbers and verified to two independent sources.

89760 is 17 x 5280.

So the system goes beyond the imperial system quite naturally.

Double sharp raised the point that 256hz could just as easily be C but this again produces the same result using base 8.

256/8 = 32 264 /8 = 33 the base unit of the imperial system. 32 is also a root of the imperial system

5280 / 32 = 165 or 10 chains if imperial feet are used.

Hz on feet are irrelevant just the numbers and their relationships are under consideration here and the question is why is this happening? They appear to be naturally occurring. The origin of the units is a different question.

the system being looked at is this one

99 102 105 stated as 16.5, 17 and 17.5 so all x 6.

The suggestion is that the imperial system 5280 works with a base unit of 0.99 imperial feet to produce a base 100 system of 5333.333r units.

So the units for each number will be 0.99, 1.02 and 1.05.

the mile will pro rata giving 5280, 5440 and 5600 ( There is that Stonehenge Aubrey circle number again)

5280/.99 = 5333.3333r ( the imperial system)
5440/1.02 = 5333.3333r ( Thom's system)
5600 / 1.05 = 5333.3333r ( the roman system) According to Anne Macaulay)

Thom discovered a unit of 2.72 feet 0.17 x 16 feet
1.02 feet is 6 x 0.17 feet the same system exactly.

What unit works with 5333.333 feet?
It is base 100 so 100 x 0.12 of a foot and this is 12 inches.

This is one of the key observations concerning the imperial system.

It is a base 100 unit on a base 99 system ( naturally occurring possibly?)

The question always posed is one of insufficient evidence but in this case very persuasive evidence can be produced in the form of the Scottish Mile 5920 feet.

Pro rata measurements are 18.5 111 and 5920 producing a calculation of 111 x 0.12 feet = 1.11 feet.

5920 / 1.11 = 5333.333r

Note: Anne Macaulay wrote a book called 'Megalithic Measures and Rythms'

She was a gifted musician and investigated the natural fibonacci rythms in the stone circle survey drawings of Alexander Thom.

It is worth a read if you can get hold of a copy. It has become a collector's item.
https://www.amazon.co.uk/Megalithic-Mea ... c+measures
Quote
Like
Share