From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ulrich =?UTF-8?Q?M=C3=BCller?= Newsgroups: gmane.emacs.bugs Subject: bug#61460: 30.0.50; Calendar shows eclipse for quarter moon Date: Thu, 16 Feb 2023 21:26:24 +0100 Message-ID: References: <87sffab61y.fsf@web.de> <87cz6eb10y.fsf@web.de> <87r0uu9e5v.fsf@web.de> <87mt5i9cba.fsf@web.de> <875yc4q0ee.fsf@web.de> <87y1p0obe8.fsf@web.de> <87ttzoo6px.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16200"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cc: Eli Zaretskii , 61460@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 16 21:27:19 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pSkqc-00046M-FY for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Feb 2023 21:27:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSkqP-00024L-1C; Thu, 16 Feb 2023 15:27:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSkqN-000249-La for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 15:27:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pSkqM-0005U2-4O for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 15:27:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pSkqM-0006WM-0f for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 15:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ulrich =?UTF-8?Q?M=C3=BCller?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2023 20:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61460 X-GNU-PR-Package: emacs Original-Received: via spool by 61460-submit@debbugs.gnu.org id=B61460.167657919925036 (code B ref 61460); Thu, 16 Feb 2023 20:27:01 +0000 Original-Received: (at 61460) by debbugs.gnu.org; 16 Feb 2023 20:26:39 +0000 Original-Received: from localhost ([127.0.0.1]:37742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSkpz-0006Vj-DK for submit@debbugs.gnu.org; Thu, 16 Feb 2023 15:26:39 -0500 Original-Received: from woodpecker.gentoo.org ([140.211.166.183]:38100 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSkpx-0006VT-DM for 61460@debbugs.gnu.org; Thu, 16 Feb 2023 15:26:38 -0500 In-Reply-To: <87ttzoo6px.fsf@web.de> (Michael Heerdegen's message of "Tue, 14 Feb 2023 11:56:58 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:255836 Archived-At: >>>>> On Tue, 14 Feb 2023, Michael Heerdegen wrote: >> Next round: The following simplifies the calculation and IMHO makes >> it much easier to understand. Results are identical, and tests pass. > Yes, thanks. I want to suggest to get rid of the successive rebinding > to the variable `moon-lat' and use a different name (`node-distance' > maybe?) since that calculation is not just a simple conversion of units. >> Alternatively, we could leave the result in degrees (as all other >> calculations in lunar.el are in degrees) and change the values in the >> final cond to 13.9 and 21.2 degrees. This would also get rid of the >> excessive number of digits. > Good idea. The conversion to radians is a bit artificial and not really > useful, just harder to read. Pushed to master, including your suggestion (I went for "node-dist"). I think the last open question is what values we should use as limits for "certain" and "possible" eclipses? A calculation of these limits can be found here (complete text on Google Books): William Chauvenet, "A manual of spherical and practical astronomy", Vol. I, Lippincott & Co., London, 1863. On page 439: "a solar eclipse is certain if at new moon =CE=B2 < 1=C2=B023'= 15", impossible if =CE=B2 > 1=C2=B034'53", and doubtful between these limits." And on page 543: "a lunar eclipse is certain if at full moon =CE=B2 < 52'4", impossible if =CE=B2 > 63'53", and doubtful between these limits." These limits are given in terms of ecliptic latitude =CE=B2, which can be converted to the argument of latitude u using the same spherical triangle as above (in message #68): sin =CE=94u =3D sin =CE=B2 / sin i Using the minimum and maximum values of the lunar orbit's inclination i_min =3D 4=C2=B057'2" and i_max =3D 5=C2=B020'6" (see table on page 438), = I get the following limits for =CE=94u: Solar eclipse certain: =CE=94u < 15.10=C2=B0 Solar eclipse possible: =CE=94u < 18.65=C2=B0 Lunar eclipse certain: =CE=94u < 9.37=C2=B0 Solar eclipse possible: =CE=94u < 12.43=C2=B0 (These are close to the values given by Peter Duffet-Smith, "Practical astronomy with your calculator", 3rd ed., Cambridge University Press, 1991, page 156: Solar eclipse certain: 15=C2=B031', possible: 18=C2=B031'; = lunar eclipse certain: 9=C2=B030', possible: 12=C2=B015'.) However, if I put these limits into the comparisons in eclipse-check, then it misses the partial lunar eclipse on 2023-10-28 (I haven't checked any others, but if it is wrong in this year, then it is probably wrong in more cases). I suspect that the calculations in lunar-phase are not precise enough. Also, I believe that I have found the source of the current limits: Jean Meeus, "Astronomical algorithms", 1st ed., Willmann-Bell, Richmond, VA, 1991. This happens to be one of the references mentioned in the header of lunar.el, therefore the limits are likely to be consistent with the precision of the other calculations. On page 350 it says: "If F [the argument of latitude] differs from the nearest multiple of 180=C2=B0 by less than 13=C2=B0.9, then there is certai= nly an eclipse; if the difference is larger than 21=C2=B0.0, there is no eclipse; between these two values, the eclipse is uncertain at this stage and the case must be examined further." tl;dr I suggest that we leave the values as-is, except for a small adjustment from 21.2 to 21.0, as in the patch included below. If there aren't any nobjections, I'm going to push this to master. @Michael: Can this bug be closed then? >From 431c60084dade55acd0d407fff1cdfb2352a3d91 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Ulrich=3D20M=3DC3=3DBCller?=3D Date: Thu, 16 Feb 2023 20:09:22 +0100 Subject: [PATCH] ; * lisp/calendar/lunar.el (eclipse-check): Adjust upper limit. --- lisp/calendar/lunar.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/calendar/lunar.el b/lisp/calendar/lunar.el index 1f827ca34b0..8fb5c89c057 100644 --- a/lisp/calendar/lunar.el +++ b/lisp/calendar/lunar.el @@ -164,8 +164,9 @@ remainder mod 4 gives the phase: 0 new moon, 1 first qu= arter, 2 full moon, (t "")))) (cond ((string=3D phase-name "") "") + ;; Limits 13.9=C2=B0 and 21.0=C2=B0 from Meeus (1991), page 350. ((< node-dist 13.9) (concat "** " phase-name " Eclipse **")) - ((< node-dist 21.2) (concat "** " phase-name " Eclipse possible **")) + ((< node-dist 21.0) (concat "** " phase-name " Eclipse possible **")) (t "")))) =20 (defconst lunar-cycles-per-year 12.3685 ; 365.25/29.530588853 --=20 2.39.2