NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
From: Frank Reed
Date: 2023 Apr 30, 13:26 -0700
Modris,
Thank you for bringing this up!
Back in November I noticed some occasional "weird" output from my lunars web app. There were differences on the order of 0.1 to 0.2', just as you found. This is a small difference, but it's at the margin for lunars where it should be fixed. I added this to my long list of things to look at and spent some time on it in December. But it was problematic because, as it turns out, the bug is intermittent. And intermittent bugs are the worst! Your example got me looking at it again, and this time I figured it out in just an hour. I'm about to fix it. What's interesting here is that it's not a problem with the astronomical computations --not directly. It doesn't have anything to with ephemeris data or parallax or refraction computations or spherical trigonometry solutions or anything astronomical at all. It's an interface issue that crept in sometime last year.
Without changing a thing in code, I am able to generate alternate output for your Venus case that is a near match for the other solutions. I'm posting this side-by-side comparison as a little puzzle for any of you interested in this issue. What did I change here?? It looks like it's all the same, but the "correct" lunar distance here is changed by 0.2'. It's re-assuring that the underlying "lunars" engine in my code is working fine. It's not an "astronomy problem". But from an end user's perspective, a bug is a bug even if it is intermittent! I'm going to leave it "broken" for 24 hours in case any of you want to puzzle out the change that I made to produce this distinct output. And I emphasize: it's not a coding change. It's in the way I have used the app ...an interface issue. Can you reproduce my second screen here?
Frank Reed
Clockwork Mapping / ReedNavigation.com
Conanicut Island USA
