Live data from Hacker News

Show HN: Tiny Moon – Swift library to calculate the moon phase

github.com

31–40 of 41 posts

Re: Show HN: Tiny Moon – Swift library to calculate the moon phase

#31
post #27

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.…

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?

Re: Show HN: Tiny Moon – Swift library to calculate the moon phase

#32

If granular accuracy is not an important factor, you can also use Islamic calendar to calculate the moon phase. Muslims uses lunar cycles for some religious events (e.g. the Ayyamul Bidh or 3 days fasting during full moon). So when its 15 of an Islamic calendar, it’ll be a full moon. I used this approach because most platforms supports islamic calendar. I really like the offline first approach, and would definitely u…

I wonder, how is Allah's tolerance towards technotheological errors? What if there's a bug in the calendar for Ramadan or Salah?

In Islam, err is forgiven. If you’ve done your best and there’s a bug you missed, then its forgiven, and when you discover it, just fix it.

That’s why if a scholar based with intensive research and data, has concluded that X is true. If in the end its really true, they’ll receive two rewards; when its debunked and it was actually false, they receive one reward. The sin is to be ignorant and without any research and data concluded that X is true.

Specifically for Ramadan, the guideline is to use Moon sighting. If you see a new moon, then you begin fasting. If not, then you postpone for a day before starting Ramadan. Usually there’s a committee that does this and they will announce the result. But it doesn’t prevent anyone with the ability to observe to decide when to start Ramadan.

Salah guideline is the sun, e.g the dawn prayer is when there’s thin strike of the sun on the horizon. So to calculate the prayer time you use the sun position relative to your position on earth. If there’s a bug that somehow err the prayer time to ~5 minutes. We can always observe the sun first.

So there’s always this second factor that you can use to validate the first method. Time seems off? Look at the sun. Sun not visible? Estimate with time. Both seems off? Estimate with the variables that you can observe.

“ God does not burden any soul with more than it can bear “ (Al Baqarah 286)

——- So to answer the question, the tolerance depends on your effort on trying to reduce the err.

God knows best

Re: Show HN: Tiny Moon – Swift library to calculate the moon phase

#33
post #27

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.…

> 0001337

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

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

Re: Show HN: Tiny Moon – Swift library to calculate the moon phase

#36
post #27

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.…

> 0001337 Should I be suspicious of 'LEET code showing up in here? https://en.wikipedia.org/wiki/Leet

nice spot

Re: Show HN: Tiny Moon – Swift library to calculate the moon phase

#37
post #31
post #27

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.…

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?

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

Re: Show HN: Tiny Moon – Swift library to calculate the moon phase

#38
post #30
post #27

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.…

> but note that it is only so accurate for each quarter phase So it's not actually comparable at all?

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.

Re: Show HN: Tiny Moon – Swift library to calculate the moon phase

#39
post #30
post #27

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.…

> but note that it is only so accurate for each quarter phase So it's not actually comparable at all?

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

Re: Show HN: Tiny Moon – Swift library to calculate the moon phase

#40
post #27

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.…

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!

Post reply on HN