Time Matters 0.6.0a Alpha Pre-Release - Windows

[Jim Eshelman]

Works great! (And I see you added Orcus and rearranged things on the Options page. Neat.) Thanks

And no changes to midpoints were needed because they're already by orb.

[Ember Nyx]

Funny story, I had had Orcus there the whole time... It was just hidden behind Sedna because I screwed up the Y coordinate for those entries.

And no changes to midpoints were needed because they're already by orb.

The midpoint bugfixing is the last part of this beta that still needs to get fixed before we can call it a stable release and I can start working on 1. stable Linux and MacOS releases, and 2. the 0.7 stuff.

The things on my radar for 0.7 are:

• Add Novien table to bottom of chart page (i.e. the natal chart page, I'm assuming)
• Allow users to display contacts with angles as aspects in the aspect list (i.e. optionally, additionally parse them as aspects within the normal rules that govern contacts to angles)
• Add support for 10° multiple aspects
• Add partile transits to natal angles to Other Partile section
• Include zips under source control (i.e. distribute downloads via Github rather than pass around direct download links)

Additionally, I'm hoping to get in some more infrastructure for the minor solunar return charts - Ennead variants, KLRs, NLRs, anlunar variants, etc. Lunisolars and solilunars would probably come later due to some technical (algorithmic) challenges. (I probably have semi-usable code lying around to calculate those, but I'm not confident in its behavior.)
Triwheels (and probably quadwheels) do functionally work in terms of chart display and aspect parsing stuff, but the various setup screens and their logic (i.e. finding the desired return datetimes) aren't set up.
It's fine if the kinks aren't worked out on those - but I find myself continually missing this functionality whenever I slog through calculating one of these charts and their aspects (especially mundane aspects) the hard way.

[Jim Eshelman]

The midpoint bugfixing is the last part of this beta that still needs to get fixed before we can call it a stable release and I can start working on 1. stable Linux and MacOS releases, and 2. the 0.7 stuff.

That's an exciting juncture! As much as I want to get to 1.0, I'd also like to begin offering this to people who are on MacOS since there is really nothing for them to use right now to do anything like we want.

The things on my radar for 0.7 are:
Add Novien table to bottom of chart page (i.e. the natal chart page, I'm assuming)

My concept is that it's only useful in the natal right now, and there should an Options setting to turn it on/off. Perhaps default it to On, though, so people start seeing it.

Given that options setting, I can't think of a reason (unless there are programming complexities) not to make it available on returns and ingresses as well - defaulted to Off, though. (Returns would only have it for the return, I guess, not repeat the natal.) I can't think at the moment that people really want this, and it could lead to some insane pathways; but if it's only a matter of copying a few lines to the returns and ingresses, I can't think why NOT to make it available as an option if someone digs enough to find it.

Allow users to display contacts with angles as aspects in the aspect list (i.e. optionally, additionally parse them as aspects within the normal rules that govern contacts to angles)

This might be one or the coolest additions. I'm at least interested to see whether the mind takes to this better than NOT having it. - As part of this, I think an important feature is to use it to capture transits to natal angles in return charts (either in the first list because it's foreground or in the Other Partile). - Oh, I just saw that you had that last one below.

Add support for 10° multiple aspects
Add partile transits to natal angles to Other Partile section
Include zips under source control (i.e. distribute downloads via Github rather than pass around direct download links)

All good.

Additionally, I'm hoping to get in some more infrastructure for the minor solunar return charts - Ennead variants, KLRs, NLRs, anlunar variants, etc. Lunisolars and solilunars would probably come later due to some technical (algorithmic) challenges. (I probably have semi-usable code lying around to calculate those, but I'm not confident in its behavior.)

Some of these I'm quite eager to see. (I'd do a lot more KLRs with it. Even though I have a kluge in Solar Fire, the precision isn't as good as I'd like.) I don't know how much people in general are interested in all this, but we ultimately should have it.

Since KLRs require calculating secondary progressions, will these be available ahead of the return variants? Having secondaries by themselves first would make QA go better, since getting the rate exactly right needs some work compared to any software in the past. -- Unfortunately, introducing secondaries introduces a few extra complications to get the variants correct.

It's fine if the kinks aren't worked out on those - but I find myself continually missing this functionality whenever I slog through calculating one of these charts and their aspects (especially mundane aspects) the hard way.

Oh, yeah! I definitely hear that. I'm not sure what we'll find with stuff like mundane three-layered aspects in a Kinetic.

[Ember Nyx]

Since KLRs require calculating secondary progressions, will these be available ahead of the return variants? Having secondaries by themselves first would make QA go better, since getting the rate exactly right needs some work compared to any software in the past. -- Unfortunately, introducing secondaries introduces a few extra complications to get the variants correct.

You're right, and I kind of forgot about that part.

Here's my thought process on that - getting the julian day corresponding to the progressed planets is I think as simple as:

(Pseudocode)

Code: Select all

Number of days elapsed since birth = target datetime - birth datetime
Julian day for prog planets = number of days elapsed since birth * progression rate
(Then just plug in that julian day and calculate all the positions)

Is that correct?

Also, I feel like it would be a good idea to eventually include quotidian charts on the same transit/prog menu page, since they'd work the same way: very similarly to solunars, but using an exact date and time rather than finding active/forward charts. Calculating quotidians requires a lot of similar infrastructure to calculating anlunars, KLRs, etc - we'd need to calculate a few charts along the way to get their points, and in doing so would need to know "what is the UTC julian day for the active SSR/quarti-SSR/whatever," etc.

[Jim Eshelman]

This could be a long, rambling answer; or maybe I'll use a bit of self-discipline.

In fact, I'll create a new thread in the Wish List File Room sub-forum about progressions. That will be more useful as a stand-alone.

Ember, I need to say first (and I'd forgotten this myself) that I saw all of these minor chart add-ins as version 2.x developments. I looked back at the version 1.0 target list and - apologies for being surprised - saw that you've almost covered everything. All that's really left on the original plan is the Novien table and a couple of minor text matters (and then the Mac and Linux builds you already said come next).

That you've essentially finished the original plan for 1.0 doesn't mean we can't add more (and it certainly doesn't mean we shouldn't look ahead to anticipate infrastructure needs). I wanted to float the question, though, of whether it's a good idea to add these extra things at this stage. There seems to me great merit in having a full release 1.0 that we can start evangelizing, spreading the word online, getting more people involved in a product we're willing to say is completely finished (while subject to expansion).

Mike N's original plan of natals / ingresses / solar and lunar returns has been sharpened a great deal. Maybe a fresh QA look will find little things that need tweaking (oh, you said there's is something still to be done to get midpoints right - I forgot that). What do you think about making a beeline for a 1.0 release with the short list remaining? That would mean Noviens now and the rest of your 0.7 list being a 2.0 target.

(I'll address the exact progression questions in the next answer and then start working on a Progressions wish list post.)

[Jim Eshelman]

Here's my thought process on that - getting the julian day corresponding to the progressed planets is I think as simple as:

(Pseudocode)

Code: Select all

Number of days elapsed since birth = target datetime - birth datetime
Julian day for prog planets = number of days elapsed since birth * progression rate
(Then just plug in that julian day and calculate all the positions)

Is that correct?

Yes, that's it in essence (and that's it exactly for the simplest case). The whole complication of the simplest case is in getting the exact progression rate constant.

However, there are important non-simplest cases that we need to include - things that (at the moment) I don't think are valid but really do need to be examined because (1) they represent a correct representation of Fagan (and to a lesser extent Bradley) positions, (2) many Siderealists wouldn't take us seriously without our including them, and (3) they really do need to be examined - we've never had the right tools to do this exhaustively even though smaller studies seem to have settled the issues.

I'll cover these in the progressions thread but they boil down to (1) allowing both the Q1 and Q2 progression rates and (2) allowing the argument (the pace at which time unfolds) be either even by the mean solar rate or uneven by the apparent solar rate. The two variations that use the apparent solar rate are more complicated, even though they ultimately follow the concept of your pseudo-code.

The apparent solar rate methodology will also be essential for the PSSR. Both Fagan and Bradley held that the PSSR used the apparent Sun, not mean Sun (uneven, not even) rate. Kenneth Bowser and I independently concluded that the PSSR worked by the mean rate, though I'd say this is based on too few examples and too little work overall. I'd like to put the way of testing this easily in everybody's hands rather than just conclude that Ken and I know what we're saying <g>.

So there are variations. Probably the progression options table should be able to pick from all four variants and then other things (like Kinetics) based on those progressions use whatever variation is selected.

Also, I feel like it would be a good idea to eventually include quotidian charts on the same transit/prog menu page, since they'd work the same way: very similarly to solunars, but using an exact date and time rather than finding active/forward charts. Calculating quotidians requires a lot of similar infrastructure to calculating anlunars, KLRs, etc - we'd need to calculate a few charts along the way to get their points, and in doing so would need to know "what is the UTC julian day for the active SSR/quarti-SSR/whatever," etc.

One of these days we're going to have to confront the fact that we have too many perfect synonyms in use - multiple names for the same thing. When quotidians first came into use (and multiple variants of them unfolded) it seemed obvious to give them their own names. However, ultimately, the natal quotidian is exactly the same as the progressed natal chart. (Ditto with the solar quotidian and the progressed SSR.) So, in doing secondary progressions, we are exactly doing quotidians already.

Yes, I agree it's for an exact date/time. I think the options pages and landing pages are the hard part of all of this: The calculations themselves are straightforward even when complicated. These are techniques where the computer can shine and make up for the nearly HALF CENTURY we haven't been able to give this research the right attention.

BTW, if there is currently any (infrastructure or definition) reason this can't all be done for calculated ingresses, we have to change that. Some of these techniques are basic to the ingress system (and I've been holding off researching all the variations until we have the software).

Bottom line, yes, I think your above paragraph shows you've got this all sorted out in your head correctly.

At some point we need to consider how many progression forms to include. One could argue for only including secondaries. If TM becomes widely used, there will be a noteworthy minority wanting tertiaries. This is mostly the same as your original formula above (with a different progression rate) except that the angles are handled differently.

One further thing: For the sorts of things we're discussing now (transits, progressions, quotidians), I think we want to think about two separate delivery systems: One is just the calculation of a stand-alone chart. The other is more of a report outputting contacts by date etc. that they are exact. The 'calendar' reports, of course, depend on the ability to calculate the individual systems in the first place.

[Ember Nyx]

That you've essentially finished the original plan for 1.0 doesn't mean we can't add more (and it certainly doesn't mean we shouldn't look ahead to anticipate infrastructure needs). I wanted to float the question, though, of whether it's a good idea to add these extra things at this stage. There seems to me great merit in having a full release 1.0 that we can start evangelizing, spreading the word online, getting more people involved in a product we're willing to say is completely finished (while subject to expansion).

Mike N's original plan of natals / ingresses / solar and lunar returns has been sharpened a great deal. Maybe a fresh QA look will find little things that need tweaking (oh, you said there's is something still to be done to get midpoints right - I forgot that). What do you think about making a beeline for a 1.0 release with the short list remaining?

I see what you're saying, and yeah, it's probably worth it to nail down the core 1.0 stuff as the immediate next priority. I do think we should talk about menu design/etc prior to 1.0 release. Time Matters doesn't really conform to modern UI/UX conventions and I'd like to rearrange things before championing it widely.

That would mean Noviens now and the rest of your 0.7 list being a 2.0 target.

Nitpick, I see things like transits/progs/etc as being 1.x releases rather than 2.0. I personally see a 2.0 release as something like 1. an entirely new, modernized Python framework instead of Tkinter (or moving to something like Electron, which is Javascript-based), or more likely, 2. a web application that would be inherently cross-platform and mobile-compatible out of the gate. I don't think there's a reasonable way to get full mobile and cross-platform desktop functionality without having it be a website (which explains why no existing program is either). That is a whole other can of worms (where do charts live? etc), but I see Time Matters (or an open-source successor, whatever the name) as eventually being a web app.

[Jim Eshelman]

No disagreement with the broad, expansive picture. Those are all important steps and moves (and the idea of webapp deployment possibilities, which also takes it to mobile platforms, is really great!).

I was tending to think of the first successor version or two (I hadn't thought past 3.0) being more feature additions than platform additions. This isn't to slow modernization and the other expansion, just to not rush all features into the first pushed version.

And yeah, menu work sounds good - I'm sure we can do better (I say that being enormously grateful for what we have). And regarding transits etc., I've been patiently hoping for the ability to put any chart at all "inside" (or "outside") any other - to get any blending similar to what we have with transits and progressions but with any two charts of any kind. This would seem useful as a step toward transits, progressions, and eventual synastry stuff. (I soooo want the cool synastry stuff but I know it will be way easier after a lot of other stuff is built ahead of it).

[Jim Eshelman]

Or, to say it another way, I've been quite willing (when release time comes) to say, "It doesn't look like much, you won't use it to visually impress anybody, but man-o-man it does things no other program does and is well-crafted to astrological practice for Sidereal astrologers. Oh, and it's free."

At the same time, I'd be even happier not to have to say the first part of that

[Ember Nyx]

I'm currently working on a design mockup for the various menus in Figma, and I'll share a link once I have that ironed out. I'm also doing some more research to see what is doable with Tkinter (the UI library that Time Matters relies on to render windows) and add-on packages. The research portion of that will probably take the longest, so I suspect the remaining bugfixes and more feature work will happen before that's ready - but just so you know!

[Ember Nyx]

I may have finally fixed midpoint weirdness. I'm fairly confident that I'm adding the midpoints using the correct logic (only count RA contacts if both points are in orb to EP-a/WP-a even if that's not their closest angularity, etc), and I am apparently calculating them correctly, but I'm not totally sure I'm marking mundane vs non-mundane midpoints correctly.

I think in our original discussion, you talked about contacts to EP and Zenith (i.e. squares to Asc/Mc) as being mundane midpoints, same as PVL to angle or RA to EP-a, except that we count these in longitude. That would mean we should mark them with an M.
But wouldn't a conjunction to Zenith (for example) also be an ecliptical square to Ascendant, which is a non-mundane midpoint? Couldn't any contact to Zenith or EP be rephrased as a different relationship to As/Mc?

I feel like conjunction/opposition to Asc/Mc would be considered "non-mundane" (and seemingly nonexistent in practice) midpoints, but squares and octiles would have to be considered mundane midpoints, as they would have some relationship with Z/Ep.

How badly am I misunderstanding?

[Jim Eshelman]

I get the confusion. Sorry if my word choices made this more awkward.

Yes, midpoints to Zenith-Nadir are taken in longitude because contact with the angle is taken in longitude.

The confusion arose, I'm sure, because of my insistence to Mikestar13 that for ingresses only mundane midpoint contacts to angles are valid. I think, because of this, he probably hard-coded that rule somewhere for ingresses. Let's go back to the top:

In general, we should be able to test both ecliptical and mundane contacts of midpoints to angles. (Despite the research that has been done, the availability of TM lets us test this much more extensively.)

I'll discuss ingresses vs. natals separately because in many ways they behave separately. (Brief explanation of why I think this is so: The nature of ingresses in the world seems to be to narrowly select geographic areas, so close mundane contacts and angularity more generally seem to be "the whole ball game" for them.)

For ingresses, I literally have calculated and tracked many thousands of charts. In doing this, it became very clear that mundane contacts of midpoints with angles are terribly important. Since I haven't done a meticulous side-by-side check of these against ecliptical midpoint contacts, I can't say authoritatively that they don't exist in the ingresses, but in more casual looking I think they do not. We should still be able to test it, though.

In natals, its seems to go the other way. Based on the results from ingresses (and some theoretical modelling of how midpoints to angles probably work), for a while I expected that they would only work mundanely in natals as well. I now think I was wrong about that (a great theory that turned out to be wrong): With TMSA available, comparing ecliptical and mundane midpoint contacts to angles, I'm utterly unimpressed with the mundane contacts. From observing natal charts, I suspect mundane midpoint contacts to angles don't exist in natals. Nonetheless, we need to be able to test this and check for ourselves and keep drawing better conclusions.

I'm retracing all of this to make a couple of points. First, I think we really need to allow both categories for all charts (though we can set some "best practice" recommendations by what the default option file say). Second, based on best available information, with ingresses it's all about mundane contacts with angles, just as everything else with angles is "all about angles" etc.

So... here's where I haven't communicated clearly (probably because I haven't sorted things out with finality in my own head)... and here I only speak of ingresses at the moment...

Midpoint contacts with major angles are taken mundanely. Midpoint contacts with EP-a and WP-a are taken in RA. Midpoint contacts of Zenith-Nadir are taken in longitude.

I may indeed, at some point, of lumped the Z-N items with "mundane contacts" (by being lazy with language and meaning "the right way to take what are always mundane contacts with angles). But they are measured in longitude - and I now think that what serves best is to simply call them ecliptical contacts.

Part of my earlier hesitation is because I didn't want to authoritatively impose my view that midpoints are formed by circles of position and, therefore, all 0/180/90 contacts are direct. (TM has a user-selectable option on what to call "squares to midpoints.") But if we DO adopt this perspective, it simplifies the current question. - The crazy consideration is that midpoint contacts would LOOK like ecliptical aspects to MC/Asc were listed (to get Z, N, EP, WP, we take midpoints that would be conjunct, opposite, or square MC/Asc) and sorting THAT out probably overwhelmed my feeble brain. But if we enable it that way, the worst outcome (not a bad outcome, just the worst) is that the individual astrologer is given information and has to sort it out.

With ingresses, the downside is substantially resolved by the fact that midpoints would only be listed as to Z or N (or EP-WP) if the planets involved are on those angles; so we don't inadvertently get ecliptical midpoints to major angles that way. (These are handled with different rules for ingresses than natals.) For natals, the possible problems are mostly (entirely?) resolved because ecliptical contacts are the standard anyway.

I'm rambling / flow of consciousness here (in between getting things done at work); so, most likely, we'll have to have more Q&A on this. But maybe this gets it started.

I may have finally fixed midpoint weirdness. I'm fairly confident that I'm adding the midpoints using the correct logic (only count RA contacts if both points are in orb to EP-a/WP-a even if that's not their closest angularity, etc), and I am apparently calculating them correctly, but I'm not totally sure I'm marking mundane vs non-mundane midpoints correctly.

I think in our original discussion, you talked about contacts to EP and Zenith (i.e. squares to Asc/Mc) as being mundane midpoints, same as PVL to angle or RA to EP-a, except that we count these in longitude. That would mean we should mark them with an M. But wouldn't a conjunction to Zenith (for example) also be an ecliptical square to Ascendant, which is a non-mundane midpoint? Couldn't any contact to Zenith or EP be rephrased as a different relationship to As/Mc?

Agreed.

I feel like conjunction/opposition to Asc/Mc would be considered "non-mundane" (and seemingly nonexistent in practice) midpoints, but squares and octiles would have to be considered mundane midpoints, as they would have some relationship with Z/Ep.

We get could really picky here (I'm not sure we want to, but we could) depending on whether the user has defined 90° contacts to the half-sum as direct or indirect. If selected as direct (my own modelling), then 0/180/90 are all the same and they are all direct contacts to Z-N or EP-WP. OTOH, if the user says squares to the half-sum are indirect, then only the "squares to A or M" count as Z/N or EP/WP contacts for ingresses.

Or, we just list them all and let the astrologer sort them out, although ingresses have other filtering based on what planets are on what angles.

[Ember Nyx]

I mostly understand. I have some more questions:

Regarding Z/EP contacts in ingresses:

1. Let's say the longitude for Ascendant is 15° Aries. One planet is 15°15' Aries, another is 14°30' Aries (so the midpoint is 15' away, I think ). Is this a conjunction to whatever that uses uses the 0/180° orb, or a "square to Zenith" that uses the 90° orb?

2. Let's take that same example, and let's say those 2 planets aren't wacky TNOs and that they are actually angular in PVL. They are obviously not "foreground" on Zenith. Does this mean, in an ingress, their halfsum will never show up on the As line?
If this line of thinking is correct, then in ingresses, Zenith/Nadir/Ep/Wp contacts are seemingly only regarded as conjunctions (or oppositions, whatever), never squares - which has implications about which orbs are used.

I might have more, but that's what is coming to mind as i look at the code.

[Jim Eshelman]

Regarding Z/EP contacts in ingresses:

1. Let's say the longitude for Ascendant is 15° Aries. One planet is 15°15' Aries, another is 14°30' Aries (so the midpoint is 15' away, I think ). Is this a conjunction to whatever that uses uses the 0/180° orb, or a "square to Zenith" that uses the 90° orb?

This is an example in ecliptical midpoint contacts and you limited it to ingresses. That's already suspicious to me in practice except I did say we have to have both for comparison. So...

I'm puzzled by the question (come to think of it) because midpoint reports don't specify what aspect is being made. The answer to your question could be made different depending on what settings the person has picked.

For example, if the user selects "Is 90°?" to be Direct, they are using a model in which midpoints are formed between circles of position instead of points. In your example (tweaked 1' for convenience), A at 15°16' Aries is actually on a great circle defining 15°16' Libra-Aries. B at 14°30' Aries is really on a great circle defining 14°30' Libra-Aries. These four longitudes (14°30' Lib, 15°16' Lib, 14°30' Ari, and 15°16' Ari) have four direct midpoints at 14°53' Cancer, Libra, Capricorn, and Aries. It's a conjunction with both of them!

The real question, I think, is: How do we label these. Something I implied but forgot to say last time is that, if we're taking midpoints to angles in angles, then we need to include ecliptical contacts to Z/N/EP/WP even if ecliptical angles are turned off. That's probably why I confusingly called them 'mundane' previously because they have to be included (as ecliptical contacts to angles) even if mundane-only is enabled.

So I think the real question is how to display these on the Cosmic State / midpoint report. How does this sound>

• If ecliptical aspects are turned on, it is listed as a midpoint contact to Asc or MC and there are no separate lines for Z or EP.
• If ecliptical aspects are NOT turned on - only mundane aspects are enabled - we still need the Z/N/EP/WP contacts so the same things are listed as minor angle contacts.

2. Let's take that same example, and let's say those 2 planets aren't wacky TNOs and that they are actually angular in PVL. They are obviously not "foreground" on Zenith. Does this mean, in an ingress, their halfsum will never show up on the As line?

In a natal, if ecliptical aspects are turned on, any ecliptical conjunction of a midpoint to Asc or MC counts. If mundane aspects are turned on, any midpoint in PVL that hits any angle hits all the angles (hence listing it just as "Angle").

In an ingress, same thing except only planets somehow foreground / angular quality to be considered.

[Jim Eshelman]

After sleeping on it, I'm still not sure I've made it clear let alone simple. Part of this is that I've been rushed - no chance to sit an hour or two and compose a thoughtful answer, so I just blurt through it all. (And now, within the hour, we're hitting the road for the day.)

Three considerations rotate around each other, three binary options that beg for a pivot table:

1. Are squares to the half-sum treated as direct or indirect midpoints. (This masks the real mathematical question: Do we consider midpoints formed by points on the measuring circle halfway between two circles of position, which makes them direct midpoints; or between two isolated points, which makes them indirect.)
2. Are ecliptical midpoints enabled?
3. Is this a natal or an ingress?

Let's limit this to the one main question you asked: Are two planets straddling Ascendant treated as midpoint on Asc or midpoint on Zenith? (In the answers below, "Ascendant" might be any major angle and "Zenith" any linked minor angle.)

• Natal / Ecliptic Yes / Direct. The contact is always listed as Asc. No need to distinguish Zenith.
• Ingress / Ecliptic Yes / Direct. The contact is always listed as Asc. No need to distinguish Zenith. (In the example, both planets pass the foreground test.)
• Natal / Ecliptic Yes / Indirect. The contact is Asc. [The question here is whether Zenith should be assessed separately. I'm good either way. Historic Cosmobiology would ignore midpoints square Asc in this situation. I think we should probably do that because the alternative sets off a couple of more layers of code distinctions, though one could argue (in a perfect world) for the more complex code.]
• Ingress / Ecliptic Yes / Indirect. The contact is Asc.
• Natal / Ecliptic No / Direct. Possibly the most complicated scenario on the list since we have to guess at the user's intent. If only mundane midpoint contacts are allowed in a natal, is this just someone wanting mundoscope midpoints (since all planets are used in the natal), or are they trying to isolate all cases of midpoints hitting angles? On the principle of "in case of doubt, give the user too much rather than deprive them of information," I think we list this as a Zenith contact.
• Ingress / Ecliptic No / Direct. For an ingress, the explicit intent is to capture all cases of midpoints hitting angles, so, again, we list this as a Zenith contact.
• Natal / Ecliptic No / Indirect. The contact isn't listed.
• Ingress / Ecliptic No / Indirect. The contact isn't list.

One thing I got out of this exercise is clarifying that the practical outcome does NOT depend on whether we are looking at a natal. (The logic of why we do a thing may vary, but not what we actually do.) That means the table above can be simplified:

• Ecliptic Yes / Direct. The contact is always listed as Asc.
• Ecliptic Yes / Indirect. The contact is Asc.
• Ecliptic No / Direct. This is a Zenith contact.
• Ecliptic No / Indirect. The contact isn't listed.

I think that's right. Please question and critique. (I slammed this together in a frequently interrupted half hour.)

[Jim Eshelman]

I looked back at the version 1.0 target list and - apologies for being surprised - saw that you've almost covered everything. All that's really left on the original plan is the Novien table and a couple of minor text matters (and then the Mac and Linux builds you already said come next).

That you've essentially finished the original plan for 1.0 doesn't mean we can't add more (and it certainly doesn't mean we shouldn't look ahead to anticipate infrastructure needs). I wanted to float the question, though, of whether it's a good idea to add these extra things at this stage. There seems to me great merit in having a full release 1.0 that we can start evangelizing, spreading the word online, getting more people involved in a product we're willing to say is completely finished (while subject to expansion).

Since I wrote this, we've talked about a couple of other things that are needed.

And then... yesterday... I realized I hadn't mentioned one really important thing: parans. To be Fagan-complete, we need to be able to calculate parans in a given chart.

• It's a major topic through Fagan's writings in "Solunars" over the years.
• It's a big deal to Ken Bowser and those who have studied with him. The software will be a hard sell to them until this feature is included.
• We need to do our own research. I've put off looking at this more than intermittently for decades because we don't have an easy way to get them on demand. I know they're important in some contexts and we need to get a better handle on them by practical use.

At the moment, consistent with the 1.0 targets, I'm only talking about potential parans that exist with a given chart - just another category of aspects like ecliptical and mundane (PVL) aspects.

I am certain these are valid for a given location and are, therefore, important in relocation work. I don't know if birthplace potential parans permanently survive relocation.

I think I've written this up elsewhere. All I'm looking for now is a third category of aspect (like ecliptical and mundane) - only conjunctions, oppositions, and squares exist - user selectable like the current ones by leaving blank or adding orbs. On the Options page, their selection could go under the mundane aspects (there are three blank lines) with only a little rearrangement of labels. - To help that, I'm quite willing to get rid of the mundane octiles option (this was put in at a time we wanted to look and see if there was something usable in mundane octiles, and nothing has come of it.) - If selected, they would go in a chart's aspectarian equal to ecliptical and mundo, i.e., whichever of the three is closest "wins."

These would be marked by a capital "P." There is some stealth planning in this: First, parans probably should be ranked equal to eclipto and mundo aspects if selected. Second, technically PVP aspects are a type of paran, but nobody in the whole astrological universe thinks of them that way: Therefore, during experimentation with PVPs they are treated as "little" P aspects. Perhaps one day there will be no difference between P and p aspects, but that day won't come soon.

[Jim Eshelman]

Though I think that's obvious, an example wouldn't hurt. Your natal aspectarian using my default settings and ten standard planets is this:

Code: Select all

   Class 1 Aspects             Class 2 Aspects             Class 3 Aspects    
Mo sq Ju  2° 4'  92% M      Mo sq Ur  3°44'  73% M      Mo sq Me  7°15'   6%  
Mo sq Sa  2°35'  87%        Su co Ur  5°42'  65% M      Mo tr Ve  6°37'  20%  
Mo sq Ne  0° 8' 100%        Me oc Ma  1°57'  56%        Su op Ju  7°22'  43% M
Me co Sa  3°43'  85% M      Me co Ne  6° 9'  60% M      Su oc Pl  2°31'  28%  
Me sx Pl  2°14'  90%        Ve sx Ma  3° 5'  82%        Ma oc Sa  2°43'  17%  
Ju op Ur  1°35'  97%        Ju op Ne  4°55'  74%        Ju op Sa  7°27'  42% M
Sa co Ne  2°26'  94% M      Ur co Ne  6°30'  55%        Sa co Ur  9° 7'  16% M
Sa sx Pl  2°26'  89%                                    Ne sx Pl  5° 9'  51%

Suppose I decide to define, for natal charts, paran orbs for Class 1 only and use the same orbs I use for other Class 1 aspects. (I think that's much too large, but let's suppose someone is really into these and thinks they're the same as any other natal aspect. In your chart, for birthplace, I get the following potential parans within these orbs:

Code: Select all

Moon-Sun sq 2°34'
Moon-Saturn sq 1°04'
Mercury-Saturn co 3°37'
Jupiter-Uranus op 1°10'
Saturn-Neptune co 2°41'

This doesn't require many changes in your aspectarian, but it requires some. You gain a Moon-Sun square. Your Moon-Saturn moves significantly closer (I know you've always wanted that <g>); but so does Jupiter-Uranus. Your Mercury-Saturn moves a tiny bit closer. Almost half your Class 1 aspects are now parans in this slightly different picture:

Code: Select all

   Class 1 Aspects             Class 2 Aspects             Class 3 Aspects    
Mo sq Su  2°34'  xx% P      Mo sq Ur  3°44'  73% M      Mo sq Me  7°15'   6%  
Mo sq Ju  2° 4'  92% M      Su co Ur  5°42'  65% M      Mo tr Ve  6°37'  20%  
Mo sq Sa  1°04'  xx% P      Me oc Ma  1°57'  56%        Su op Ju  7°22'  43% M
Mo sq Ne  0° 8' 100%        Me co Ne  6° 9'  60% M      Su oc Pl  2°31'  28%  
Me co Sa  3°37'  xx% P      Ve sx Ma  3° 5'  82%        Ma oc Sa  2°43'  17%  
Me sx Pl  2°14'  90%        Ju op Ne  4°55'  74%        Ju op Sa  7°27'  42% M
Ju op Ur  1°10'  xx% P      Ur co Ne  6°30'  55%        Sa co Ur  9° 7'  16% M
Sa co Ne  2°26'  94% M                                  Ne sx Pl  5° 9'  51%  
Sa sx Pl  2°26'  89%        

[Jim Eshelman]

Out of fairness, here is my chart as an example, too. I'm afraid it doesn't make me look very nice (and these were consistent with my experiences at birth location). I would like to think that, like other examples I've seen, these faded in the years after I settled in California. Here is my standard aspectarian:

Code: Select all

   Class 1 Aspects             Class 2 Aspects             Class 3 Aspects    
Mo sx Ma  1°31'  95%        Mo tr Ve  4°29'  62%        Mo tr Ju  6°13'  29%  
Me co Sa  2°24'  94%        Mo sq Pl  1°57'  56% p      Mo oc Sa  2°33'  26%  
Ve sx Ma  2°57'  83%        Ma op Ju  4°41'  76%        Mo tr Ur  5°56'  35%  
Ve tr Ju  1°44'  94%        Ma op Ur  4°25'  79%        Su sq Ma  6°28'  24%  
Ve tr Ur  1°27'  96%                                    Su co Ne  8°14'  30% M
Ve sq Pl  0°13' 100%                                                          
Ma sq Ne  0° 7' 100% M                                                        
Ju co Ur  0°17' 100%                                                          
Ju sq Ne  2°16'  90%                                                          
Ur sq Ne  2° 0'  92%                                                          
Ne sx Pl  0°46'  99%

Adding my Class 1 orbs for potential parans, I get the following additional aspects (a lot!):

Code: Select all

Moon op Pluto 3°19' P
Mercury co Saturn 0°38' P
Venus sq Mars 2°56' P
Venus sq Jupiter 1°31' P
Venus co Saturn 2°57' P
Venus sq Uranus 1°18' P
Mars op Jupiter 0°37' P
Mars sq Saturn 0°53' P
Mars op Uranus 1°49' P
Jupiter co Uranus 0°12' P
Jupiter sq Neptune 1°40' P
Uranus sq Neptune 1°53' P

All twelve of these are either new or closer orb than the ones in the first aspectarian. They substantially reshape the natal aspectarian into the following:

Code: Select all

   Class 1 Aspects             Class 2 Aspects             Class 3 Aspects    
Mo sx Ma  1°31'  95%        Mo tr Ve  4°29'  62%        Mo tr Ju  6°13'  29%  
Mo op Pl  3°19'  xx% P                                  Mo oc Sa  2°33'  26%  
Me co Sa  0°38'  xx% P                                  Mo tr Ur  5°56'  35%  
Ve sq Ma  2°56'  xx% P                                  Su sq Ma  6°28'  24%  
Ve sq Ju  1°31'  xx% P                                  Su co Ne  8°14'  30% M
Ve co Sa  2°57'  xx% P                                  
Ve sq Ur  1°18'  xx% P                                  
Ve sq Pl  0°13' 100%                                                          
Ma op Ju  0°37'  xx% P
Ma op Ur  1°49'  xx% P
Ma sq Ne  0° 7' 100% M                                                        
Ju co Ur  0°12' 100% P                                                        
Ju sq Ne  1°40'  xx% P                                                        
Ur sq Ne  1°53'  xx% P                                                        
Ne sx Pl  0°46'  99%

In contrast, the natal parans for Los Angeles are quite different:

Code: Select all

Moon op Pluto 1°40' P
Sun sq Jupiter 0°17' P
Sun sq Uranus 0°49' P
Mercury sq Mars 0°18' P
Mercury co Saturn 0°38' P
Mars op Jupiter 1°34' P
Mars op Uranus 1°40' P
Jupiter sq Saturn 1°03' P
Jupiter co Uranus 0°13' P
Jupiter sq Neptune 0°02' P
Saturn sq Uranus 0°50' P
Uranus sq Neptune 0°15' P

Applying this to my LA aspectarian (which has different mundane aspects that the birthplace one), I get the following alternate reality:

Code: Select all

   Class 1 Aspects             Class 2 Aspects             Class 3 Aspects    
Mo sx Ma  1°31'  95%        Mo tr Ve  4°29'  62%        Mo tr Ju  6°13'  29%  
Mo op Pl  1°40'  xx% P      Su sq Ma  4°47'  57% M      Mo oc Sa  2°33'  26%  
Su sq Ju  0°17'  xx% P                                  Mo tr Ur  5°56'  35%  
Su sq Ur  0°49'  xx% P                                  Su co Ne  8°53'  20%  
Me sq Ma  0°18'  xx% P
Me co Sa  0°38'  xx% P      
Ve sx Ma  2°57'  83%        
Ve tr Ju  1°44'  94%        
Ve tr Ur  1°27'  96%                                                          
Ve sq Pl  0°13' 100%                                                          
Ma op Ju  1°34'  xx% P      
Ma op Ur  1°40'  xx% P      
Ma sq Ne  2°25'  89%                                                          
Ju sq Sa  1°03'  xx% P
Ju co Ur  0°13' 100% P                                                         
Ju sq Ne  0°02' 100% P                                                        
Sa sq Ur  0°50'  xx% P
Ur sq Ne  0°11' 100% M                                                        
Ne sx Pl  0°46'  99%

[Ember Nyx]

I see why we need to prioritize this for a real 1.0 release. I'll make sure it's on my roadmap. I think you have calculations/logic in another thread, but I'll get to that once I get to that.

I'm still digesting your midpoint explanations. As an astrologer, they make sense and are intuitive. As a programmer, pieces are still settling for me, and I feel like we're going to end up with logic corrections to my code no matter what - so I'm contemplating how to make that easy and also clear in the code.

(From a technical standpoint - I think I need to extract the code that handles midpoints, and just calculate all 45° aspects to all halfsums in longitude, PVL, and RA. Being purely numerical computation, this will be so fast as to not matter to any user. And then, in the main flow of the code, deal with "what's allowed to be displayed" based on angularity rules, etc. I think aspects in general should kind of work the same way, eventually. They already half do, but I should commit to this model.

Thankfully, my rewrite of the angularity code means that we already have access to all the axes on which a planet is foreground, not just the one with the closest orb. That underlies PVP aspect parsing working correctly, as planets can be on Vx and some other foreground zone simultaneously.)

[Jim Eshelman]

(From a technical standpoint - I think I need to extract the code that handles midpoints, and just calculate all 45° aspects to all halfsums in longitude, PVL, and RA. Being purely numerical computation, this will be so fast as to not matter to any user. And then, in the main flow of the code, deal with "what's allowed to be displayed" based on angularity rules, etc. I think aspects in general should kind of work the same way, eventually. They already half do, but I should commit to this model.

I see how this could make things a LOT easier. My brain immediately slid toward ways to simplify it - like decide which kinds of aspects are authorized (e.g., calculate no parans if no parans are allowed); OTOH always doing a thing the same way every time leaves fewer cracks for bugs. (Exceptions are harder to debug even if you document the hell out of the code.)

On a totally unrelated and useless vein, I'm sure I never told you how I wrote my first aspect-finding code (in some variation of BASIC; probably CBASIC). Its weakness is that it had no orb flexibility and no partial degrees for orbs. - The gist is that I created a 180-character string with an ASCII character defining an aspect in each spot. (I'd have to look back at the ASCII table to reinvent how I did it, but they were all printable, so > 33.) Absolute value of the difference between two longitudes, truncate, use the number to know which 0-to-179 character to pull from the string, and that told me what the aspect was.

[Ember Nyx]

(From a technical standpoint - I think I need to extract the code that handles midpoints, and just calculate all 45° aspects to all halfsums in longitude, PVL, and RA. Being purely numerical computation, this will be so fast as to not matter to any user. And then, in the main flow of the code, deal with "what's allowed to be displayed" based on angularity rules, etc. I think aspects in general should kind of work the same way, eventually. They already half do, but I should commit to this model.

I see how this could make things a LOT easier. My brain immediately slid toward ways to simplify it - like decide which kinds of aspects are authorized (e.g., calculate no parans if no parans are allowed); OTOH always doing a thing the same way every time leaves fewer cracks for bugs. (Exceptions are harder to debug even if you document the hell out of the code.)

Exactly. Many of the difficulties in rewiring things in Time Matters are due to the fact that, even in my refactor, several things still get calculated at the point that they're used and not done globally. I think this can be done better, and it would be closer to how we as humans think of them anyway. (They'll cost a few extra milliseconds.)

On a totally unrelated and useless vein, I'm sure I never told you how I wrote my first aspect-finding code (in some variation of BASIC; probably CBASIC). Its weakness is that it had no orb flexibility and no partial degrees for orbs. - The gist is that I created a 180-character string with an ASCII character defining an aspect in each spot. (I'd have to look back at the ASCII table to reinvent how I did it, but they were all printable, so > 33.) Absolute value of the difference between two longitudes, truncate, use the number to know which 0-to-179 character to pull from the string, and that told me what the aspect was.

That's pretty clever actually. I've run into several similar examples at various jobs of using array index to encode values, usually as prefixes or suffixes for some identifier, like majorID-minorID-encodedOptions-somethingElse. This is pretty commonly done with cloud-based resources, to cram extra information into the name of something without needing any extra space to store that info.

[Jim Eshelman]

I think this is a bug. I might be missing something, though.

Madonna was born August 16, 1958, 7:05 am EST, Bay City, MI.

She has Pluto (7°33') within 3° of square MC (9°35'). However, while I have my minor angles set at 3° orbs, I can't justify squares to MC at more than 2°. No big deal... I just temporarily off minor angles and see what the Ang value is without it.

Except... in her case it doesn't change. Pluto at PVL 349°07' is 10°53' past Ascendant and should have a strength just under 75%. However, whether minor angles are enabled or not, Pluto's strength remains at 87%. This happens with all three angularity models. It even happens if I put back minor angle orbs but with 2° as the Class 3 boundary.

Since (on a minor angle curve with a 3° outer bound), 87.5% is the value at 2°00', and this is just past 2°00', it seems to be using the minor angle strength value even when minor angles are disabled.

[Ember Nyx]

You know what's funny? I think I ran into this a day or two ago, but it was only off by a little bit, so I thought I was crazy...

I made a Trello ticket for this and will check it out soon.

[Jim Eshelman]

As expected, this applies equally to all minor angles. I think the Ang value is calculated before a final determination of what's angular.

Marion has a lot of minor angle contacts, so is always a good test case. Look at the unusual Mars, Uranus, and Haumea entries below with minor angles turned off (blank):

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mo 15Le59' 2"  3N53 +12 20' 163 14' 11N20 320 35' -29  5' 203 15' 138 47'  22%  b
Su 14Ta 1'27"  0N 0 +57'32"  66 30' 21N41  55 39' - 5  3' 182 51'   6  7'  92% A 
Me 27Ar30'46"S 3S35 - 1'49"  50 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 
Ve 19Ar28' 4"  1S31 + 1 13'  41 42' 14N30  77  2' + 7 12' 178 23' 352 37'  86% A 
Ma  3Le51' 0"  1N25 +29'21" 150 45' 13N28 334 30' -32 13' 209 38' 124 20'  96%   
Ju 17Pi58' 6"  1S11 +10'59"  11 40'  3N44 105 29' +22 48'   6 24' 336 26'  10%  b
Sa 28Cp52'23"  1S 3 + 0'24" 325 48' 14S49 160 24' +32 24'  30 52' 297 52'  50%   
Ur  7Le 7' 9"  0N46 + 1' 7" 153 39' 11N42 330 37' -32 52' 209 22' 127 13'  85%   
Ne 19Li25'23"  1N50 - 1'27" 221 45' 14S12 257 15' - 6 57' 358 27' 172 52'  87% D 
Pl 15Le19'57" 13N36 + 0'16" 166 33' 20N32 322 30' -19 30' 195 42' 149 48'   0%  b
Ha  7Le26'13" 15N35 + 0'16" 159 46' 25N22 330 42' -18  2' 195 51' 146 23'  81%  b
Er 16Pi42'44" 22S 7 + 0'24"  18 53' 16S 0 115  1' + 3 57'   1 41' 355 38'  95% A

Mick Jagger is another great test case, with an abundance of foreground planets including minor angles. He was born July 26, 1943, 2:30 AM BDST, Dartford, UK. Don't miss his Venus and Mars entries in particular (again with minor angles blanked out):

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mo  0Ta 1' 0"  5S14 +12 36'  52 55' 13N42  71 54' + 3 11' 179  1' 356 39'  97% A 
Su  8Cn13' 2"  0S 0 +57'20" 124 26' 19N41   6  5' -18 40' 198 34'  72 35'  37%   
Me 16Cn57'39"  1N47 + 1 58' 133 53' 19N13 356 40' -19 17' 199 15'  99 25'  83% I 
Ve 19Le37'11"  1S45 +36'25" 164 11'  4N51 321 48' -26 48' 201 39' 140 45'  99%  b
Ma 18Ar15'29"  1S48 +39'24"  40 20' 13N47  81 28' +10 53' 178 22' 349  0' 100%   
Ju 11Cn32' 7"  0N29 +13'16" 127 58' 19N22   2 35' -19  9' 199  8'  82 37'  86% I 
Sa 28Ta 0'44"  1S20 + 6'35"  81 20' 21N52  44 51' - 4 58' 183 31'   7  1'  90% A 
Ur 13Ta50'34"  0S 7 + 2'22"  66  2' 21N30  57 12' + 2  8' 178 51' 357 28'  98% A 
Ne  5Vi51'40"  1N21 + 1'22" 180 22'  1N18 304 11' -22 36' 193 10' 153 17'   3%  b
Pl 12Cn45' 4"  5N 6 + 1'44" 130 29' 23N32   0  4' -15  1' 195  1'  89 46' 100% I 
Ha 20Cn57'39"  7N15 + 1'18" 139 41' 23N17 351 20' -14 50' 194 40' 119 38'  50%   
Er 11Pi55'46" 25S50 - 0'15"  16  4' 21S17 121 55' - 2 28' 358 42'   2 55'  98% A 

[Ember Nyx]

Thanks for giving these examples; I'll hopefully be able to fix this one relatively soon. I'm deep in midpoint logic land at the moment.

I think I've wrapped my head around what you wrote above, and I don't think I have any questions on that specifically. I do have a separate question, though: if mundane midpoints are enabled, do we allow planet = planet/planet midpoints in PVL/RA? What about planet = planet/angle in PVL? (I assume not in RA, that seems a bit ridiculous)

Or do "mundane midpoints" only allow angles to be at the center of planet/planet halfsums?

[Jim Eshelman]

My opinion (coming from trying to control the eventual chaos a bit) is that we only enable angle = planet/planet mundane midpoint. In a practical sense, if nobody ever asks for it to be expanded, there's no reason to do the extra work.

[Jim Eshelman]

Fantasy project... No reason (on my behalf) to plan this... but fantasizing...

I can see some decade the community needs to investigate whether mundoscopes alone, with no relation to an ecliptical chart, provide a fully working model. If so, then thst chart, of course, should have full PVL midpoint (and not ecliptical ones).

[Ember Nyx]

I realized something else that I don't think we talked about: polywheel midpoints.

My code theoretically handles these inter-chart midpoints just fine. I feel like return chart midpoint logic should probably follow ingress midpoint logic, using the same rules, with the exception that we probably don't care about return angle = planet/other chart angle.

What do you think?

[Ember Nyx]

Let me add another post onto this. Since I extracted out the midpoint logic, I think it'll be much easier to test, which means we get value from having explicit test cases that encode what we think the expected behavior is.

Here are some comments I left for myself in the (to-be-rewritten) display logic.
This assumes that we're either in an ingress, or a polywheel (and polywheels use ingress logic).

Can you let me know if any of these are wrong?

# If the point is a foreground planet, and both other points are foreground planets: write it (i.e. the midpoint)

This is probably the one I am most uncertain about
# If the point is a foreground planet, and one other point is a foreground planet, and the other point is some inner chart angle (like radix Ascendant): don't write it?

# If the point is a major angle, and both planets are foreground somehow, and the halfsum uses PVL: write it
# If the point is EP-a, and both planets are foreground in RA, and the halfsum uses RA: write it
# If the point is Z or EP:
# If ecliptic midpoints are enabled, list As or MC
# If ecliptic midpoints are disabled, and squares are direct, list as Zenith/EP
# If ecliptic midpoints are disabled, and squares are indirect, don't write it