This is really nice. My initial thought was "why just divide the time interval since the Unix Epoch by the synodic period of the moon". Turns out the moon's phase is a bit more complicated than that. https://en.wikipedia.org/wiki/Lunar_phase#Calculating_phase
`pom(6)` from `bsdgames` might already be installed on your system to do this. Source comments indicate it was originally based on prior versions of the same book but updated to the Third Edition in 1998.
For "implement simple task in many languages" you should probably think of Rosetta Code, now at https://rosettacode.miraheze.org/wiki/Rosetta_Code
This code consistently converts angles to the [0, 360) range, which is IMO overkill. A better approach is to normalize everything to [0, 2) range so that you can simply multiply or divide by pi to get the radians. If your math library has `sinpi` or `cospi` it will be even more accurate, as it no longer has to divide by 2pi to do the actual calculation.
I adapted the same moonphase logic for the status line program I use with dwm. Did you run into any discrepancies with using January 0 vs December 31st? Some of the translations of Walker's as noted in my comment at https://github.com/ericpruitt/emus/blob/ea059239845ee6d57614... seem to produce differing results.
made a PR for raku, hope it gets accepted
some cool things stood out:
sub fixangle($a) { $a mod 360 } # raku has built-in support for Euclidean modulo
pi # raku has pi
# Solve equation of Kepler
my $e = $M;
my $delta;
repeat { # raku's repeat loop allows initialisation of delta to be folded in
$delta = $e - $eccent * sin($e) - $M;
$e -= $delta / (1 - $eccent * cos($e));
} while abs($delta) > 1e-6;LCAL[0]: The Moon Phase Calendar Program
A PostScript program to visualize a calendar of moon phases (skip down to "LCAL PostScript Calendar Examples" for just that). Did some nice PS prints recently for the next 10 years, adapted to fit in a frame I had laying around.
AWK can be far more than a DSL.
Fun! From the repo[0]:
> Your function must be self-contained, such that someone could copy-paste it into their code and not get an error. It also must not effect the environment outside it if at all possible (no #define or mutating globals). It must be as "pure" and self-contained as the language will allow.
This is an interesting restriction, actually, with respect to style. The “natural” way I would program such an algorithm certainly doesn’t adhere to this requirement.
Producing functions that are still correct, idiomatic and legible while producing minimal changes to environment or state requires a non-beginners understanding of the runtime nature of the language.
[0]: https://github.com/oliverkwebb/moonphase?tab=readme-ov-file#...