WISH LIST - Parans and PVP aspects

[Jim Eshelman]

I'm putting these in the same thread because they are related, but I'll discuss their development separately. Although we'd like to have these ASAP, they don't qualify for the Priority Wish List except PVP aspects should be on the "we're headed toward 1.0" priority list if they're as easy as I think they will be.

It is increasingly unfortunate TM doesn't have parans as an aspect category. We should be testing them more aggressively and getting some real experience with their reliability which I consider unconfirmed (from too little work). Nonetheless, they require some significant additional development (aside from the Chart Options page expansions) so we may have to be patient anyway.

I'm particularly aware that Ken Bowser, who swears by parans, works on a Mac (and sometimes on his wife's Windows computer) and I'd really like him to take an interest in TM - but there's no reason to think that he will if it doesn't show parans. Once the program is ported to a Mac I'd like to nudge him harder to take a serious look at the program, but I also don't see any reason to push it out to a Mac until the main work on remodeling the program is finished (hoping that the Mac version will be some variations of putting the same code in a different wrapper and through a different compiler).

Anyway... just because we have to wait is no reason for me not to get the development notes ion place so they are ready.

[Jim Eshelman]

In the long run, these may simply be regarded as a type of paran and not need a separate name. For now, though - the idea being so new and unfamiliar - I think we're better off with a separate name.

Please understand that PVPs are ACTIVE parans. That is, they exist in present time in the chart we are examining. I define a paran (meaning an active, or fully present, paran) as having two characteristics:

1. Two planets are on an angle (using that term loosely) at the same time.
2. They form a hard aspect with each other.

Parans as we have known them, therefore, are a special case of mundoscope aspects. We are accustomed to these being formed involving planets on the HORIZON and/or MERIDIAN. They can be a paran-conjunction if on the same angle; a paran-opposition if on the same axis; or a paran-square if one is on the horizon and the other on the meridian.

What we have not done (until I discovered it with Sidereal solar and lunar ingresses) is measure them in a way that includes the prime vertical. Since the horizon, meridian, and prime vertical form three interlocking great circles - each precisely 90° from both the others - with these three defining the entire mundane framework, it makes logical sense (and seems confirmed with ingresses in practice) that

• Just as parans-as-we-know-them are formed by two planets both mundanely on the horizon and/or meridian and a hard aspect between them in a mundane framework...
• ...this probably is expandable to: two planets both mundanely on the horizon, meridian, and/or prime vertical and a hard aspect between them in a mundane framework.

To understand what follows, it is probably also useful to know that aspects between any two of these three great circles are measured along the third. For example, we are already accustomed to measuring mundane aspects between a planet on the horizon and one on the meridian in the prime vertical - the third circle. Similarly, an aspect between a planet on the meridian and one on the PV is measured along the horizon (in azimuth). An aspect between a planet on the horizon and one on the PV is measured along the meridian (in ML).

Another caveat: The current working definition of PVPs is intentionally conservative. I might be leaving out perfectly valid aspects. (This is seeming to be true now that we have ML on TM charts - especially if no planets are really closely angular, the somewhat wider ones seem willing to show in valid PVP aspects. This is a first impression only.) If some definitions below seem excessively narrow, they surely are: I think this is appropriate for a stage where we are first confirming that these exist, both because closer aspects with closer angularities are known to show more truly and purely, and because there are potentially so many PVP aspects.

[Jim Eshelman]

For the purposes of PVP aspects, "on the prime vertical" means within a minor angle's orb (usually taken as 3°, but user selectable) of azimuth 90° or 270°; i.e., within a narrow orb (essentially the same as a Class 1 major angle orb) of being mundanely on the Vertex or Antivertex.

Historically - and I think we should do it now for testing purposes - I have put the same restriction on the horizon and meridian planets. In researching thus far, I have only considered a planet within 3° of horizon or meridian in PVL. This could be user-adjusted a little by defining it not as 3° but as whatever they have set for Class 1 major angle contact, just as the Vx/Av contact is measured by a minor angle's Class 3 orb. (These will usually be the same, especially if someone is using the defaults - as pretty much everybody does. They need not be.)

I vote for this narrowness initially, which also makes dev easier. Later, when we know what we have greater certainty, user options can be added and this will seem a natural development step in the software.

Interpret what follows as (by definition) involving only:

1. Planets within a Class 3 minor angle orb of 90° or 270° azimuth and
2. Planets within a Class 1 major angle orb of horizon or meridian in PVL

We also will need orbs for these aspects. Initially, until it gets its own options page:

1. Use the user's defined Class 1 mundane aspect orb.
2. If none is set, use the defined Class 1 ecliptical aspect orb.
3. if none is set, use 3°.

The rest is easy!

User Option
Chart Options should have a user toggle to turn these on/off. Initially, this is probably the only new user option we need.

PVP conjunctions
If two qualified planets have no ecliptical or mundane (mundoscope) aspect AND are within orb of a conjunction in azimuth, they have a PVP conjunction.

PVP opposition
If two qualified planets have no ecliptical or mundane aspect AND are within orb of an opposition in azimuth, they have a PVP opposition.

PVP square (meridian-to-PV)
If two qualified planets have no previously mentioned aspect AND are within orb of a square in azimuth, they have a PVP square.

PVP square (horizon-to-PV
If two qualified planets have no previously mentioned aspect AND are within orb of a conjunction or opposition in Meridian Longitude, they have a PVP square.

Aspectarian display
Collate this with all other aspects in the same way. After the score (where PVL aspects have an M), place a lower-case p.

If turned on, these should exist in natals and ingresses, and with the usual aspect mix in returns (transit-to-transit, transit-to-natal, natal-to-natal).

Default is turned off.

[Jim Eshelman]

Active parans are the only parans Cyril Fagan originally considered. However, today, what most astrologers using parans call "parans" are something else. In the 1970s, in Interpreting Solar Returns, I thought it necessary to distinguish these by calling the firsts active parans and the second potential (or latent) parans.

Active parans require that two planets be simultaneously on an angle (meaning initially only the horizon and meridian) AND have a hard aspect in a relevant mundane framework.

Potential (or latent) parans have the same requirements EXCEPT they don't require that the planets meet those conditions right now - at the moment of the chart being examined. Instead, potential parans allow that there is some sidereal time in any given 24 hours where these conditions will be met.

For example, I was born with both Mars and Saturn were far from angles. They obviously weren't in paran. However, at my birth latitude, some time every day my Mars would cross Midheaven at the same time my Saturn crossed Descendant. For several minutes every day, they formed an active paran. The potential for this was always in my birth chart - the aspect existed only in an abstract way and was latent, ready to rotate to the angles once a day and, bam!, become an aspect.

Similarly, in Los Angeles, every day my Sun crosses IC at the same time my Jupiter-Uranus rises. I don't have that Mars-Saturn square anymore, but I now have a Sun square Jupiter-Uranus - at least for a few minutes every day.

These potential or latent parans are what need to be added to TM when possible.

[Jim Eshelman]

Two user settings are required. First, a box to turn this type of aspect on or off. Second, an orb setting: There are wide opinions about the orbs and people should be allowed considerable flexibility. Three divergent theories, for example, are:

• Use a 1° orb.
• For each to be on an angle - especially something like a quotidian angle - at the same time, the most extreme variation is 1° either side, or a 2° orb.
• Parans are just other aspects, so give them the same orbs you give any other aspect or, at least, any other hard aspect.

The easiest solution is just to allow users to set C1/C2/C3 orbs. It would be nice to have a convenient on/off toggle so these could remain set.

When they are turned on, these should be collated with all other aspects and a capital P put after the entry. My thought is that, not only is P intuitive for "paran," but the capital P for parans and lower case p for PVP aspects shows that they are essentially the same kind of aspect AND gives suggests a lower trust level.

There is a kind of hierarchy of aspect types. This can be expanded, perhaps, by trusting that people who are really interested in parans probably aren't as interested in mundoscope aspects (an assumption built into the recommendations below). Right now, the priority in TM is: Look at both ecliptical and mundane aspects. If both exist for the same planet pair, use the closer orb.

This probably should be continued in parans: Of all three, the closest orb wins. It should not be extended to PVP aspects, for which the rule should be not to list them if any aspect exists between the same planets in any other enabled aspect type.

Default should be turned off.

[Jim Eshelman]

I will describe how I would do this task by hand. There may be an easier way: In fact, the SE may have this function already enabled (and certainly has some of the steps along the way automated). If I write it out the long, hard way we'd do it by hand, we can always adjust toward simpler

Build a Speculum
A speculum (in the current sense) is a table containing four items for each planet: The sidereal time/RAMC (most conveniently expressed as degrees rather than time) when the planet is on Asc, MC, Dsc, and IC.

Combine all of these items into a single sorted list. For ten planets (for example), it would have 40 items.

NOTE: Depending on the procedure eventually selectable, most of this process will be basic to the eventual Astro-Mapping report, which also will require building a table of these four crossings for each planet - used differently - plus a separate process to get minor angle contacts (which will use the same subroutines slightly differently). ---- I should probably detail that slightly more: To get EP-a/WP-a angle crossings, at 270° and 90°, respectively, to the RAMC for crossing MC. To get Zenith/Nadir crossings, add 90° and 270° to the planet's longitude, define latitude 0°, then calculate the Asc crossing for each of the two points. To get EP/WP (in longitude) crossings, add 270° and 90°, respectively, to the planet's longitude, define latitude 0°, then calculate the MC crossing for each of them. - None of that is needed for the current paran task, though.

Find Parans
Find all planet combinations that 'conjoin' each other in the list within the selected orb (not missing the obvious wrap-around at 360° to 0° of course, which for some reason I felt compelled to say this time).

That's it! You're done! You have your paran list.

[Mike V]

I'm putting these in the same thread because they are related, but I'll discuss their development separately. Although we'd like to have these ASAP, they don't qualify for the Priority Wish List except PVP aspects should be on the "we're headed toward 1.0" priority list if they're as easy as I think they will be.

I'd like to have them sooner rather than later also. I think they're of moderate difficulty: The logic itself is relatively straightforward, but it needs to run in a very complicated place in the code that I am trying to clean up. I want to clean that up first because otherwise I don't think I'll have a great deal of confidence that adding this won't break something else unexpectedly - planets mysteriously getting treated as foreground (or not), etc. More on that below...

I'm particularly aware that Ken Bowser, who swears by parans, works on a Mac (and sometimes on his wife's Windows computer) and I'd really like him to take an interest in TM - but there's no reason to think that he will if it doesn't show parans. Once the program is ported to a Mac I'd like to nudge him harder to take a serious look at the program, but I also don't see any reason to push it out to a Mac until the main work on remodeling the program is finished...

Here's a sneak peak behind the dev curtain...

I have a branch for the 0.6.0 alpha that I'm working in. (Bugfixes for 0.5 happen separately and get merged in once stable.) On that branch, I'm working on a number of things that I want to squeeze into that release. The big actual wishlist item is adding angles to the data table - which seems easy enough.

Alongside that item, I'm trying to get as much heavy, risky, disruptive dev work done at the same time as possible - get it all out of the way early. I'm refactoring the internal data structures that are being used to represent all of these concepts - chart objects, bundles of calculated planetary data, etc. My intention is that it'll be significantly easier to reason about these things, and add onto them, after that.

To make that refactoring less buggy, I've started writing unit tests. These are basically hardcoded sets of planetary data - natals, solunar returns - so that I can test how they get evaluated and written to a chart file. If I accidentally break mundane aspects in lunar returns, for example, these tests should alert me that something that should not have changed got changed; I should be able to catch more bugs before releases rather than after.

Now for the fun part. I currently have semi-working Linux and MacOS ports. (I'm currently working on TM on my Linux partition.)

...(hoping that the Mac version will be some variations of putting the same code in a different wrapper and through a different compiler).

Kind of yes, kind of no.

The very last part that happens (and will need to happen any time I make a release) is I need to run cx_freeze to build an installer on the OS that it will be used on - I have access to Windows, Linux, x86-64 Mac, and ARM Mac (M1), so I can do this myself, though it takes some time.

Working backwards from that - there are a number of system things I have needed to work out so that the actual Time Matters program runs correctly on the Unix-like OSes. For example, I had to move heaven and earth to get fonts to work correctly on Linux, for reasons that boil down to "Time Matters creates a GUI using Tkinter, a Tk/Tcl wrapper, which is old and limited." I've contemplated updating that but that is a really foundational change that I'm not sure is worth doing anytime soon. (On the flip side, it could make Time Matters look much sleeker and fancier.)

Each of these OS-related considerations has had an impact on how I'm refactoring the core application code. Different things need to run at startup, when opening a chart, etc depending on the OS we're on. I believe I'm mostly done with that part. I'm currently working on actually bundling the code for distribution, ironing out permissions for directories where charts live, etc. Naturally, that is completely different on each OS, so I have to test it on each OS in turn.

But we're getting there.

[Jim Eshelman]

This is all very cool.

FWIW, as I was reading it, about half a dozen times the silly, simple idea came back into my head to add a line in the .dat files specifying the version under which the chart was last calculated. I know Mikestar was (understandably) concerned about thinking way down the road, getting data structures exactly right, not screwing up how it would be for users in the future, wanting everything always to be backwards compatible - all things that he, of course, really should have been sweating about. However, I think the way he was going about it paralyzed him a bit - never sure it was right enough to move forward.

While still trying to get it all right the first time, one shouldn't cut the brake lines before heading out on the road. Adding that version number at the top of the .dat file means you can always change .dat file structures any time you need to - and always easily flag the user when they bring up an old chart. ("If it isn't at least 0.7.0, recalculate it.")

[Mike V]

I agree, and I was pondering this same idea of backwards compatibility plus converting between formats. It is definitely doable.

[Jim Eshelman]

Data entry is stable. The files already have all the data any chart would ever need, so any later data file format can be obtained by recalculating what's already on hand.