Pr b perisel

[Wiljea]

library+constants: PeriSel lunar perigee command and Moon T₀/Porb☽

B1. Add the validated PERISEL.rpl in the NEW astronomy command section, with
its header doc (epoch 2451534.6698, 35 terms, ~5 min, the 2016 & 2034
validation points, the apogee-value warning).
B2. Add Porb☽ (anomalistic month 2380713.11_s, abs unc 97165_s ≈ ±1.12 d)
after Prot☽, and set T0☽ = 'JDN→(PeriSel(→Num(JDN(DateTime))))'
(abs unc 600_s ≈ ±10 min), output _date. Same commit: matching
constants.md (ref Meeus ch.50). Depends on B1 (T0☽ calls PeriSel).

[evgaster]

Why put the PeriSel function in the library.cc ?
Why not a library/Perisel.48s and appropriate entry in config/library.csv ?

"Moon time of perigee passage" depends on DateTime.
It is not a constant! It should not be in constants.cc nor in config/constants.csv.

Maybe it could be provided as an equation.
But most appropriate would be as a library function.

[Wiljea]

PeriSel (Perigee of Selene) is a RPL command that will reside in the new Library "Astronomy". It will serve to compute T₀☽ up to around year 2100. It is the most recent time of perigee passage of the Moon (closest approach to Earth with a precision of ± 10 min). Since the perigee recurs approximately every 27.55 days, it can be considered as a constant parameter that changes every month.

In a sense, this can be considered a flight parameter in astronautics, with the same conceptual basis as T₀♂, which represents the last perihelion passage of Mars that also changes every Martian year (as do all other planets). This last flight parameter is therefore also a constant that varies over time (and will be implemented in the next release with the IFTE command and the orbital period Porb♂). It is important to understand that the whole purpose of the Astronomical Library constants is to provide the information necessary for future astronautical missions to precisely locate themselves within the solar system.

The next development I envision for DB48x will indeed be adding Rocketry and Astronautics sections to the Equation Library. I will then use these constants to solve example problems related to such astronautical missions.

[evgaster]

PeriSel (Perigee of Selene) is a RPL command that will reside in the new Library "Astronomy".

That doesn't answer my questions:

Why put the PeriSel function in the library.cc ?
Why not a library/Perisel.48s and appropriate entry in config/library.csv ?

the information necessary for future astronautical missions

If I now want to know the first "perigee passage of the Moon" in 2032 ... you expect me to change the date of my calculator and lookup the value of the "constant".

I reviewed your rpl code.
It deviates from Meeus, Astronomical Algorithms, 2nd ed., ch.50. You leave out the T power terms in your jdn0 variable and you leave out the T terms of the coefficients for the sine terms. Please explain.

[evgaster]

I have put your Perisel in /library/PeriSelJean.48s, my own implementation in /library/PeriSel.48s and added the following in /config/library.csv:

"Astronomy"
        "PeriSel",      "="
        "PeriSelJean",  "="

Here is my implementation PeriSel.zip.

It is very simple to add library functions. No need to mess with library.cc, so please don't.

[Wiljea]

Thanks @evgaster — the .48s setup and the new "Astronomy" library section are exactly right. I'll update this PR accordingly:

• Remove PeriSel from library.cc and ship it as a .48s library function using the structure you set up — no library.cc changes.

• Replace the 35-term truncation with the full Meeus ch.50: complete mean-perigee polynomial and all 60 Table 50.A terms, including the t-dependent coefficients. It matches PyMeeus to under 0.001 min over 1950–2100. New check points:

2457706.5 → 2457706.974818 (2016-Nov-14, k=224)
2464291.5 → 2464292.421948 (2034-Nov-25, k=463)

I've prepared a merged version — your table-driven matrix×array + explicit 50.A tables, with mode-independent 1_° sine arguments so no global angle-mode switch is needed. One detail to reconcile: the JDE-row T³ coefficient — PyMeeus uses +0.000001098, your matrix has −0.000001098; the impact is ≤0.2 s near 2100, but worth confirming against Meeus eq. 50.1 (in the book).

• Porb☽ stays: anomalistic month 2380713.11_s, with ±1.12 d (the measured 1σ spread of real perigee-to-perigee intervals — solar perturbation).

• T₀☽ currently evaluates JDN→(PeriSel(DateTime)), i.e. it reads the clock. Whether such a value belongs in constants.cc — or should only be reached through the PeriSel function — is a convention question I'd like @c3d to settle. The function already covers any epoch regardless.

• The doc (constants.md) will be updated to match (full-formula accuracy, library-function reference).

[evgaster]

mode-independent 1_° sine arguments so no global angle-mode switch is needed.

My approach has a slightly better performance. It was a late change to squeeze out a few ms.
But if you prefer to always convert to _° then here's a previous version that had that.
PeriSel.zip

One detail to reconcile: the JDE-row T³ coefficient — PyMeeus uses +0.000001098, your matrix has −0.000001098;

I used this copy of the book. It has a minus sign. Is the book wrong or is PyMeeus wrong?

[evgaster]

T₀☽ currently evaluates JDN→(PeriSel(DateTime)),

Beware that the current JDN implementation of DB48X has some issues (its off by 0.5). Doesn't bother PeriSel (most of the time).

#1580 will fix JDN ... if @c3d gets around to merging it.

[Wiljea]

Thanks @evgaster — I've reworked this along the lines you suggested.

Out of library.cc. PeriSel is now a single .48s function (library/PeriSel.48s) with a new "Astronomy" section in config/library.csv; src/library.cc is back to its dev state. It's now the full Meeus ch.50 Table 50.A (all 60 periodic terms, incl. the t‑dependent coefficients), merging your data‑driven matrix/array structure with the mode‑independent 1_° sine scaling (RAD/DEG/GRAD all agree, no global angle‑mode save/restore).

T³ sign — the book is right. I kept −0.000001098 (Meeus eq. 50.1, which is what your copy and your original matrix have). PyMeeus's +0.000001098 is the slip on their side. The difference is < 0.1 s anywhere in 1950–2100 (at most 2·0.000001098·T³ d), so it doesn't move any perigee instant — but −1.098e‑6 is the published value.

One deviation to flag: I replaced the ToProgram‑built per‑term mapper with a fixed‑program Map. A routine that assembles a program at run time with ToProgram stays symbolic when the function is called inside an algebraic — ⓁPeriSel(x) becomes 'PeriSel(x)' and ⒸT₀☽ →Num then errors Bad argument type, failing -Tcstlib. The fixed « FromList Drop → dD dM dF « … sin » » Map gives identical results and works both as RPL (x ⓁPeriSel) and inside an algebraic. Glad to revisit if you'd prefer another shape.

Input: accepts a Julian Day Number or a date (a _date value is converted via JDN; a plain real passes through).

Constants: Porb☽ = anomalistic month 2380713.11 s; T₀☽ = 'JDN→(ⓁPeriSel(→Num(JDN(DateTime))))' ± 300 s (~5 min, the ch.50 method accuracy vs the true perigee). On your point that T₀☽ depends on DateTime: I've left it in constants.cc for now but defer that to @c3d (same question as the planetary T₀ in #1700).

Validated on the simulator: 2457706.5 → 2457706.974818 (2016‑Nov‑14, k=224), 2464291.5 → 2464292.421948 (2034‑Nov‑25, k=463); -Tcstlib = 392 tests, 0 failures.

Known limitation (separate issue to follow): a date‑valued constant with a duration uncertainty (±300 s) can't yet render its value±uncertainty range (date + duration); normal recall of the date works, only the ±‑range recall errors. I'll file a separate "date ± duration range" issue rather than zero the uncertainty (see ISSUE #1705).

[Wiljea]

Thanks — good to know (about the 0.5 deviation), and I can reproduce it: 2451545.0 JDN→ gives 2000-01-01 00:00 instead of the J2000 noon, so JDN→ is treating integer JDN as midnight (off by 0.5). It shows up in T₀☽ as a 12 h shift in the time-of-day (e.g. the 2034-Nov-25 perigee renders ~10:07 instead of ~22:07).

PeriSel itself is unaffected — it takes a raw JDN (I validated it on literal JDNs, not JDN(date)), and rounding k to the nearest integer absorbs the ±0.5 day, so perigee selection is robust except within ~1 day of apogee. The DateTime↔JDN conversions in T₀☽ do inherit the offset, so I'll let #1580 fix it upstream rather than compensate here (a +0.5 patch would invert once #1580 lands). This is another reason the clock-dependent T₀☽-as-constant question is worth @c3d's call.