What is the meaning of the decimal point in an EDA value in a JI par file? I thought that it meant the decimal number was the number of EDA steps the symbol is assigned, but this doesn't make sense since, for example, is 25\58EDA, but its apotome complement, , is 33.2\58EDA (the keen-eyed of you may have noticed that \(25 + 33.2\ne 58\)). The symbol that is assigned to 33\58EDA is , but its apotome complement is whose value is 25.8\58EDA. There are also many commas whose EDA value, if calculated this way, doesn't fall in their capture zones, all of which have some other commas that share the integer part of their EDA values.
With a search on the forum I found this post where Dave said "The ones with decimal places are split 58-EDA buckets", which seems to confirm my suspicion that the integer value is the "actual" value of both symbols and the decimal point part is used to distinguish between them, but then why not just have n.1 and then n.2 etc. if needed? What does the value of the fractional part actually mean? Also, is there some preference for one symbol over the other when notating 612edo? (which was the reason I looked at all of this stuff in the first place)
Also I just noticed that is assigned 13.5\58EDA but its opposite is assigned -13.4\58EDA, which looks like an actual mistake.
Decimal point in EDA values
- Dave Keenan
- Site Admin
- Posts: 2511
- Joined: Tue Sep 01, 2015 2:59 pm
- Location: Brisbane, Queensland, Australia
- Contact:
Re: Decimal point in EDA values
Good questions. George chose those numbers. But I'm pretty sure the part after the decimal point was intended as an approximate decimal-fraction part of a number of steps, not merely a distinguishing or ordering mark. You can see in George's original version of the JI Calculator spreadsheet, that he uses a formula to calculate non-integer values for Olympian.
They made some sense at the start of the development of the JI precision levels, when the precision levels actually were EDAs, and so there were only integer values for these numbers. But now they are useless for any precision levels other than Olympian and Athenian. As you can see here, https://sagittal.org/SagittalJI.gif, Promethean and Herculean are nothing like EDAs now. And as you have shown, those EDA columns are riddled with errors.
I believe those EDA columns should be deleted from the JI2.par and JI3.par files. The column heading isn't even correct in JI3.par. And the Short ASCII column should be deleted from all the JIx.par files.
The final use for those numbers may indeed be to help in notating 612-EDO (if it happens that's what George had in mind when he assigned them). But a 612 notation should also be informed by the considerations mentioned on this page when choosing the notation for 581-EDO.
They made some sense at the start of the development of the JI precision levels, when the precision levels actually were EDAs, and so there were only integer values for these numbers. But now they are useless for any precision levels other than Olympian and Athenian. As you can see here, https://sagittal.org/SagittalJI.gif, Promethean and Herculean are nothing like EDAs now. And as you have shown, those EDA columns are riddled with errors.
I believe those EDA columns should be deleted from the JI2.par and JI3.par files. The column heading isn't even correct in JI3.par. And the Short ASCII column should be deleted from all the JIx.par files.
The final use for those numbers may indeed be to help in notating 612-EDO (if it happens that's what George had in mind when he assigned them). But a 612 notation should also be informed by the considerations mentioned on this page when choosing the notation for 581-EDO.
Re: Decimal point in EDA values
I think I cracked it: They are intended to be a short way to specify (other?) capture zones for the symbols: the apotome fraction lower bound for upward pointing symbol is the "EDA value" minus a half, divided by the EDA steps (i.e. \(\frac{v-\frac12}s\)), and for downward pointing symbols the same calculation with a plus rather than a minus calculates upper bounds. This explains how decimal parts describe "split EDA buckets" and the weird stuff that happens with the apotome complements (with this interpretation giving "33.2 EDA steps" means the boundary between and it is 32.7\58EDA and giving "25.8 EDA steps" means the boundary between and it is 25.3\58EDA, which makes sure they are used as apotome complements).
I'll try to confirm or disprove my solution there then.Dave Keenan wrote: ↑Wed Nov 20, 2024 7:35 pm You can see in George's original version of the JI Calculator spreadsheet, that he uses a formula to calculate non-integer values for Olympian.
Why Olympian too? It also has fractional values.They made some sense at the start of the development of the JI precision levels, when the precision levels actually were EDAs, and so there were only integer values for these numbers. But now they are useless for any precision levels other than Olympian and Athenian.
If my solution to this riddle is correct then it can lead to some notation for 612—choose the ones whose capture zones contain the whole number EDA degrees, although this notation probably won't make a lot of intuitive sense. I have no need right now for a full 612edo notation, but I also looked at this problem a bit and found out that if we only use legal Herculean symbols we have no hope even for single shaft flag arithmetic: is the only symbol for 3 degrees and is the only one for 7, which means that <> has to be assigned 4 degrees, but we also have alone in the 9 bucket.The final use for those numbers may indeed be to help in notating 612-EDO (if it happens that's what George had in mind when he assigned them). But a 612 notation should also be informed by the considerations mentioned on this page when choosing the notation for 581-EDO.
- Dave Keenan
- Site Admin
- Posts: 2511
- Joined: Tue Sep 01, 2015 2:59 pm
- Location: Brisbane, Queensland, Australia
- Contact:
Re: Decimal point in EDA values
I agree, you have cracked it. The fixed ½-step offset from the lower bound, irrespective of the width of the capture zone, also explains how this EDA value may not even be inside the capture zone in some cases.רועיסיני wrote: ↑Thu Nov 21, 2024 2:33 am I think I cracked it: They are intended to be a short way to specify (other?) capture zones for the symbols: the apotome fraction lower bound for upward pointing symbol is the "EDA value" minus a half, divided by the EDA steps (i.e. \(\frac{v-\frac12}s\)), and for downward pointing symbols the same calculation with a plus rather than a minus calculates upper bounds. This explains how decimal parts describe "split EDA buckets" and the weird stuff that happens with the apotome complements (with this interpretation giving "33.2 EDA steps" means the boundary between and it is 32.7\58EDA and giving "25.8 EDA steps" means the boundary between and it is 25.3\58EDA, which makes sure they are used as apotome complements).
The other complication is that this is only strictly true for Olympian. The others then round their bounds to a nearby Olympian bound. I'm not sure if it is always the nearest Olympian bound.
If there are still some that are wrong according to this formula, please post them as an "issue" on the sagittal github.
It totally confirms your hypothesis.I'll try to confirm or disprove my solution there then.Dave Keenan wrote: ↑Wed Nov 20, 2024 7:35 pm You can see in George's original version of the JI Calculator spreadsheet, that he uses a formula to calculate non-integer values for Olympian.
Olympian only has 6 fractional values out of 116 below the half-apotome. I guess we should keep them in all the .par files, now that we understand them. Thanks.Why Olympian too? It also has fractional values.They made some sense at the start of the development of the JI precision levels, when the precision levels actually were EDAs, and so there were only integer values for these numbers. But now they are useless for any precision levels other than Olympian and Athenian.
OK. But that's a fairly mild violation, particularly if the symbol is not in the notation. One could say that the second left boathook has a different value from the first, in the way that shafts have different values. How should we notate that? <> = 4. <<>> = 5? «» = 5?If my solution to this riddle is correct then it can lead to some notation for 612—choose the ones whose capture zones contain the whole number EDA degrees, although this notation probably won't make a lot of intuitive sense. I have no need right now for a full 612edo notation, but I also looked at this problem a bit and found out that if we only use legal Herculean symbols we have no hope even for single shaft flag arithmetic: is the only symbol for 3 degrees and is the only one for 7, which means that <> has to be assigned 4 degrees, but we also have alone in the 9 bucket.The final use for those numbers may indeed be to help in notating 612-EDO (if it happens that's what George had in mind when he assigned them). But a 612 notation should also be informed by the considerations mentioned on this page when choosing the notation for 581-EDO.
Please feel free to propose a 612-EDO notation in the appropriate sub-forum. After all, in sagittal.pdf (page 18) we do claim to have notated "270, 282, 306, 311, 342, 388, 494, 612". In going back over emails with George, I can only find the recurring assumption that by notating Promethean and Herculean we had also notated 494 and 612. But I never found a specific subset that was chosen for either of these.
The 612-EDO notation doesn't have to be limited to Herculean symbols. I think it should be free to use any Athenian core with schisma accent that is allowed by Olympian. And any Promethean needed to fill in the gaps.
[Edit: Actually, maybe combinations of schisma accents with Athenian cores should be allowed outside of those in Olympian.]
Re: Decimal point in EDA values
Actually I checked this now and the formula is more complicated than this, because the cutoffs between the buckets are also far from the half-integer eda-values! What seems to work the best is that the eda value of a specific (positive) comma is \(i+\frac pb\) where \(i\) is the integer value, \(p\) is the sum of the sizes of the capture zones of all the previous commas in its bucket and \(b\) is the size of the entire bucket. I made a pull request which fixes the values that are still wrong even according to this formula. @cmloegcmluin you may want to take a look too.Dave Keenan wrote: ↑Thu Nov 21, 2024 9:47 am If there are still some that are wrong according to this formula, please post them as an "issue" on the sagittal github.
Re: Decimal point in EDA values
Another probably simpler way to state the new formula is that you divide the eda bucket in the same ratio as that of the real capture zones and then round the lower bounds to one decimal place.
- Dave Keenan
- Site Admin
- Posts: 2511
- Joined: Tue Sep 01, 2015 2:59 pm
- Location: Brisbane, Queensland, Australia
- Contact:
Re: Decimal point in EDA values
Thanks for figuring this out, Roee