[jheriko]

this looks incredibly bad from the implementation. there is a much simpler algorithm that works for hundreds of years in either direction of the present...

by comparison this is an absolute mountain of code. here is a good one - but note that it is only so accurate for each quarter phase (...and not sure why it destroys the formatting):

function approximateMoonPhase(julianDay)

{

    // from Meeus p.319

    // JDE = 2451 550.09765 + 29.530 588 853 k

    // + 0.000 1337 T2

    // - 0.000 000 150 T3

    // + 0.000 000 000 73 T4

    const t = toJulianCenturiesSinceJ2000(julianDay);

    const lhs = julianDay - 2451550.09765 + (-0.0001337 + (0.00000015 - 0.00000000073 * t) * t) * t * t;

    return lhs / 29.530588853;

}

enjoy. its from the same source as your work appears to use...

which, as someone who as implemented a ton of this stuff. its kind of a damning sentiment that we still refer to such an old book instead of learning the problem space and making better solutions... i have a whole book in me about this at some point.

[zokier]

> but note that it is only so accurate for each quarter phase

So it's not actually comparable at all?

[jheriko]

thats a fair cop

tbh the small error can be very easily fixed. its close to the difference between a sine wave and its linear piecewise approximation from tip to tip, hence the very high accuracy on the quarters

you could go even further and remove the error from path being nearly a precessing ellipse...

in both cases what you will get is nothing that you would detect by eye or even with a telescope.

for the stated purpose this algorithm does fine in almost every use case including astronomical ones.

[jheriko]

i did a quick code review. this mountain of code has the same error and the same precision with identifying phases.

[saltcured]

Yeah these things are really piles of code and feature integration and can obscure the underlying logic somewhat.

1. Moon phase (or "age") is trivial to compute using modular arithmetic, given an absolute moment in time as an offset relative to a reference full moon time.

2. Converting datetime formats to a reference time can get complicated, particularly if you want to handle historical dates where calendar systems changed.

3. Converting phase into named bins is a pretty trivial lookup table to quantize the continuous phase value.

4. Converting phase into an approximate percent illumination is pretty trivial geometry, using a simplified model of the moon as a circle with an elliptical boundary for the shaded versus lit part.

5. Converting percent illumination into apparent brightness requires much more work to actually compute the positions of the sun, moon, and earthbound observer.

6. Finding moonrise and moonset times requires even more work to repeatedly find the positions and search for horizon crossings.

Edit: and computing practical brightness is even more complex as you need to fuse together the above with meteorological data to consider what light actually reaches the observer!

[Terretta]

> 0001337

Should I be suspicious of 'LEET code showing up in here?

https://en.wikipedia.org/wiki/Leet

[jheriko]

nice spot

[loufe]

You almost earned a downvote from me for the unnecessarily negative tone. You have a great post and the idea that there's a more elegant solution is awesome, but I'm puzzled why you chose to phrase your response that way.

To your point though, is this your solution? Is the accuracy helped by using more precise numbers or is it more of a structural limitation?

[jheriko]

downvote me. im tired of masses of bloat and excessive code