Excessivelyprecise Approximation Of 12edo
21 posts
• Page 1 of 1
Excessivelyprecise Approximation Of 12edo

DanDozens Disciple
 Joined: Aug 8 2005, 02:45 PM
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]

DanDozens Disciple
 Joined: Aug 8 2005, 02:45 PM
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/enus/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 wholehertz tuning is very good in the middletoupper 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 wholehertz tuning is the opposite of periodbased integer encoding, e.g., as used in the POKEY chip on [url=http://www.atariarchives.org/c3ba/page045.php]Atari 8bit 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]

DanDozens Disciple
 Joined: Aug 8 2005, 02:45 PM
One possibility is to represent the frequencies as [url=https://en.wikipedia.org/wiki/Doubleprecision_floatingpoint_format]doubleprecision floatingpoint numbers[/url], good to 53 significant bits.
As a [i]binary[/i] floatingpoint 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]

DanDozens Disciple
 Joined: Aug 8 2005, 02:45 PM
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 bruteforce the denominators. To avoid any basespecific bias, I'll set the upper bound of the bruteforcing to 2520.
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.
For Middle C, it's 2519236783/9629169.
To be continued...
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 bruteforce the denominators. To avoid any basespecific bias, I'll set the upper bound of the bruteforcing 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)
if err < best_error:
best_error = err
# Only allow one (the best) of each denominator.
if result and q.denominator == result[1].denominator:
result[1] = q
else:
result.append(q)
return result
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(x):
x = Fraction(x)
for q in best_approximations(x):
if float(q) == float(x):
return q
To be continued...

DanDozens Disciple
 Joined: Aug 8 2005, 02:45 PM
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]

DanDozens Disciple
 Joined: Aug 8 2005, 02:45 PM
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 "octaveneutral" 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]

Piotr
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 equaltemperament. Here are ratios of a welltemperament:
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 GD, DA and AE, about 7 cents down each. This ensures that CEG is pure, as well as GB. Since EDOs are commonly used to approximate just ratios (and not the other way around), this welltemperament 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 GD, DA and AE. This is equal to 19edo 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 CG 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
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 equaltemperament. Here are ratios of a welltemperament:
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 GD, DA and AE, about 7 cents down each. This ensures that CEG is pure, as well as GB. Since EDOs are commonly used to approximate just ratios (and not the other way around), this welltemperament 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 GD, DA and AE. This is equal to 19edo 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 CG 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

davidkCasual Member
 Joined: Oct 25 2015, 01:24 PM
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
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

HaroldCasual Member
 Joined: Dec 25 2016, 09:47 PM
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 π does not play a role.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

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
RPM, anyone?Harold @ Nov 21 2017, 11:10 PM wrote: There is no imperial unit of frequency.
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral 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)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral 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)

davidkCasual Member
 Joined: Oct 25 2015, 01:24 PM
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.
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.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
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?

davidkCasual Member
 Joined: Oct 25 2015, 01:24 PM
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.
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.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
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 11smooth, 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.

davidkCasual Member
 Joined: Oct 25 2015, 01:24 PM
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.
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.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
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 Ehalfsharp) 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).davidk @ Nov 24 2017, 02:23 PM wrote: I never knew C could be 264 Hz

davidkCasual Member
 Joined: Oct 25 2015, 01:24 PM
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
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

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
Yes, since 528 = 2 * 264, and because the perfect fourth is 4/3 in just intonation. In 12tone 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.

davidkCasual Member
 Joined: Oct 25 2015, 01:24 PM
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 doubleprecision floatingpoint numbers, good to 53 significant bits.
As a binary floatingpoint 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.
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 doubleprecision floatingpoint numbers, good to 53 significant bits.
As a binary floatingpoint 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.

davidkCasual Member
 Joined: Oct 25 2015, 01:24 PM
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
AB = 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/MegalithicMea ... c+measures
Line 105 99 3520 (1760 x 2) Two miles in yards
3520/99 = 35.55555556 A
3520/105 = 33.52380952 B
AB = 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/MegalithicMea ... c+measures