<blockquote>
  <p><strong>How would you interpret this?</strong> "(1780 + 80) * 3 on base 808, and add 2"</p>
</blockquote>

<p>As before, there is a confusing avoidance of specifying the unit under consideration, but the pattern is still that the last number is in minutes of arc, the middle in degrees, and the first in $30^\circ$ for the Zodiac divisions, so:
$$\begin{eqnarray*}
\frac{(1780+80)\times 3}{808} &amp;=&amp; 6+\frac{27}{30} + \frac{10}{30\times 60} + \frac{41}{30\times 60^2}+\ldots \\
&amp;=&amp; (6;\;27\!:\,10)\text{.}\end{eqnarray*}$$
The $+2$ makes this $(6;\;27\!:\,12)$, although this makes the second addend in minutes of arc while the first one is not. As before, the calculation is not rounded.</p>

<blockquote>
  <p>Eade has <code>(8; 11 : 7) - (6; 27 : 12) = (1; 3 : 55)</code>, but that doesn't work.</p>
  
  <p>That specific substr. gives me <code>(1; 13 : 55)</code>, which could be a typo in the paper, but that value doesn't carry things forward either.</p>
</blockquote>

<p>I think that you are correct that this is a typographical error, but the corrected value probably <em>is</em> carried forward--the error is just repeated again in Step 16. Note that $(1;\;13\!:\,55) = 43^\circ 55'$, which makes the corrected Step 16
$$296\sin(1;\;13\!:\,55) = 205.309 = (0;\;3\!:25)\text{,}$$
following the convention that the numerical value is re-interpreted as minutes of arc. On the other hand, if we follow what Step 16 actually says, we get a very different value:
$$296\sin(1;\;3\!:\,55) = 165.164 = (0;\;2\!:45)\text{.}$$</p>

<p>Granted, the value actually carried forward to Step 17 is $(0;\;3\!:24)$ instead, but the former is definitely much closer. This further discrepancy could also be an undocumented geographical correction (the procedure does, after all, have things like $+3$ and $+2$ at times), but I'm more inclined to guess that this is due to imprecision in the calculation of sine, as the paper indicates that a table was used.</p>

CC BY-SA 3.0
2015-10-08T15:33:12.357Z
2015-10-08T20:27:11.567Z
2015-10-08T20:27:11.567Z
Stan Liou
<p>This is a follow-up to <a href="https://astronomy.stackexchange.com/q/11753/9153">How to interpret this old degree notation?</a></p>

<p>It is about an old calendar system which generates a luni-solar calendar with a procedural method, using a handful of calculations and some constants derived from astronomical observations.</p>

<p>This method originates from ancient India. Today it is used in Thailand to determine public holidays and observance days (<em>uposatha</em> days) for Buddhist monks, which fall on New- and Full Moon days.</p>

<p>Actually it's a neat system that had allowed village "astronomers / astrologers" construct a calendar with a method they could memorize by rote learning, without astronomical tools to make precise measurements. It is dreadfully underdocumented, and I've been collating the method and it's practices in <a href="https://github.com/profound-labs/calculating-the-uposatha-moondays" rel="nofollow noreferrer">Calculating the Uposatha Moondays</a>.</p>

<p>Most useful have been the actual formulas in <a href="http://www.siamese-heritage.org/jsspdf/1991/JSS_088_0r_Eade_RulesForInterpolationInThaiCalendar.pdf" rel="nofollow noreferrer">Rules for Interpolation in the Thai Calendar</a> by J.C. Eade, it is just some basic arithmetic, but following his notation is a puzzle in itself.</p>

<p>Effectively I'm trying to implement these formulas (see image below), in a <a href="https://github.com/splendidmoons/suriya-go/blob/master/suriya.go" rel="nofollow noreferrer">golang package</a>.</p>

<p>With the earlier help, I arrived at <strong>step 13 (Mean Moon)</strong>. Hooray :)</p>

<p>Step <strong>14.</strong> and <strong>15.</strong> is a puzzle again.</p>

<h2>Step 14.</h2>

<p><strong>How would you interpret this?</strong> "(1780 + 80) * 3 on base 808, and add 2"</p>

<h2>Step 15.</h2>

<p>Eade has <code>(8; 11 : 7) - (6; 27 : 12) = (1; 3 : 55)</code>, but that doesn't work.</p>

<p>That specific substr. gives me <code>(1; 13 : 55)</code>, which could be a typo in the paper, but that value doesn't carry things forward either.</p>

<p>Things straighten up at step <strong>16., 17., 18.</strong>, which would produce the paper's results, to get there I faked the values for step 14. and 15, to work at least in the example case given in the paper.</p>

<p>In <a href="https://github.com/splendidmoons/suriya-go/blob/master/suriya.go" rel="nofollow noreferrer">suriya.go</a>
this business is happening in:</p>

<pre><code>func (suDay *SuriyaDay) Init(ce_year int, lunar_year_day int)
</code></pre>

<p><a href="https://i.sstatic.net/bMGRW.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/bMGRW.png" alt="JC Eade, Rules for Interpretation"></a></p>

<notation>
From Mean Moon to True Moon in an old procedural calendar
Gambhiro
# From Mean Moon to True Moon in an old procedural calendar

(Asked by: username_0 on 2015-10-08)

This is a follow-up to How to interpret this old degree notation?
It is about an old calendar system which generates a luni-solar calendar with a procedural method, using a handful of calculations and some constants derived from astronomical observations.
This method originates from ancient India. Today it is used in Thailand to determine public holidays and observance days (uposatha days) for Buddhist monks, which fall on New- and Full Moon days.
Actually it's a neat system that had allowed village "astronomers / astrologers" construct a calendar with a method they could memorize by rote learning, without astronomical tools to make precise measurements. It is dreadfully underdocumented, and I've been collating the method and it's practices in Calculating the Uposatha Moondays.
Most useful have been the actual formulas in Rules for Interpolation in the Thai Calendar by J.C. Eade, it is just some basic arithmetic, but following his notation is a puzzle in itself.
Effectively I'm trying to implement these formulas (see image below), in a golang package.
With the earlier help, I arrived at step 13 (Mean Moon). Hooray :)
Step 14. and 15. is a puzzle again.
Step 14.
How would you interpret this? "(1780 + 80) * 3 on base 808, and add 2"
Step 15.
Eade has (8; 11 : 7) - (6; 27 : 12) = (1; 3 : 55), but that doesn't work.
That specific substr. gives me (1; 13 : 55), which could be a typo in the paper, but that value doesn't carry things forward either.
Things straighten up at step 16., 17., 18., which would produce the paper's results, to get there I faked the values for step 14. and 15, to work at least in the example case given in the paper.
In suriya.go
this business is happening in:
func (suDay *SuriyaDay) Init(ce_year int, lunar_year_day int)

**Tags:** notation


---

## 1 answers

### Answer by username_1 on 2015-10-08. Score: 1 | Accepted answer

> **How would you interpret this?** "(1780 + 80) \* 3 on base 808, and add 2"

As before, there is a confusing avoidance of specifying the unit under consideration, but the pattern is still that the last number is in minutes of arc, the middle in degrees, and the first in $30^\circ$ for the Zodiac divisions, so:
$$\begin{eqnarray\*}
\frac{(1780+80)\times 3}{808} &=& 6+\frac{27}{30} + \frac{10}{30\times 60} + \frac{41}{30\times 60^2}+\ldots \\
&=& (6;\;27\!:\,10)\text{.}\end{eqnarray\*}$$
The $+2$ makes this $(6;\;27\!:\,12)$, although this makes the second addend in minutes of arc while the first one is not. As before, the calculation is not rounded.

> Eade has `(8; 11 : 7) - (6; 27 : 12) = (1; 3 : 55)`, but that doesn't work.
>
> That specific substr. gives me `(1; 13 : 55)`, which could be a typo in the paper, but that value doesn't carry things forward either.

I think that you are correct that this is a typographical error, but the corrected value probably *is* carried forward--the error is just repeated again in Step 16. Note that $(1;\;13\!:\,55) = 43^\circ 55'$, which makes the corrected Step 16
$$296\sin(1;\;13\!:\,55) = 205.309 = (0;\;3\!:25)\text{,}$$
following the convention that the numerical value is re-interpreted as minutes of arc. On the other hand, if we follow what Step 16 actually says, we get a very different value:
$$296\sin(1;\;3\!:\,55) = 165.164 = (0;\;2\!:45)\text{.}$$

Granted, the value actually carried forward to Step 17 is $(0;\;3\!:24)$ instead, but the former is definitely much closer. This further discrepancy could also be an undocumented geographical correction (the procedure does, after all, have things like $+3$ and $+2$ at times), but I'm more inclined to guess that this is due to imprecision in the calculation of sine, as the paper indicates that a table was used.


---

