Looking Ahead to Version 0.5: Transits, Progression, and Directions

[mikestar13]

First off I am going to canonize the three letter abbreviation TPD for discussing these techniques collectively. It will save me a boatload of typing down the road.

L = ecliptic longitude below.

My questions all involve angles.

Transits to the Nativity: we consider hard aspects by L to the As and Mc.
Transits to angles of a relocated nativity are valid in and around that locality.

Transits to SSR angles: return is cast for the locality where where the return actually occurred, hard aspects by L to the As and Mc.
We don't consider transits to the angles of the SSR relocated to the locality of the moment (?).

Transits to SLR angles: same rule as SSRs, relocate to locality of the moment, ignore?

Transits to Q2 angles: location where the transit occurs, not SSR location if they differ(?)

Transits to PSSR angles: same rule as Q2(?)

Transits to Solar Arc angles: are these even valid?

Progressions to natal angles: locality where they occur?

Solar arcs to natal angles: same as progressions (?)

How do we handle tertiary angles? In fact how do we calculate tertiaries? Q1 or Q2 analog?

I'm assuming progressions/directions to a progressed/directed chart are not valid.

[mikestar13]

Planetary state? (Since we're only showing it for planets?)

There is an advantage to having fewer syllables rather than more syllables, though. "Astro State" seems hokey.

What do you think of "Planetary State"?

Not bad at all, but according to your example,I will be listing Angle = X/Y midpoints. What's a good term that encompasses planets and angles? Or maybe only do planets and have a separately titled section for Angle midpoints?

[mikestar13]

Another question: are midpoint of the form X = Mo / Y part of the planetary state of the Moon? If so, no separate listing of angle midpoints will be needed but the length of the midpoint list nearly triples, as Su = Mo / Me would then be listed under Su, Mo, and Me. This inclines me to think "no". But OTOH, Ve co Mars will be listed under both Ve and Ma.

[Jim Eshelman]

Transits to the Nativity: we consider hard aspects by L to the As and Mc.
Transits to angles of a relocated nativity are valid in and around that locality.

I am convinced this is the right approach. However, my certainty shouldn't be confused with accuracy . At some point - later in the development cycle than we've really talked about, probably in the 1.x range - I think we need all of these things calculated mundanely. Astrologers need to be able to actually test (extensively, exhaustively) this issue of which/both/etc. of these categories are valid.

With the above, though (under the "certainty" heading) transits to EP/WP in RA.

Transits to SSR angles: return is cast for the locality where the return actually occurred, hard aspects by L to the As and Mc.
We don't consider transits to the angles of the SSR relocated to the locality of the moment (?).

I'm pretty confident this is correct. However, from watching the last five years, I actually think transits to the local angles are very weak effects, but they might be no effect.

It seems to me that transit to a Solar Return should simply be to wherever that SSR is calculated for.

Transits to SLR angles: same rule as SSRs, relocate to locality of the moment, ignore?

I don't find them useful in the slightest. Nonetheless, I don't see a reason to restrict the charts for which transits could be run.

Transits to Q2 angles: location where the transit occurs, not SSR location if they differ(?)
Transits to PSSR angles: same rule as Q2(?)

Current location.

It just occurred to me that you're designing an "all in one package" report of some kind? Hadn't thought of that. Going chart by chart, it makes most sense to run transits for wherever the chart is calculated, e.g., to get local quotidians, use a local natal. But maybe you have a better plan?

BTW - really useful request IMHO - I bet it's not hard to export a report as a CSV, right? A CSV button? Because I dump multiple things into Excel and then sort and format the heck out of it.

Transits to Solar Arc angles: are these even valid?

I don't think they're valid at all.

Progressions to natal angles: locality where they occur?

Always to the natal for birthplace. Equally for the current locale.

Solar arcs to natal angles: same as progressions (?)

For people who use Solar Arcs, there is universal agreement that they work at birthplace. I submit that locale is comparably important.

How do we handle tertiary angles? In fact how do we calculate tertiaries? Q1 or Q2 analog?

From my testing, terts angles work best in the "Solar Arc in longitude" model. (I suppose people should be given a choice of this vs. Naibod in RA, for this and primaries.) No quotidian equivalent seems applicable and, in any case, would be very fast. Birthplace and locale seem both to work indifferently, often with excruciatingly close orbs.

I'm assuming progressions/directions to a progressed/directed chart are not valid.

Not sure what you mean. Are you saying secondary progressed planets to other secondary progressed planets aren't valid?

[Jim Eshelman]

Another question: are midpoint of the form X = Mo / Y part of the planetary state of the Moon?

I don't think so. I can see why some people might want to see them there (a lunar influence of some kind, but they aren't part of the actual state of Moon itself. - For example, in addition to my Mo = Su/Pl, I have Su = Mo/Me. You could argue that both of these have something to say about both my lunar and solar energies, but if I'm addressing the specific question of "What conditions my Moon?" or "What conditions my Sun?", they are only important where they already fall.

I have some other complexities I'd like to include in a perfect world, but they introduce enough problems I haven't raised them.

I think have separate midpoint-only lines for the Asc and MC (and, if chosen, Vx <shiver>).

[mikestar13]

I mean the solar arc of a tertiary (for example) is not valid.

[Jim Eshelman]

While anything is possible until we test it, I agree this sounds nuts.

Also, I'm not sure what it would mean since a tert is not a chart fixed in time. It's a moving target.

[Jim Eshelman]

What do you think of "Planetary State"?

Not bad at all, but according to your example,I will be listing Angle = X/Y midpoints.

I forgot that when I wrote the above. - We wouldn't be doing this except it's the only reasonable place to put midpoint angles. BTW, midpoint sign might as well go there, too, though it seems wrong to list planets on angles here as if they were aspects in the usual sense; so maybe just sign and midpoints?

What's a good term that encompasses planets and angles? Or maybe only do planets and have a separately titled section for Angle midpoints?

In theory, I like the cleaner view of planets only, but it's the obvious, logical place to put midpoints to angles if midpoints are turned on.

Maybe... just a single blank line after the planetary state, then the lines for Asc and MC midpoints? It doesn't seem we should take three lines, a new label, and mental clutter to separate them, but maybe just a blank line.

[mikestar13]

I can output a csv file quite easily in addition to what will show on screen with the chart. I will start doing this for transits and will add on each type of progression and direction as I add them in successive releases of 0.5.x. I'm thinking of ordering the them transits, quotadians, PSSR, solar arcs, primaries, tertaries in terms of the order I code them. As for the solar arc of a tert, it is a moving target but is calculable iteratively (just like a KLR), but in these sort of cases, there seems to be no point in doing it. So transits to the Eastpoint in RA should be part of the package(transits to EP in longitude not considered), but for the time being the As and Mc will be by longitude (mundane transits won't be hard to add once we agree on a rigorous definition of them).

[Jim Eshelman]

Here's the complexity I have in mind for the planetary state report. Because I see inherent problems, I'm happy to skip all of this, but I thought I'd throw it out into the brainstorming mix.

Consider my Mercury, which would appear something like this:

Code: Select all

Me Lib         | co Sa 1°36'
               | = Ur/Pl 23'   Ju/Pl 30'   Ve/Ne 44'   

It doesn't appear to be a very impressive Mercury. (The midpoints help.) Mercury is at least deeply middleground and probably should count as background. It's only aspect is a close conjunction of Saturn (which fits - especially in its best features - but let's presume you don't know me).

The only way to properly understand my Mercury's importance and the overall strength of it in my life and psyche is to know that my Sun is in Virgo. That makes all the difference in the world.

My Uranus would appear interesting even without this extra consideration, but perhaps not in the same way. Under current plans, my Uranus would appear:

Code: Select all

Ur Can         | co Ju 0°17'   tr Ve 1°27'   sq Ne 2°00'   op Ma 4°25'   tr Mo 5°56' 
               | = Su/Sa 22'

Not bad - the aspects are quite strong - but, again, the scope and intensity of the planet doesn't land without noting that it rules my Moon-sign.

Possibly, we need to do nothing at all about this, or possibly the solution is to add Vir-Su to the front of the Mercury line's aspects and Aqu-Mo to the front of the Uranus line's aspects. Perhaps chief among the complexities of this are the continuing debate-space about a fixed planetary dignity list. - There is then the flip side, the side that shows "take-aways": Should the Venus and Neptune lines lead with (Vir-Su and the solar line lead with (Aqu-Mo), since the teaching is that explicitly there are contra-Neptunian, contra-Venusian, and contra-solar effects operating for a Virgo-Aquarius as one of the most fundamental things in the chart? (And then the astrologer is left how to sort out that Venus is closely angular but a luminary is in a contra-Venusian sign.)

Tossing it out there for discussion and brainstorming...

[Jim Eshelman]

I'm thinking of ordering the them transits, quotidians, PSSR, solar arcs, primaries, tertaries in terms of the order I code them.

Sequence doesn't matter to me since half the purpose of csv export is that I can sort them by date and time (in addition to formatting). I assume which techniques are included will be user selectable? (Individual check boxes?)

So transits to the Eastpoint in RA should be part of the package (transits to EP in longitude not considered), but for the time being the As and Mc will be by longitude (mundane transits won't be hard to add once we agree on a rigorous definition of them).

And transits to EP/WP in RA is tedious, because, in theory, the only way to get it right is to precess the transiting planet back to the natal epoch. You might be able to get it, though, by precessing the natal MC (not EP) to the current epoch - I don't know what the difference might be in timing. (This, of course, is why we need computers <g>.)

[mikestar13]

Basically we need to agree on a default list of planetary dignities and debilities, which will be user editable in Program Options (I can't imagine wanting to change this per chart). Then listing luminary signs when positively or negatively relevant, example for Venus, luminary in Taurus, Libra, or Pisces (+) or Aries, Virgo, or Scorpio (-). We can of course have the case of the Sun and Moon giving contrary indications. Example Saturn with Sun in Capricorn and Moon in Cancer.

[Jim Eshelman]

We can of course have the case of the Sun and Moon giving contrary indications. Example Saturn with Sun in Capricorn and Moon in Cancer.

But that, of course, is meaningful. (That's why I suggested Vir-Su and Aqu-Mo instead of something simpler. Having Trump as Tau-Su and Sco-Mo makes the point, but so would a Virgo-Libra like Jimmy Carter.) I propose the following list (for pluses; opposite signs give minuses):

Tau - Moon Venus
Gem - Mercury
Can - Moon Jupiter
Leo - Sun
Virgo - Mercury
Libra - Venus Saturn
Sco - Mars
Sag - Jupiter
Cap - Mars Saturn
Aqu - Uranus
Pis - Venus Neptune
Ari - Sun Pluto

There will of course be multiple seeming contradictions, but that's true for the aspect list alone and, in any case, should be left to the astrologer to resolve. A Pisces with a Class 1 Moon-Mercury conjunction won't be contra-Mercury in any conventional sense (though there is particular meaning to get from it, e.g., is likely to be data-driven without being anti-belief). A Leo Moon with Uranus rising is not going to be contra-Uranian, a Taurus with an angular Mars won't be the usual form of contra-Mars (but is likely to be a person who is driven by a commitment to peace and willing to be a warrior at the drop of a hat). Or whatever. The program's job is to give the data.

Of course, I also don't want to so overload it that the "analyze at a glance" is lost.

[mikestar13]

I will do some testing about how to adjust for precession in RA for calculating EP contacts. What I've been assuming is that the ecliptical longitude and latitude of a point are fixed for all time and the target RA is recalculated from the ayanamsa and OE of the moment (iteratively). This certainly seems proper for planets. Angles? Maybe not. Questions like this remind me why in my early days of learning I ignored transits to angles altogether!

[mikestar13]

I'm thinking in terms of putting luminary signs on the first line for a planet (if relevant) then starting the aspects on the second line. Aspects will start on the first line if neither luminary sign is relevant. That way we see luminary signs as part of the general state of a planet (as well as the planet's sign and angularity), this general state being conditioned firstly by aspects and secondly by midpoints.

[Jim Eshelman]

Interesting. I won't have an opinion until I see it and, in any case, it's your program So, my Mercury (for instance) would look something like this?

Code: Select all

Me Lib         | Vir Su
               | co Sa 1°36'
               | = Ur/Pl 23'   Ju/Pl 30'   Ve/Ne 44'   

[mikestar13]

Exactly, Jim, though I'm thinking the left side should have angularity info as originally suggested.

[Jim Eshelman]

On angularity, my thought is that both FG and BG should be listed (with their scores) even if BG is otherwise turned off (the use of it in the top list is different from its use under State), with nothing shown but empty space if MG.

I think the table will look good with this design, and visually draw the eye where it needs to go.

[mikestar13]

A Leo Moon with Uranus rising is not going to be contra-Uranian, a Taurus with an angular Mars won't be the usual form of contra-Mars (but is likely to be a person who is driven by a commitment to peace and willing to be a warrior at the drop of a hat). Or whatever. The program's job is to give the data.

That second line is reminiscent of the old Klingon proverb "a warrior for peace is still a warrior".

[Jim Eshelman]

Oh, another idea... brainstorming, thinking some people are uncomfortable with giving strong emphasis to dignified planet characteristics in understanding signs... if dignities are user configurable, then with an empty dignity list I assume that line simply would never appear, right?

Also, if there is a user-configurable dignity list, the sign abbreviation could have a + or - after it, a standard part of the "state" that we're otherwise relying on the user to have in their head (perhaps rightly so).

My Venus would then look like:

Code: Select all

Ve Sco- BG   0% | whatever goes her for Sun in Virgo
                | sq Pl 0°13'   tr Ur 1°27'   tr Ju 1°44'   sx Ma 2°57'   tr Mo 4°29'
                | Ne/MC 20'   Ur/As 57'

or my Saturn:

Code: Select all

Sa Lib+         | co Me 2°24'   
                | Mo/MC 22' d   Ma/Pl 34' d

[mikestar13]

Yes, excellent suggestion. So my first step will be redesigning the Program Options page to call up a page to change dignities or turn them off. I had been thinking of adding the +/- indication: Vi Su + or Pi Su -. Great minds, huh?

[Jim Eshelman]

"Turn them off" could just be a "clear all" button (next to a "load defaults" button or whatever).

On Virgo vs. Pisces Suns, strangely similar minds <g>.

[Jim Eshelman]

I think there should be a default Students option. It would be a Natal substitute for when people are following a somewhat simplified "learners" approach. (I'm thinking about beginners in general and, in particular, when the "big book" is available and people are learning from scratch.) It would have these characteristics:

• Eris, Sedna, Vertex, and Node default off.
• Angle orbs the same except no C3 for minor angles.
• Background at cadent cusps, DO show BG.
• No class 3 aspects.
• No octiles (i.e., Ptolemaic aspects at C1/2; mundane hard aspects C1).
• Show all aspects.

However, if you like this idea then there needs to be a way to "permanently" select the Student option in lieu of Default_Natal (and switch back later). That's a new feature, of course. As I think about THAT, I start visualizing a page off of Options where people can select the Options files they want as their own defaults. (Though I think Ingresses and Returns are likely to be pretty stable, or inspire only small tweaks, once you start the slippery slope of changing default options files... well, you get the idea.)

Just thinking aloud; and I don't want you to get bored or run out of things to do <vbg>.

[Jupiter Sets at Dawn]

I like this idea a lot.

[mikestar13]

Great idea. I will built in in to version 0.4.5. The user will choose on setup whether to start with Student options or Standard options, and will be able to change their choice in Program Options page (I have to re-design the Program Options page anyway for the Cosmic State? report). A Student Natal option file will be provided with the program, and will be the shown whenever I would use Default Natal, if the student option is in effect. Exception: an existing chart will use whatever option set it was calculated with (of course it's merely a few clicks to recalculate it with Student Natal if desired.

[mikestar13]

Love the way 0.4.5 is shaping up. It looks like 0.4.5 (or a sucessor 0.4.x if bug fixes are needed) will be my Christmas present to the solunars.com community. When the 0.4 line is declared stable, I can start the new year with work on Version 0.5 preview and get into predictive techniques beyond solunars.

I notice I have 1113 posts and am a Synetic Member, by the time version 1.0 is out, I suspect I'll be Irish.

[mikestar13]

{
"name": "Nelson, Michael",
"type": "Natal",
"class": "N",
"year": 1957,
"month": 4,
"day": 1,
"style": 1,
"time": 8.383333333333333,
"location": "Huntington Park, CA USA",
"latitude": 33.98277777777778,
"longitude": -118.21194444444444,
"zone": "PST",
"correction": 8.0,
"notes": "AA from BC",
"options": "Default Natal",
"ayan": 24.146828474588713,
"oe": 23.443429501053593,
"cusps": [
0.0,
40.13163885272594,
71.31536362281548,
91.96009498352254,
110.68605303280091,
134.70659912188054,
173.54681977112037,
220.13163885272596,
251.3153636228155,
271.9600949835226,
290.68605303280094,
314.7065991218806,
353.54681977112034
],
"ramc": 317.29852839122873,
"Vertex": [
187.07520727572447,
158.34887865058244
],
"Eastpoint": [
25.600411218715404,
349.90016513508596
],
"Moon": [
2.3029186731060567,
2.074919142324345,
12.508326258468337,
23.764952137406034,
12.140278351946849,
92.7976462368419,
26.182708904705876,
333.7902258964518
],
"Sun": [
347.52946186275284,
6.968971295992405e-05,
0.9866428379087041,
10.735793446728096,
4.618311637687994,
108.32227632878511,
32.50416345937584,
326.13048691911445
],
"Mercury": [
359.6820016780924,
0.5902431231173785,
1.9369427383750049,
21.836774087442315,
9.797912982992658,
96.13813498585739,
26.512970627114264,
333.35521337338827
],
"Venus": [
344.2186276313878,
-1.3653881980385798,
1.241432950276549,
8.22216793362342,
2.063272648867241,
112.55687576089628,
32.852570057821126,
325.03689019330403
],
"Mars": [
45.143306388800866,
1.2308554413393373,
0.6288828661604857,
67.40159635720214,
23.06392084752611,
59.86254504285051,
-2.4790834710972685,
2.865975530105665
],
"Jupiter": [
150.8481675480473,
1.5531408189006228,
-0.1199560726182357,
176.02324906241392,
3.41472673507017,
307.8168386216736,
-37.768505938319926,
135.55564415866323
],
"Saturn": [
230.09876336071648,
1.8235792140252236,
-0.01441403685676921,
253.13551830351358,
-20.702090635741193,
238.25001805042734,
8.074036645890676,
189.4710665224584
],
"Uranus": [
98.7503930094011,
0.6218815659955576,
-0.007792102426372138,
125.3379871125082,
20.119896157333383,
13.692907588785204,
-34.71059257160315,
71.13321306067341
],
"Neptune": [
187.6199930447117,
1.8016638724452962,
-0.025224255634424028,
210.23488100563432,
-10.399000444208983,
270.7095977429158,
-19.88972138919371,
160.10887305781017
],
"Pluto": [
124.1152459615972,
11.38067926665411,
-0.016939636929768145,
154.67134348685715,
22.71842272243848,
341.27003385946426,
-30.938219052745534,
118.17891872805049
],
"Eris": [
344.7297616609078,
-23.098121664233748,
0.01158016179295707,
17.485543096158544,
-17.665223806104752,
121.99047952534835,
12.89722590190725,
344.89150433343104
],
"Sedna": [
1.8410349424327486,
-10.505674949773944,
0.009920014328618073,
27.892579784380086,
0.23623792064067142,
100.93899088675425,
16.12974048739263,
343.5876844902054
],
"Mean Node": [
207.765132022814,
0.0,
-0.052992012717507614,
229.49335808163937,
-18.24784950147491,
253.56293112856645,
-8.329253495586945,
171.32113070888252
],
"True Node": [
205.904591221757,
-0.0,
-0.05634255065889186,
227.6060812648484,
-17.75787048968071,
254.9673231641675,
-9.569053775561382,
170.09847050386907
]
}

This is the content of a TMSA chart file (Nelson, Michael~1957-04-01~Natal.dat), the heart and soul of TMSA. When a chart is calculated, this is what is created, then the text file (Nelson, Michael~1957-04-01~Natal.txt) is calculated from it with the wheel, aspectarian, etc. You will notice factors which can be switched off are still calculated (Eris, Sedna, Vertex, both forms of the node), but not added to the .txt file.

For Solunars (and going forward, any bi-wheel chart) their is an additional field "base_chart". This contains the entire data of the chart from which the SSR (or ...) was calculated (birth chart in most cases).

I did a bit of pruning of items no longer in use, and an addition for version 0.4.4. The format is fairly stable now. I don't anticipate removing anything else, with a pretty high degree of certainty. So concurrent with the release of version 0.4.5 or slightly after, I will publish a more formal specification of the chart file format. This will serve two purposes:

1. It will be a boon to my successor programmer when I pass on, or worse become unable to program.
2. It will enable the creation of add on programs in any programming language, both by me and by third parties.

So if you program, and want to do something with TMSA charts (calculate harmonic or composite chart, age harmonics, ...) have fun. The chart files are not covered by the AGPL (in general, the output of a program, distinguished from the program itself is not subject to software licensing) and you may use any license you like if you publicly release your program, though it is my personal preference that you use an open source license (Not necessarily the AGPL, I personally prefer the MIT license: https://opensource.org/licenses/MIT. TMSA uses the AGPL because the use of the Swiss Ephemeris requires me to).

[Jim Eshelman]

I'm thinking of ordering the them transits, quotadians, PSSR, solar arcs, primaries, tertaries in terms of the order I code them.

Mike, I'm not sure what you intend for primaries (I have some guesses, but that's all), so I thought I should get a request into this thread.

I've been reading Kenneth Bowser's book, Primary Directions and the Horoscope of the United States (It's a good read btw) and chatting just a bit with Kenneth about his use. While acknowledging planet-to-planet primaries as working, his main focus is on primary angles crossing natal planets (direct and converse - mundane only) using a rate of 1°/year for angle rotation.

The 1°/year rate seems arbitrary and artificial to me; OTOH, I've never been too impressed with primary rotation and Kenneth is getting good results. The least this tells me is that people need to be able to check out what he's doing.BTW, he's not stuck on the rate, but it's been steady enough for him that he can rely on it.

This brings up several ideas about these:

-- Various rates need to be allowed (I think you were planning this), to which 1°/year should be added.
-- As on so many other things you are planning (such as quotidians), we need to be able to choose between mundane contacts, ecliptical contacts, and both kinds (maybe a non-exclusive check box on whether to include each type). I'm looking forward very much to being able to compare mundane vs. ecliptical contacts on quotidians to perhaps settle the question once and for all, and that now seems equally important to primary angles.
-- I don't know if you were planning primaries (as in your sentence above) for the degree-ish per year traditional "progressed angles" along with secondaries (vs. real secondary angles which are quotidians). If so, I'd like some way to get primaries on their own (if for no other reason that that we may be talking about different but similar systems: If Kenneth is right about the degree/year rate for wholly mundane primaries, that may or may not be the same as composite "progressed horoscope" system.

Most astrologers simply have never had the ability to test any of a dozen or more questions which (actually) are really fundamental. TMSA as you described it has a really great chance of finally doing that - if we can just get people to use it.