New version Swiss ephermeris code

[vreijs]

Hello Ralf.

Here is the code of 2.09.03: https://www.astro.com/ftp/swisseph/ and https://www.astro.com/ftp/swisseph/src/

There are two new functions to include in the R code: swe_houses_ex2() and swe_houses_armc_ex2(). We propose to remove the functions that provide lesser output: swe_houses_ex() and swe_houses_armc()

Let me know when you have time, as I need to replace these two old ones with new ones.

All the best and stay healthy.

Victor

---

Last comment on this version:

Hi,

this release has three minor bug fixes:

• An initialization *serr = '\0'; was missing in function swe_calc(), which could lead to crashes when error messages were written.

• Sidereal positions of asteroids were wrong with ayanamshas 9-16, 21-26, 37, 38, 41, 42. (Namely, all ayanamshas whose initial date is given in UT.)

• Asteroids with ipl > 10000 (SE_AST_OFFSET): calculating with several different ayanamshas after each other did not work properly.

The first bug was intoduced with version 2.09.01. The 2nd one exists since version 2.05, this is 5 years old. The 3rd one exists since more than 20 years. It seems that either sidereal astrologers rarely use asteroids or they rarely use the above-mentioned ayanamshas.

Best wishes,

Dieter

[rstub]

@vreijs Sorry for the delay. I see there is meanwhile version 2.10 available. I guess it makes more sense to use that, right?

[vreijs]

Hello Ralf,

Indeed best to take this newest version. I have gotten in the meantime a few 'new' computers and thus need to set up my environment again (and relearn it...).

On Sat, 1 May 2021 at 19:31, Ralf Stubner @.***> wrote:

@vreijs https://github.com/vreijs Sorry for the delay. I see there is meanwhile version 2.10 available. I guess it makes more sense to use that, right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-830666302, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFQ3PWK4P2H47YXCQJTTLQ3FXANCNFSM4RDCQV5A .

[rstub]

Let me know if you have any questions. BTW, with v2.10 I have the following failures in the tests:

══ Failed tests ════════════════════════════════════════════════════════════════
── Failure (test-misc.R:22:5): deltat can be retrieved ─────────────────────────
swe_deltat(1234.567) not equal to 1.58738640540236.
1/1 mismatches
[1] 1.6 - 1.59 == 0.0103
── Failure (test-misc.R:29:5): deltat can be retrieved for vector ──────────────
swe_deltat(c(1234.567, 1234567)) not equal to c(1.5873864, 0.366039979375346).
2/2 mismatches (average diff: 0.0064)
[1] 1.598 - 1.587 == 0.0103
[2] 0.369 - 0.366 == 0.0025
── Failure (test-misc.R:72:5): version works ───────────────────────────────────
swe_version() not equal to "2.08".
1/1 mismatches
x[1]: "2.10"
y[1]: "2.08"
── Failure (test-misc.R:86:3): Determing ayanamsa using UT: ────────────────────
result$daya not equal to 24.99688.
1/1 mismatches
[1] 25 - 25 == -0.000115
── Failure (test-misc.R:94:3): Determing ayanamsa using ET: ────────────────────
result$daya not equal to 24.99688.
1/1 mismatches
[1] 25 - 25 == -0.000115

The first two differences are probably due to a deltaT update, right? The version change is also expected. Any idea about the last two changes?

[vreijs]

Hello Ralf,

This are the changes in the version ( https://www.astro.com/swisseph/swisseph.htm#_Toc58931150):

2.08

13-jun-2019

update of Delta T and minor bug fixes

2.09

22-jul-2020

Improved Placidus houses, sidereal ephemerides, planetary magnitudes; minor bug fixes

2.10

10-dec-2020

NEW: planetary moons

So no mention of changes in DeltaT for 2.09 and 2.10 (or it are minor bugfixes). If ther eis a chnage in DeltaT formula: I would expect that in DeltaT and UT related calculations there is a difference. Why Determing ayanamsa using ET:is different, I would not expect that....

So perhaps worth asking Swiss Ephemeris. I will do that.

All the best,

Victor

On Mon, 3 May 2021 at 09:20, Ralf Stubner @.***> wrote:

Let me know if you have any questions. BTW, with v2.10 I have the following failures in the tests:

══ Failed tests ════════════════════════════════════════════════════════════════ ── Failure (test-misc.R:22:5): deltat can be retrieved ───────────────────────── swe_deltat(1234.567) not equal to 1.58738640540236. 1/1 mismatches [1] 1.6 - 1.59 == 0.0103 ── Failure (test-misc.R:29:5): deltat can be retrieved for vector ────────────── swe_deltat(c(1234.567, 1234567)) not equal to c(1.5873864, 0.366039979375346). 2/2 mismatches (average diff: 0.0064) [1] 1.598 - 1.587 == 0.0103 [2] 0.369 - 0.366 == 0.0025 ── Failure (test-misc.R:72:5): version works ─────────────────────────────────── swe_version() not equal to "2.08". 1/1 mismatches x[1]: "2.10" y[1]: "2.08" ── Failure (test-misc.R:86:3): Determing ayanamsa using UT: ──────────────────── result$daya not equal to 24.99688. 1/1 mismatches [1] 25 - 25 == -0.000115 ── Failure (test-misc.R:94:3): Determing ayanamsa using ET: ──────────────────── result$daya not equal to 24.99688. 1/1 mismatches [1] 25 - 25 == -0.000115

The first two differences are probably due to a deltaT update, right? The version change is also expected. Any idea about the last two changes?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-831074077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFVAZ3ZGNB3G4NC3O2DTLZFEJANCNFSM4RDCQV5A .

[rstub]

I meanwhile think what looked like deltaT was actually me testing without swephRdata. So probably no need to ask on the ML.

Now I only need a proper fix for some new compiler warnings ....

Victor Reijs @.***> schrieb am Mo. 3. Mai 2021 um 22:50:

Hello Ralf,

This are the changes in the version ( https://www.astro.com/swisseph/swisseph.htm#_Toc58931150):

2.08

13-jun-2019

update of Delta T and minor bug fixes

2.09

22-jul-2020

Improved Placidus houses, sidereal ephemerides, planetary magnitudes; minor bug fixes

2.10

10-dec-2020

NEW: planetary moons

So no mention of changes in DeltaT for 2.09 and 2.10 (or it are minor bugfixes). If ther eis a chnage in DeltaT formula: I would expect that in DeltaT and UT related calculations there is a difference. Why Determing ayanamsa using ET:is different, I would not expect that....

So perhaps worth asking Swiss Ephemeris. I will do that.

All the best,

Victor

On Mon, 3 May 2021 at 09:20, Ralf Stubner @.***> wrote:

Let me know if you have any questions. BTW, with v2.10 I have the following failures in the tests:

══ Failed tests ════════════════════════════════════════════════════════════════ ── Failure (test-misc.R:22:5): deltat can be retrieved ───────────────────────── swe_deltat(1234.567) not equal to 1.58738640540236. 1/1 mismatches [1] 1.6 - 1.59 == 0.0103 ── Failure (test-misc.R:29:5): deltat can be retrieved for vector ────────────── swe_deltat(c(1234.567, 1234567)) not equal to c(1.5873864, 0.366039979375346). 2/2 mismatches (average diff: 0.0064) [1] 1.598 - 1.587 == 0.0103 [2] 0.369 - 0.366 == 0.0025 ── Failure (test-misc.R:72:5): version works ─────────────────────────────────── swe_version() not equal to "2.08". 1/1 mismatches x[1]: "2.10" y[1]: "2.08" ── Failure (test-misc.R:86:3): Determing ayanamsa using UT: ──────────────────── result$daya not equal to 24.99688. 1/1 mismatches [1] 25 - 25 == -0.000115 ── Failure (test-misc.R:94:3): Determing ayanamsa using ET: ──────────────────── result$daya not equal to 24.99688. 1/1 mismatches [1] 25 - 25 == -0.000115

The first two differences are probably due to a deltaT update, right? The version change is also expected. Any idea about the last two changes?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-831074077, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AEDLUFVAZ3ZGNB3G4NC3O2DTLZFEJANCNFSM4RDCQV5A>

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-831525292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGUIIS64B66D63SSOM5WWB3TL4EBVANCNFSM4RDCQV5A .

[vreijs]

Did you already check if that indeed helped? I would have thought that DeltaT for such remote days would not depend on swephRdat. (DeltaT is a simple formula, which changes due to new historic analysis of eclipses...).

Let me know if I need to retract my question to the SwiSS Ephemeris list.

All the best,

Victor

On Mon, 3 May 2021 at 22:54, Ralf Stubner @.***> wrote:

I meanwhile think what looked like deltaT was actually me testing without swephRdata. So probably no need to ask on the ML.

Now I only need a proper fix for some new compiler warnings ....

Victor Reijs @.***> schrieb am Mo. 3. Mai 2021 um 22:50:

Hello Ralf,

This are the changes in the version ( https://www.astro.com/swisseph/swisseph.htm#_Toc58931150):

2.08

13-jun-2019

update of Delta T and minor bug fixes

2.09

22-jul-2020

Improved Placidus houses, sidereal ephemerides, planetary magnitudes; minor bug fixes

2.10

10-dec-2020

NEW: planetary moons

So no mention of changes in DeltaT for 2.09 and 2.10 (or it are minor bugfixes). If ther eis a chnage in DeltaT formula: I would expect that in DeltaT and UT related calculations there is a difference. Why Determing ayanamsa using ET:is different, I would not expect that....

So perhaps worth asking Swiss Ephemeris. I will do that.

All the best,

Victor

On Mon, 3 May 2021 at 09:20, Ralf Stubner @.***> wrote:

Let me know if you have any questions. BTW, with v2.10 I have the following failures in the tests:

══ Failed tests ════════════════════════════════════════════════════════════════ ── Failure (test-misc.R:22:5): deltat can be retrieved ───────────────────────── swe_deltat(1234.567) not equal to 1.58738640540236. 1/1 mismatches [1] 1.6 - 1.59 == 0.0103 ── Failure (test-misc.R:29:5): deltat can be retrieved for vector ────────────── swe_deltat(c(1234.567, 1234567)) not equal to c(1.5873864, 0.366039979375346). 2/2 mismatches (average diff: 0.0064) [1] 1.598 - 1.587 == 0.0103 [2] 0.369 - 0.366 == 0.0025 ── Failure (test-misc.R:72:5): version works ─────────────────────────────────── swe_version() not equal to "2.08". 1/1 mismatches x[1]: "2.10" y[1]: "2.08" ── Failure (test-misc.R:86:3): Determing ayanamsa using UT: ──────────────────── result$daya not equal to 24.99688. 1/1 mismatches [1] 25 - 25 == -0.000115 ── Failure (test-misc.R:94:3): Determing ayanamsa using ET: ──────────────────── result$daya not equal to 24.99688. 1/1 mismatches [1] 25 - 25 == -0.000115

The first two differences are probably due to a deltaT update, right? The version change is also expected. Any idea about the last two changes?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-831074077, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AEDLUFVAZ3ZGNB3G4NC3O2DTLZFEJANCNFSM4RDCQV5A

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-831525292, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AGUIIS64B66D63SSOM5WWB3TL4EBVANCNFSM4RDCQV5A

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-831527412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFT6CQRAENUFM6HPRT3TL4EQDANCNFSM4RDCQV5A .

[vreijs]

On Mon, 3 May 2021 at 22:54, Ralf Stubner @.***> wrote:

Now I only need a proper fix for some new compiler warnings ....

Should we also feed them back to Swiss Ephemeris, perhaps it are errors that could be removed by the authors in the future?

All the best,

Victor

[rstub]

I am not 100% sure, but the changes I introduced bring the deltaT tests without swephRdata in line with those with swephRdata installed: https://github.com/rstub/swephR/pull/60/commits/d7adf32da29f8b705c0f33344daa733a1db71b1f So I would like to do some more tests with this to make sure whether this comes from using version 2.10 or swephRdata being (not) present.

As for the compiler warnings:

     libswe/sweph.c:2306:37: warning: ‘%s’ directive writing up to 255 bytes into a region of size 240 [-Wformat-overflow=]
     libswe/sweph.c:2304:40: warning: ‘%s’ directive writing up to 255 bytes into a region of size 237 [-Wformat-overflow=]
     libswe/sweph.c:2302:41: warning: ‘%s’ directive writing up to 255 bytes into a region of size 236 [-Wformat-overflow=]
     libswe/sweph.c:2300:35: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 234 and 235 [-Wformat-overflow=]
     libswe/sweph.c:2298:34: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 235 and 236 [-Wformat-overflow=]
     libswe/sweph.c:2295:38: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 231 and 240 [-Wformat-overflow=]

Yes, it would be helpful to get input from the SE developers. These come from a portion of the code ( https://github.com/rstub/swephR/blob/feature/v2.10/external/src/sweph.c#L2295-L2306) where a new string s is created based on a format and another string sp. Unfortunately, both s and sp have the same max length and could therefor lead to an overflow. I had tried to use snprintf instead of sprintf, but this gives a "truncation" warning. In my current PR, I try to forcefully truncate sp (cf https://github.com/rstub/swephR/pull/60/commits/a646c982ea6ab83d5b8f2fcb8b68ca850e94a38b) which works locally but not in the (new) CI (https://github.com/rstub/swephR/pull/60/checks?check_run_id=2494991210). One alternative would be to replace %s with something like %.200s, which again does work locally. I have not tried this on CI.

[vreijs]

On Tue, 4 May 2021 at 09:59, Ralf Stubner @.***> wrote:

I am not 100% sure, but the changes I introduced bring the deltaT tests without swephRdata in line with those with swephRdata installed: d7adf32 https://github.com/rstub/swephR/commit/d7adf32da29f8b705c0f33344daa733a1db71b1f So I would like to do some more tests with this to make sure whether this comes from using version 2.10 or swephRdata being (not) present.

We provide in R both swe_deltat and swe_deltat_ex (the last one is the recommended one)? I use in my excel swe_deltat_ex and for both 2.08 and 2.10 I get the same results at Dieter (of SE). I am using the internal ephemeris (no data files). Does the swe_deltat_ex provide errors when testing? Perhaps we should remove swe_deltat?

[rstub]

I do a difference with v2.08 depending on whether swephRdata is installed or not. I don't see such a difference for v2.10.

v2.08 w/o swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R1 R -q -f  swe-test.R 
> library(swephR)
> swe_version()
[1] "2.08"
> requireNamespace("swephRdata")
Loading required namespace: swephRdata
Failed with error:  ‘there is no package called ‘swephRdata’’
> swe_deltat(c(1234.567, 1234567))
[1] 1.587386 0.366040

v2.08 w/ swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R2 R -q -f  swe-test.R 
> library(swephR)
> swe_version()
[1] "2.08"
> requireNamespace("swephRdata")
> swe_deltat(c(1234.567, 1234567))
[1] 1.5976757 0.3685434

v2.10 w/o swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R3 R -q -f  swe-test.R 
> library(swephR)
> swe_version()
[1] "2.10"
> requireNamespace("swephRdata")
Loading required namespace: swephRdata
Failed with error:  ‘there is no package called ‘swephRdata’’
> swe_deltat(c(1234.567, 1234567))
[1] 1.5976757 0.3685434

v2.10 w/o swephRdata

ralf@barra:~/tmp$ R -q -f  swe-test.R 
> library(swephR)
> swe_version()
[1] "2.10"
> requireNamespace("swephRdata")
> swe_deltat(c(1234.567, 1234567))
[1] 1.5976757 0.3685434

What would be the expected behavior here?

BTW, thanks for forwarding the suggestion from the SE developers, which does indeed work, cf https://github.com/rstub/swephR/pull/60/checks?check_run_id=2502228436

[vreijs]

Hello Ralf,

What if you look at swe_deltat_ex's output? That is a better function (I only use that in my Excel by the way and it gives the same results for 2.08 and 2.10)?

I will build up my R environment and get to learn it again. So that I can better assist!

What changes do the SE developers need to include in their code, so that in the future it will work? Are they all in: https://github.com/rstub/swephR/commit/ea6546eb004ff448cfac4951a9b3790222e884a0

All the best,

Victor

On Tue, 4 May 2021 at 21:56, Ralf Stubner @.***> wrote:

I do a difference with v2.08 depending on whether swephRdata is installed or not. I don't see such a difference for v2.10.

v2.08 w/o swephRdata

@.***:~/tmp$ R_LIBS_USER=~/tmp/R1 R -q -f swe-test.R

library(swephR)

swe_version()

[1] "2.08"

requireNamespace("swephRdata")

Loading required namespace: swephRdata

Failed with error: ‘there is no package called ‘swephRdata’’

swe_deltat(c(1234.567, 1234567))

[1] 1.587386 0.366040

v2.08 w/ swephRdata

@.***:~/tmp$ R_LIBS_USER=~/tmp/R2 R -q -f swe-test.R

library(swephR)

swe_version()

[1] "2.08"

requireNamespace("swephRdata")

swe_deltat(c(1234.567, 1234567))

[1] 1.5976757 0.3685434

v2.10 w/o swephRdata

@.***:~/tmp$ R_LIBS_USER=~/tmp/R3 R -q -f swe-test.R

library(swephR)

swe_version()

[1] "2.10"

requireNamespace("swephRdata")

Loading required namespace: swephRdata

Failed with error: ‘there is no package called ‘swephRdata’’

swe_deltat(c(1234.567, 1234567))

[1] 1.5976757 0.3685434

v2.10 w/o swephRdata

@.***:~/tmp$ R -q -f swe-test.R

library(swephR)

swe_version()

[1] "2.10"

requireNamespace("swephRdata")

swe_deltat(c(1234.567, 1234567))

[1] 1.5976757 0.3685434

What would be the expected behavior here?

BTW, thanks for forwarding the suggestion from the SE developers, which does indeed work, cf https://github.com/rstub/swephR/pull/60/checks?check_run_id=2502228436

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-832203522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFST65ZL2CO42TBMSQDTMBGN5ANCNFSM4RDCQV5A .

[rstub]

Using swe_deltat_ex in the four different environments one can learn more about what is going on.

v2.08 w/o swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R1 R -q -f  swe-test2.R 
> library(swephR)
> swe_version()
[1] "2.08"
> requireNamespace("swephRdata")
Loading required namespace: swephRdata
Failed with error:  ‘there is no package called ‘swephRdata’’
> swe_deltat_ex(c(1234.567, 1234567), 2)
$deltat
[1] 1.587386 0.366040

$serr
[1] "SwissEph file 'seplm48.se1' not found in PATH '/usr/local/lib/R/site-library/swephR/ephemeris/'"                       
[2] "SwissEph file 'seplm18.se1' not found in PATH '/usr/local/lib/R/site-library/swephR/ephemeris/' \nusing Moshier eph.; "

> swe_deltat_ex(c(1234.567, 1234567), 4)
$deltat
[1] 1.587386 0.366040

$serr
[1] "" ""

v2.08 w/ swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R2 R -q -f  swe-test2.R 
> library(swephR)
> swe_version()
[1] "2.08"
> requireNamespace("swephRdata")
> swe_deltat_ex(c(1234.567, 1234567), 2)
$deltat
[1] 1.5976757 0.3685434

$serr
[1] "" ""

> swe_deltat_ex(c(1234.567, 1234567), 4)
$deltat
[1] 1.587386 0.366040

$serr
[1] "" ""

v2.10 w/o swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R3 R -q -f  swe-test2.R 
> library(swephR)
> swe_version()
[1] "2.10"
> requireNamespace("swephRdata")
Loading required namespace: swephRdata
Failed with error:  ‘there is no package called ‘swephRdata’’
> swe_deltat_ex(c(1234.567, 1234567), 2)
$deltat
[1] 1.5976757 0.3685434

$serr
[1] "" ""

> swe_deltat_ex(c(1234.567, 1234567), 4)
$deltat
[1] 1.587386 0.366040

$serr
[1] "" ""

v2.10 w/ swephRdata

ralf@barra:~/tmp$ R -q -f  swe-test2.R 
> library(swephR)
> swe_version()
[1] "2.10"
> requireNamespace("swephRdata")
> swe_deltat_ex(c(1234.567, 1234567), 2)
$deltat
[1] 1.5976757 0.3685434

$serr
[1] "" ""

> swe_deltat_ex(c(1234.567, 1234567), 4)
$deltat
[1] 1.587386 0.366040

$serr
[1] "" ""

So it seems like v2.10 no longer needs the SE data files for making deltaT computations using SE instead of Moshier. Is that expected? Or am I misinterpreting things here?

ea6546e also contains the removal of my previous attempt at fixing the new issue. The best reference are allways the files in external/patch, in this case https://github.com/rstub/swephR/blob/ea6546eb004ff448cfac4951a9b3790222e884a0/external/patch/19_increase_buffer.diff.

BTW, thanks for telling me about v2.10.1. I will integrate this into this branch. Can you compile a list of changes since v2.08? I would like to add that to NEWS.md.

[rstub]

BTW, v2.10.1 brings in quite some changes, given that it is "only" a patch release:

• two source files are no longer used (swepcalc.c and swepdate.c)
• all other sources are now covered by AGPL and no longer GPL, even though LICENSE still refers to GPL

THe second point is no big issue for us, since swephR has always been covered by AGPL. But might be confusing for other users of the source code. Have the SE authors mentioned this change in any way?

[rstub]

Yet another BTW, the patch 19_increase_buffer.diff is part of version 2.10.01.

[vreijs]

Hallo Ralf, There was some small feedback not not negative. The reasoning is here (of Alois): On Wed, Apr 21, 2021 at 1:17 PM Alois Treindl @.***> wrote:

We intend to change the licensing policy for Swiss Ephemeris from GPL 2.0 to AFGPLv3, starting from the next release, 2.10.1 and later.

See https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License for a description.

The change is intended to close a loophole in the GPL license.

The old license allows a Swiss Ephemeris user to use our software, modify it at will and run it on a server.

As long as he does not distribute his software (passes it on to others) he is not obliged to make the source code and his modifications available to anyone, including the authors of the software.

Under AFGPL such a user must make his software source code available for download also to users of his server. That way, something is returned to the community. Others may profit from his work, just as he profits from our work, for free.

With the dual licensing model of Swiss Ephemeris such a service provider has still the option to purchase the professional license, which frees him from the obligation to make his source code available.

Relating to: swepcalc.c and swepdate.c: Were they removed in 2.10.1? Or are they simply not used anymore? In that last case: should I mention to the SE authors that they should remove these two functions?

So I understand the that size issue of s has been included in 2.10.1, correct? Great.

On Thu, 13 May 2021 at 17:36, Ralf Stubner @.***> wrote:

BTW, v2.10.1 brings in quite some changes, given that it is "only" a patch release:

• two source files are no longer used (swepcalc.c and swepdate.c)
• all other sources are now covered by AGPL and no longer GPL, even though LICENSE still refers to GPL

THe second point is no big issue for us, since swephR has always been covered by AGPL. But might be confusing for other users of the source code. Have the SE authors mentioned this change in any way?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-840643646, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFVV43T736IKAU2VMB3TNPWWNANCNFSM4RDCQV5A .

[vreijs]

Hello Ralf,

The changes from 2.08 to 2.10.1 can be seen here: https://www.astro.com/swisseph/swephprg.htm#_Toc71121304

I know that swe_ deltat does not handle the different ephemerises correctly, that is why they introduce swe_delta_ex. So in some way swe_deltat is buggy (and not recommended to be used anymore). BUT what I find strange is that even in 2.10 the deltaT changed when using a different ephemeris. I would have thought it would stay the same...

II will query this with the SE authors.

On Thu, 13 May 2021 at 08:16, Ralf Stubner @.***> wrote:

Using swe_deltat_ex in the four different environments one can learn more about what is going on.

v2.08 w/o swephRdata

@.***:~/tmp$ R_LIBS_USER=~/tmp/R1 R -q -f swe-test2.R

library(swephR)

swe_version()

[1] "2.08"

requireNamespace("swephRdata")

Loading required namespace: swephRdata

Failed with error: ‘there is no package called ‘swephRdata’’

swe_deltat_ex(c(1234.567, 1234567), 2)

$deltat

[1] 1.587386 0.366040

$serr

[1] "SwissEph file 'seplm48.se1' not found in PATH '/usr/local/lib/R/site-library/swephR/ephemeris/'"

[2] "SwissEph file 'seplm18.se1' not found in PATH '/usr/local/lib/R/site-library/swephR/ephemeris/' \nusing Moshier eph.; "

swe_deltat_ex(c(1234.567, 1234567), 4)

$deltat

[1] 1.587386 0.366040

$serr

[1] "" ""

v2.08 w/ swephRdata

@.***:~/tmp$ R_LIBS_USER=~/tmp/R2 R -q -f swe-test2.R

library(swephR)

swe_version()

[1] "2.08"

requireNamespace("swephRdata")

swe_deltat_ex(c(1234.567, 1234567), 2)

$deltat

[1] 1.5976757 0.3685434

$serr

[1] "" ""

swe_deltat_ex(c(1234.567, 1234567), 4)

$deltat

[1] 1.587386 0.366040

$serr

[1] "" ""

v2.10 w/o swephRdata

@.***:~/tmp$ R_LIBS_USER=~/tmp/R3 R -q -f swe-test2.R

library(swephR)

swe_version()

[1] "2.10"

requireNamespace("swephRdata")

Loading required namespace: swephRdata

Failed with error: ‘there is no package called ‘swephRdata’’

swe_deltat_ex(c(1234.567, 1234567), 2)

$deltat

[1] 1.5976757 0.3685434

$serr

[1] "" ""

swe_deltat_ex(c(1234.567, 1234567), 4)

$deltat

[1] 1.587386 0.366040

$serr

[1] "" ""

v2.10 w/ swephRdata

@.***:~/tmp$ R -q -f swe-test2.R

library(swephR)

swe_version()

[1] "2.10"

requireNamespace("swephRdata")

swe_deltat_ex(c(1234.567, 1234567), 2)

$deltat

[1] 1.5976757 0.3685434

$serr

[1] "" ""

swe_deltat_ex(c(1234.567, 1234567), 4)

$deltat

[1] 1.587386 0.366040

$serr

[1] "" ""

So it seems like v2.10 no longer needs the SE data files for making deltaT computations using SE instead of Moshier. Is that expected? Or am I misinterpreting things here?

ea6546e https://github.com/rstub/swephR/commit/ea6546eb004ff448cfac4951a9b3790222e884a0 also contains the removal of my previous attempt at fixing the new issue. The best reference are allways the files in external/patch, in this case https://github.com/rstub/swephR/blob/ea6546eb004ff448cfac4951a9b3790222e884a0/external/patch/19_increase_buffer.diff .

BTW, thanks for telling me about v2.10.1. I will integrate this into this branch. Can you compile a list of changes since v2.08? I would like to add that to NEWS.md.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-840334632, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFS2T5BY5SSZC4QWFPTTNNVCDANCNFSM4RDCQV5A .

[rstub]

Hi Victor,

Concerning AGPL: Excellent! You could ask the SE authors to also update the LICENSE file in their distribution. For us this means we can get rid of the LICENSE file and just say "AGPL" in DESCRIPTION.

Concerning the two no longer used files: They are still part of the distribution (and are therefore still in external/src), but they are no longer needed for building the library. That's why I have deleted them from src/libswe. I see no need for the SE authors to take action, since there are other files in the distribution that are not needed to build the library.

I am curious to see what comes out of the deltaT discussion.

[vreijs]

Hello Ralf,

Can you tell which precise file it is? Dieter of SE is asking.

All the best,

Victor

On Thu, 13 May 2021 at 20:14, Ralf Stubner @.***> wrote:

Hi Victor,

Concerning AGPL: Excellent! You could ask the SE authors to also update the LICENSE file in their distribution. For us this means we can get rid of the LICENSE file and just say "AGPL" in DESCRIPTION.

Concerning the two no longer used files: They are still part of the distribution (and are therefore still in external/src), but they are no longer needed for building the library. That's why I have deleted them from src/libswe. I see no need for the SE authors to take action, since there are other files in the distribution that are not needed to build the library.

I am curious to see what comes out of the deltaT discussion.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/59#issuecomment-840739049, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFRWD7NNFN4S7BX4L6LTNQJJ3ANCNFSM4RDCQV5A .

[rstub]

I am refering to the src/LICENSE file in the source distribution:

[ralf@barra: ~/devel/swephR/external] [feature/v2.10 ↑·1|…6⚑ 2] ✔
08:31 $ tar xfO swe_unix_src_2.10.01.tar.gz src/LICENSE | head -n 20
/* Copyright (C) 1997 - 2008 Astrodienst AG, Switzerland.  All rights reserved.

  License conditions
  ------------------

  This file is part of Swiss Ephemeris.

  Swiss Ephemeris is distributed with NO WARRANTY OF ANY KIND.  No author
  or distributor accepts any responsibility for the consequences of using it,
  or for whether it serves any particular purpose or works at all, unless he
  or she says so in writing.  

  Swiss Ephemeris is made available by its authors under a dual licensing
  system. The software developer, who uses any part of Swiss Ephemeris
  in his or her software, must choose between one of the two license models,
  which are
  a) GNU public license version 2 or later
  b) Swiss Ephemeris Professional License

  The choice must be made before the software developer distributes software