Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix axes with equal sign houses #138

Conversation

fkostadinov
Copy link
Contributor

This fix added explicit calculation of Asc/Dsc and MC/IC axes. This is required for whole-sign house systems. In whole-sign house systems the axes do usually not coincide with the house axes h1/h7 and h4/h10. Rules are:

  1. House 1 starts at 0° of the sign where AC falls into, and ends at 30°. House 7 (and DC) accordingly on the opposite side. This means: AC is NOT at cusp of house 1, nor is DC at cusp of house 7.
  2. Starting from house 1, all other houses are simply numbered in the order of the signs.
  3. In consequence, MC can fall anywhere in houses 9, 10 or 11, and usually does not align with 0° of house 10. IC correspondingly on the opposite side, i.e. it can fall into houses 3, 4 or 5.
  4. Aspects from planets to the axes need to be calculated explicitly too, we cannot assume that e.g. sun square asc is automatically same as sun square house 1 cusp.

To get this working, many changes were necessary.

  1. In kerykeion/astrological_subject: asc, dsc, mc, ic are now calculated explicitly using swiss ephemeris library. Everything else follows from that. All these axis points are treated exactly like all other planets now.
  2. In kerykeion/settings/kr.config.json: There are now explicit settings for asc, dsc, mc, ic.
  3. In kerykeion/utilities.py: A very important change was required here. Previously, there was a method "check_if_between". This method needed to be adapted. Previously, a point was supposed to be between two other points on a circle if it was strictly greater than the start and strictly smaller than the end point. This this lead to a problem with the new explicit calculation of the axes when using Placidus or Campanus house systems, where actually ascendant does fall on the house 1's cusp at 0°. What happened was that the descendant used to fall on 0° of h7, but the check_if_between method assumed it had to be strictly greater than that, so descendant ended up (falsely) not in h7 but elsewhere randomly. The new (renamed - feel free to change the name again) function "is_point_between" has a different semantic: point must be greater than or equal to start point, or strictly less than end point. With this semantic all worked out smoothly.
  4. Also axes had to be added to kerykeion/kr_types/kr_literals.py and kerykeion/kr_types/kr_models.py
  5. Lots of changes in test files were necessary, in particular tests/test_astrological_subject.py, tests/test_astrological_subject_jyotish.py [NEW], tests/aspects/test_natal_aspects.py, tests/aspects/test_synastry_aspects.py, tests/aspects/expected_natal_aspects.py, tests/aspects/expected_synastry_aspects.py. What I did not test extensively are aspects to MC/IC axis though, as these are not very relevant in vedic astrology.

What is still open is to fix tests/charts/test_charts.py. I am lacking info the intended structure of the SVGs, so it's hard to fully grasp what's going on there. My impression is that currently the issues in the test cases are not arising anymore from my changes, but from the fact that new "correct" SVG files first need to be created that can then be used as a reference for the test cases to test against. I might be wrong about that, though. Also, I don't know exactly how the creation of charts looks visually due to the same problem here, maybe some more work is needed, or maybe not, I cannot tell. A reference to more documentation would be helpful for me and others, I'd guess.

@g-battaglia g-battaglia changed the base branch from develop to dev/axes-as-KerykeionPointModel January 7, 2025 17:57
@g-battaglia g-battaglia merged commit 583052c into g-battaglia:dev/axes-as-KerykeionPointModel Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
g-battaglia added a commit that referenced this pull request Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants