A small progress update

[Mike V]

I've been working at this large refactor of core logic for a little while now. As of last night, I have the 0.6.0 alpha calculating natals correctly, which is a big win and which involved a lot of hair-pulling.

There are some other things that exist in that alpha.

Filed under "I did it because it's coming up on the list of important things"

• Big refactor, obviously. Return charts are next.
• Fully-functional but not fully-packaged Linux and MacOS (x86-64) ports

Filed under "I did it because I was there and it was quick"

• Code for PVP aspects (fully written, but untested and not enabled)
• Ephemeris files for all the TNOs and extra bodies that we discussed, and code that allows for them, although there are no options yet to enable them

Planned to be added relatively soon:

• Adding angles to data table (the refactor is making this a lot easier to wire up)
• Zips stored on Github so that the download links are essentially permanent (and less dodgy than "here is a random download link"
• Fix natal aspects showing up in return charts as if they're news to anyone

The next 2 weeks are super busy for me at work, so I probably won't get to move the needle that much, but this is where we are at currently.

[Veronica]

That doesnt seem like small progress at all to me, it seems like you made quite a bit of progress!
I'm very grateful and appreciate all your doing on the program and on the forum Mike, Thank you very much.

[Jim Eshelman]

This sounds like a lot of progress! Thanks for ALL you're doing. I know the basic code cleanup is fundamental to the future of the program. The Mac and Linux ports could eventually significantly expand the scope of who uses the program.

Code for PVP aspects (fully written, but untested and not enabled)

Since we've had ML to play with, I've been able to reconsider the 'working definitions.' Don't worry, where it's leading me will basically change one number (i.e., which variable is used - I'll write that in the PVP thread. Havin this option to toggle on and shake out will be the next level of ease. (Having ML made all this work realistically possible - and is already giving us chances to look at things I wouldn't have struggled to check previously. But while that made it possible at all, an option to add the aspects themselves will make it easier and, for many people, realistically possible to use them.)

NOTE: I can't find the thread where we've discussed this. Do you know where it is? (Maybe I need to write a new clean statement in the Wish List sub-forum.)

[*]Adding angles to data table (the refactor is making this a lot easier to wire up)

It hadn't occurred to me that this one wouldn't have been trivial, though it always made sense that code cleanup would make it even easier. For long-term development / expansion, especially in the transit, quotidian, and synastry modules, making this easy leads to a lot more being easy.

I'm guessing adding the option for displaying angular contacts as aspects will be mostly adjusting an array or two after that?

Zips stored on Github so that the download links are essentially permanent (and less dodgy than "here is a random download link"

Important to long-term distribution in a wider circle than this site and generally making it easier for everybody - and available for others to develop further.

This is all exciting!

[Mike V]

Some more small updates...

Uniwheel code has been heavily refactored and is passing unit tests, which is great. I would feel about 95% confident releasing that as-is, but I don't think there's a need to do that. (And no one would be able to tell without looking at the source code anyway ) (Midpoints not included; more on that in a minute.)

The Biwheel+ refactored code has been fully written and I'm in the process of getting it to pass unit tests.
I say "Biwheel+" because, theoretically, this should support Triwheels and more. One core Chart class now underlies everything else; Uniwheels, Biwheels, and so on just subclass it and define a little bit of logic for writing the "middle of the chart" info, but all the rest is handled by the base class for any number of charts. There's probably more code infrastructure needed to fully get that working for something like KLRs, but, for example, aspect calculations don't care how many charts there are; it goes through all the combinations and figures out what the aspects and planetary prefixes should be; same for the information tables, cosmic state, etc.

Aspect calculation includes PVP aspects, although I haven't thoroughly tested that logic yet. I also need to add options for it to the UI, although the underlying options classes have fields for these settings. In other words, "PVP options exist, you just can't set them yet." (At least not via the UI... )

Same goes for all the experimental bodies, although that is less new of an update.

Of course, since I don't really understand the existing midpoint code, and Jim wrote out the intended (improved) logic, I will probably re-implement that, at least for Uniwheels, for 0.6.0... since it doesn't exist currently (in the refactored code).

We're getting much closer to having an alpha or beta release for 0.6.0. My guess is that we are over the 50% mark for such a pre-release version.

Once these "mostly not-new" features are done, I'll hit the next few actual new features (such as adding angles to data tables), and then it'll be ready for (pre-)release.

[Jim Eshelman]

[Mike V]

Made some major strides tonight in getting biwheels working.

Check out what else I got working - from my most recent Memphis SSR:

Code: Select all

Class 1 Aspects 
tMo sq tVe  0°13' 99% p  
tMo sq tUr  0°26' 98% p
tMo sq tEr  1°26' 75% p 
tVe op tUr  0°41' 99%  
tJu co tEr  1°29' 96% M 
tMo sq rVe  0°35 '96% p  
tMo sq rPl  1°32' 72% p
tMo sq rEr  2°20' 37% p
tUr op rPl  2°25' 89%
rVe sq tJu  0° 8' 100%
rMa co rPl  1°44' 94% M

As a peek behind the curtain, the concept behind PVP calculation isn't that hard... but doing it right took 214 lines of code

(Yes I see some aspects have radical planets listed before transiting planets - I'm sleepy and will figure this out next time)

[Jim Eshelman]

far out! "Inch by inch," but this was easily several inches at once.

214 lines? I am indeed surprised. (I figured most of the code would mostly exist from the longitude vs. mundo aspects. I'd have thought the most complicated part would have been filtering out pairs that already have an aspect.)

BTW were you also working on inserting angle contacts into the aspectarian? I only ask because my dreams most of the night were about me juggling code to make them appear and struggling wit the right order for their presentation. Quite unusual for that kind of night process - and it was never clear why I thought it was something to struggle about.

[Mike V]

214 lines? I am indeed surprised. (I figured most of the code would mostly exist from the longitude vs. mundo aspects. I'd have thought the most complicated part would have been filtering out pairs that already have an aspect.)

If I were just writing code to parse PVP aspects in a vacuum, it would be a fraction of this length. The length comes from the order of operations, which, upon review, I can tighten up to some degree. It'll still be quite a bit of code, but I can slim down a lot of checks if I keep track of some of these things (like planets being on Vx/Av) earlier.

BTW were you also working on inserting angle contacts into the aspectarian? I only ask because my dreams most of the night were about me juggling code to make them appear and struggling wit the right order for their presentation. Quite unusual for that kind of night process - and it was never clear why I thought it was something to struggle about.

I was very intently focused on TM code last night, but I'm not up to this part yet. It'll be doable relatively soon, though. I pretty much just need to fix the cosmic state code (which is 80% working) and reimplement midpoints, and then I think we're ready to go with the other new features. There are surely lots of bugs that still need to get flushed out... but being able to test against my unit tests is helping to catch many of them while I'm still architecting the code.

[Mike V]

Looks like I'm almost at feature parity with 0.5.x; just missing midpoints (and bug-flushing).

Regarding midpoints... do we want to allow aspects between planets and midpoints, or midpoints and midpoints? Or is it just midpoint contacts to angles?

[Jim Eshelman]

Regarding midpoints... do we want to allow aspects between planets and midpoints, or midpoints and midpoints? Or is it just midpoint contacts to angles?

For what kind of chart? We already have midpoint contacts with planets. (Or are you talking about mundoscopes or polywheels or...?)

On midpoints-to-midpoints, I think that's too rare a thing to worry about now but architecture perhaps shouldn't exclude it (in distant future expansion). Most people would never use it and I almost never use it, though it some point it would be useful (perhaps as a separate report) someday to have a report showing all midpoints in a 360, 90, or 45 sort.

[Mike V]

For what kind of chart? We already have midpoint contacts with planets. (Or are you talking about mundoscopes or polywheels or...?)

That is my reason for asking - in doing this rewrite, I have to throw out the existing midpoint code in its entirety; it's difficult to understand and is unrelated to the structure I have. In the process of adapting it, I would end up just rewriting it anyway. That rewrite is based on your midpoint logic in the 0.5.0 thread.

Basically, do midpoints work essentially like planetary points as far as aspects go? Does the midpoint itself have to be on some angle, or is it sufficient for the planets to be on an angle? (Or, in the case of something like Solar Moon, can it make hard aspects with arbitrary planetary midpoints?)

[Jim Eshelman]

That is my reason for asking - in doing this rewrite, I have to throw out the existing midpoint code in its entirety; it's difficult to understand and is unrelated to the structure I have. In the process of adapting it, I would end up just rewriting it anyway. That rewrite is based on your midpoint logic in the 0.5.0 thread.

Basically, do midpoints work essentially like planetary points as far as aspects go? Does the midpoint itself have to be on some angle, or is it sufficient for the planets to be on an angle? (Or, in the case of something like Solar Moon, can it make hard aspects with arbitrary planetary midpoints?)

Ah, the big overview question. OK. I'll avoid most theory behind this and just focus on calculation and function.

Let's start with a natal chart. This currently has either full functionality or close to it (at least, at this stage). Also, for this discussion let's have the working term half-sum. In most cases, half-sum is an equivalent term to midpoint, but in this post I will use it very literally as he specific result obtained by adding the two longitudes and dividing by 2. {This allows us to distinguish, e.g., conjunctions and oppositions.)

In the Midpoints chapter of the book-in-progress, I make a lot of distinctions and assertions that alter some language. Nonetheless, I'll ignore that for this post for sake of simplicity. I mention it now only to say that if you find discrepancies between how I talk about things here and in the chapter, it's intentional use of different language.

The main thing is that planets contact midpoints. Conventional language is that planets aspect midpoints. While there are specialized theories in the German area, basically 98% of midpoint users to along with the idea that planets can make any 45° degree "aspect" to a midpoint, that there is a discernible difference between the 45/135 and "major aspect" contacts, and that there might be discernible difference between 0/180 and 90 (I don't think there is, but I might be in the minority on that).

Therefore, TMSA was designed to allow the user to specify an orb for 0/180° contact, an orb for 90° contact, an orb for 45/135° contact, and a separate orb for mundane contact of a midpoint with angles. Putting in no orb (blank) turns off that contact. - One change I would like is to allow orbs to be always left specified by another toggle whether to use it.

We'll come back to mundane below (remind me if I forget). The main thing is the ability to have 0/180°, 90°, and/or 45/135° aspects of planets or angles to a half-sum; to specify the orb for each; and to separately decide whether the 90° aspects are to be considered direct (like 0/180) or indirect (like 45/135).

Mundoscope: So far, we have only implemented (and that incompletely) PVL midpoints to the angles. We might want to expand that, though I don't know how soon or how widely. Taking a Solar Fire model, perhaps eventually swing it wide open - but, for now I think it should be narrow (with an eye to a code model that is later expandable).

On the theory that all 90° multiple contacts to midpoints are direct (conjunction) midpoints, and the fact that individual angles contacted are usually indiscernible, the way picked for showing PVL midpoints to angles is to specify it as to Angle rather than a specific angle.

What I know for sure is that PVL midpoints to angles are about as important in solar and lunar ingresses as are foreground aspects. I'm nearly as certain that, for ingresses, ecliptical midpoints to angles are worthless except we get the unusual situation of the minor angles (Z/N, E/W) that are contacted ecliptically. We need to keep options open for individual astrologers for further research. For natal charts (having now had a couple of years to watch them), I'm skeptical that mundane midpoints work, but (again) we should keep options open. (These distinctions can be made in default settings, though users should be able to change it as they can now.)

In a natal horoscope, the PVL midpoints to angles use all planets. In ingresses, it uses ONLY foreground planets.

The current treatment of midpoints to angles in ingresses is flawed. You might hate me a little when I spell out where it seems it should go. -- With the definition of "only take mundane midpoints to an angle in an ingress if the planets are both foreground," MikeN took the understandable approach of taking those planets that have some F flag (some angle) and allowing them to be used in PVL midpoints to angles. However, this gives nonsense results, liker one planet on Ascendant, another on Westpoint-a, and their midpoint in PVL happens to fall on some angle. That's not the sort of phenomena we were seeing with the ingress.

Something very close to what is needed is to say that two planets, to have their PVL midpoints considered, need to be on the same or opposite angle. This gets things like planets on either side of Ascendant, or one just above Descendant and the other above Ascendant, etc. This would be a significant improvement: If on major angles, use PVL; if EP-a/WP-a, use RA; if on EP/WP or Z/N, use longitude.

It's not perfect, though, unless you go a step further: You can't just use a planet's angle that has been identified for the G column. A planet might, e.g., be on Descendant AND Westpoint-a, but we list it as WP-a because that's the stronger angular contact. However, it is also foreground on the horizon and might have a legitimate PVL midpoint with another planet near the horizon.

That's about it for now. An entire other conversation about PVL planet/planet = planet midpoints can be deferred, I think. (Not needed now, at least.) I think it might best be handled by a sorted list of midpoints as mentioned previously (with an added way to turn this on for PVL in addition to longitude.) For ingresses, I'm sure if they're valid it would involve only foreground planets as an "averaging" effect. As for natals, while I truly hope mundoscope midpoints don't exist, I might not get my wish

And I haven't mentioned returns or other polywheels at all. I suspect there will at least be a strong vote for intra-chart midpoints for synastry when the time comes.

If I missed anything, flag me I have to get dinner and then get back to the office. We're changing over WAN carriers late tonight.

[Mike V]

I understand most of this (and wrote most of the code), but I want to double check my understanding on the edge cases. I'm mostly uncertain about the non-ingress contexts. I'll give examples under each and what behavior I think this would allow.

The main thing is the ability to have 0/180°, 90°, and/or 45/135° aspects of planets or angles to a half-sum; to specify the orb for each...

Any planet can have an 8-harmonic ecliptic aspect to:
planet-planet half-sum
planet-angle half-sum

And MC can have an 8-harmonic ecliptic aspects to:
planet-planet half-sum
planet-Ascendant half-sum

And Ascendant can have an 8-harmonic ecliptic aspects to:
planet-planet half-sum
planet-MC half-sum

As a current example from Alycen's chart, with the maximum orbs:

Code: Select all

Mc Le    |    Ma/Ne 85'd

Is this kind of contact something we still want to include?

For natal charts (having now had a couple of years to watch them), I'm skeptical that mundane midpoints work, but (again) we should keep options open. (These distinctions can be made in default settings, though users should be able to change it as they can now.)
...
That's about it for now. An entire other conversation about PVL planet/planet = planet midpoints can be deferred, I think. I think it might best be handled by a sorted list of midpoints as mentioned previously (with an added way to turn this on for PVL in addition to longitude.)

(Emphasis added)

So here, in natal charts, we're only talking about implementing angle = planet-planet mundane midpoints, and only 4th harmonic aspects, right?

Which "it" might be best handled by a sorted midpoint list - the deferred topic on PVL planet/planet = planet midpoints, or all midpoints? Does this sorted list mean that we wouldn't show midpoint contacts in the cosmic state report?

The current treatment of midpoints to angles in ingresses is flawed. You might hate me a little when I spell out where it seems it should go.

I think I get this part. As long as both planets involved in a midpoint (which are foreground one way or another) are on a given axis, we need to consider other contacts to that midpoint from planets on that axis, even if that axis is not the one which gives them the strongest angularity. So we need to track all axes that a planet is legitimately foreground on, even if we only display the closest one in the chart and in the info table.

[Jim Eshelman]

The main thing is the ability to have 0/180°, 90°, and/or 45/135° aspects of planets or angles to a half-sum; to specify the orb for each...

Any planet can have an 8-harmonic ecliptic aspect to:
planet-planet half-sum
planet-angle half-sum

Any planet or angle. In fact (except for mundane midpoint-angle contacts) the most comprehensive, forthright way to think about this is to regard angles as planets for midpoint purposes. (The typical Cosmobiological list includes ten planets, Moon's node, Ascendant, and Midheaven.) Except for mundane contacts to angles, everything that would be said about planets is said the same about angles.

In brief, any planet or major angle can make any 8th harmonic ecliptical aspect to any planet-planet or planet-angle midpoint. (Mundane angle contacts are a separate matter.)

As a current example from Alycen's chart, with the maximum orbs:

Code: Select all

Mc Le    |    Ma/Ne 85'd

In theory, yes. (I'd personally never go with those orbs - she has MC = Ju/Sa 21'd as the main contact. But, yes, if those orbs are picked, that's something that should be shown.

Is this kind of contact something we still want to include?

Yes - though the fact that you're asking is confusing, so I wonder if I'm missing something. This (if one accepts the orbs) is straightforward, basic midpoint theory. (I'm sure I'm missing something in this question?)

For natal charts (having now had a couple of years to watch them), I'm skeptical that mundane midpoints work, but (again) we should keep options open. (These distinctions can be made in default settings, though users should be able to change it as they can now.)
...
That's about it for now. An entire other conversation about PVL planet/planet = planet midpoints can be deferred, I think. I think it might best be handled by a sorted list of midpoints as mentioned previously (with an added way to turn this on for PVL in addition to longitude.)

(Emphasis added)

So here, in natal charts, we're only talking about implementing angle = planet-planet mundane midpoints, and only 4th harmonic aspects, right?

For a natal, on the issue of mundane midpoints we're only talking about implementing planet/planet midpoints to angles. One needn't think of them as 4th harmonic for calculation purposes (though that's technically correct) because the angles are always 0°, 90°, 180° 270° and we aren't distinguishing which is which. If I were writing the approach I'd simply sort the PVL midpoints on a 90° sort and take anything within orb-length of 0°. [Oh, I just saw you said that later ]

Does this sorted list mean that we wouldn't show midpoint contacts in the cosmic state report?

My proposal is that we not show mundane midpoint contacts in the Cosmic State report except for planet/planet = Angle (listed under Angle).

I think I get this part. As long as both planets involved in a midpoint (which are foreground one way or another) are on a given axis, we need to consider other contacts to that midpoint from planets on that axis, even if that axis is not the one which gives them the strongest angularity. So we need to track all axes that a planet is legitimately foreground on, even if we only display the closest one in the chart and in the info table.

Yeah, that's the complication.

[Mike V]

Is this kind of contact something we still want to include?

Yes - though the fact that you're asking is confusing, so I wonder if I'm missing something. This (if one accepts the orbs) is straightforward, basic midpoint theory. (I'm sure I'm missing something in this question?)

Nope, you got my question - I was just confused about mundane angle contacts being identified as "Angle," and then this ecliptical contact which actually shows Ascendant or MC as the point contacting a midpoint. I see now that they are different considerations with different math.

[Mike V]

I have the midpoint calculation code mostly working, but I'm a little confused about one case...
In my natal chart, Jupiter is apparently semisquare my Sun/Eris half-sum 64', according to the older midpoint code in TM. (I'm still using 90' orbs just so I can test as many cases as possible at once.)
Solar Fire also gives this as 63'. I guess it truncates rather than rounds; whatever.

The actual raw orb appears to be 225°, i.e. it's semisquare the longitude opposite of the half-sum. I'm guessing this is desired behavior for indirect midpoint calculation, since even Solar Fire gives it? It kind of makes sense, especially with Solar Fire's aspect option named "modulus" in the midpoint reports section...
If that's true, then we need to count raw 225° and 315° aspects to the half-sum the same as 45°/ 135°.

While there are specialized theories in the German area, basically 98% of midpoint users to along with the idea that planets can make any 45° degree "aspect" to a midpoint ...

Ah, I see you mention it explicitly here. I glossed right over this since we talk so much about 45° and 135° that I didn't realize this implied more.
Still, for sanity's sake, we do want to include 225° and 315° aspects to half-sums under the 45° orb settings, right?

[Patrick Machado]

Astrodienst gives Jupiter sesquisquare Sun/Eris 64' for your chart, FWIW.

[Mike V]

Astrodienst gives Jupiter sesquisquare Sun/Eris 64' for your chart, FWIW.

Thanks for the double check. It's late and I might be losing my marbles a little.

Still, my question to Jim does stand.

[Jim Eshelman]

I have the midpoint calculation code mostly working, but I'm a little confused about one case...
In my natal chart, Jupiter is apparently semisquare my Sun/Eris half-sum 64', according to the older midpoint code in TM. (I'm still using 90' orbs just so I can test as many cases as possible at once.)
Solar Fire also gives this as 63'. I guess it truncates rather than rounds; whatever.

Yes, I've seen that with SF. I do think it truncates in a lot of places, which is puzzling.

The actual raw orb appears to be 225°, i.e. it's semisquare the longitude opposite of the half-sum. I'm guessing this is desired behavior for indirect midpoint calculation, since even Solar Fire gives it? It kind of makes sense, especially with Solar Fire's aspect option named "modulus" in the midpoint reports section...

Correct. The half-sum and its opposite are both direct midpoints (just going the long way or short way around the circle). Besides, this is also not just 45° from the far-midpoint, it's also 135° (shortest route) from the near-midpoint.

If that's true, then we need to count raw 225° and 315° aspects to the half-sum the same as 45°/ 135°.

Sure. That's what you'd so with aspects, right? Count them both directions around the circle, just like your Eris at 21°40' Pisces is in backward 135° aspect to your Mars at 7°26' Scorpio (Eris around to Mars is 225°47'.

While there are specialized theories in the German area, basically 98% of midpoint users to along with the idea that planets can make any 45° degree "aspect" to a midpoint ...

Ah, I see you mention it explicitly here. I glossed right over this since we talk so much about 45° and 135° that I didn't realize this implied more. Still, for sanity's sake, we do want to include 225° and 315° aspects to half-sums under the 45° orb settings, right?

Yes. See above. (This would also fall out automatically if it was calculated on a45° sort, which is how I - and most Cosmobiologists - think of it.)

[Mike V]

Sure. That's what you'd so with aspects, right? Count them both directions around the circle, just like your Eris at 21°40' Pisces is in backward 135° aspect to your Mars at 7°26' Scorpio (Eris around to Mars is 225°47'.

Ah, so Patrick and I were both right about it!

Thanks for the sanity check. The code to check aspects to midpoints is conceptually the same as other aspects, but the order of operations makes me have to deal with this step explicitly.

[Jim Eshelman]

Code: Select all

Class 1 Aspects 
tMo sq tVe  0°13' 99% p  
tMo sq tUr  0°26' 98% p
tMo sq tEr  1°26' 75% p 
tVe op tUr  0°41' 99%  
tJu co tEr  1°29' 96% M 
tMo sq rVe  0°35 '96% p  
tMo sq rPl  1°32' 72% p
tMo sq rEr  2°20' 37% p
tUr op rPl  2°25' 89%
rVe sq tJu  0° 8' 100%
rMa co rPl  1°44' 94% M

I've been thinking about your observations on PVP aspect orbs. In practice (for ingresses, primarily) I've only been using a 3° orb (arbitrary, ultimately) as if it were the same as the 3° orb I'd use for a Class 1 square in the same ingress.

This creates a bit of confusion because - just maybe - that 3° boundary is closer to the Class 3 boundary we might use for an octile (never really taking it seriously past 2° etc.). OTOH, for ingresses (and, for that matter, returns) I only use Class 1 aspects. If consistency is a requirement, then the orb I use for PVP aspects in ingresses and returns should be what I'd end up labelling Class 1 aspects PVP aspects.

Of course, maybe I've been counting PVP aspects too liberally in ingresses. (It was, after all, originally an experimental search using imprecise estimation methods before we had the real way to calculate them.)

I'm thinking when you implement these you should default to the minor aspect orbs. I think the exact bounds from the sine curve fall at 1°14' (I've been using 1.25°), 2°00', and 3°00'. On this scaling, my natal Moon-Pluto PVP square (1°57') comes out to 52% - wide Class 2 - which probably is about the level of activity it has in my character (especially considering that a lot of what's expected from that aspect overlaps Moon's Aquarius placement, plus Pluto 2°47' from Antivertex is a [minor] thing by itself).

If we use these criteria, your Memphis aspects come out scored like this (not all Class 1 so I removed that label - sorted by strength):

Code: Select all

rVe sq tJu  0° 8' 100%
tMo sq tVe  0°13' 99% p  
tVe op tUr  0°41' 99%  
tMo sq tUr  0°26' 97% p
tMo sq rVe  0°35 95% p  
tJu co tEr  1°29' 95% M 
rMa co rPl  1°44' 94% M
tUr op rPl  2°25' 93%
-----------------------------
tMo sq tEr  1°26' 73% p 
tMo sq rPl  1°32' 69% p
-----------------------------
tMo sq rEr  2°20' 34% p

[Mike V]

These are cool ideas. I think you're probably right, in that there are multiple strength classes represented in the range of 0°-3° PVP aspects. 1°14' is an interesting cutoff; I will keep that one in mind as I continue to watch these aspects. FWIW, I sometimes find rather good aspects slightly wider than my initial 1°30' cutoff (in the 1°30' - 1°45' ish range), though it's too early to tell if this is a real dividing line I'm seeing or just chart-to-chart quirks that make some aspects seem more relevant than they are. I don't have a cohesive repository of charts kept specifically for PVP aspects or anything like that.

Looking at those Memphis PVP aspects, with your interpretations at hand to make sure I'm not getting too in my own head about it:

t. Moon - t. Venus: really quite accurate, more accurate than just Venus-on-angle.

t. Moon - t. Uranus: also really accurate, though it's not quite as starkly pronounced relative to t. Uranus on an angle, whereas Moon-Venus is a serious addition to the details of this chart.

t. Moon - r. Venus: Mostly accurate. I've gone on more dates this year than any year prior, and have had more success initiating them than I ever had before, but it's still not exactly a thriving area of my life.

t. Jupiter - t. Eris: I don't know. I'm contemplating the ways in which Solar Jupiter has shown up this year... not in easy, traditional, "clean success" kinds of ways. I got a small pay raise, but my review came with a focus for my next 12 months that was intimidating and definitely not an easy goal. I've gotten recognition in occult areas (for one, I was warmly received and greatly supported in my pursuit of a small congregation/fraternity that Juan started like a decade ago). I have been absolutely burning through money for a variety of reasons, some of them totally unexpected and some of them just natural requirements of my current life trajectory... it's not that I'm in debt or anything like that, but I have been intending to invest much more aggressively than I have been able to in actuality, as I've been blasting through every paycheck I get.

t. Moon - t. Eris: This is probably too difficult to call, even though t. Eris has been aspecting SSR Moon just barely within 1° for weeks. I feel like "something" has been cooking in the emotional/subconscious space, but I don't know how to verbalize it.

t. Moon - r. Pluto: Decently accurate, not profoundly. The tone seems right, although I don't have major life events to point to for this.

t. Moon sq r. Eris: I have no idea. I would only be guessing.

I want to say that there is a clear and obvious cutoff between the partile and non-partile aspects, but, of course, many of the non-partile aspects are Eris aspects that I'm taking potshots at. At the very least, there is a definite difference in strength between t. Moon - r. Pluto and the closer non-Eris aspects.

[Jim Eshelman]

1°14' is an interesting cutoff; I will keep that one in mind as I continue to watch these aspects.

That's simply where it falls on a normal sinusoidal curve. I'd thought for a while that crude drop-offs at 1° and 2° weren't quite right - they were quite workable, but it kept seeming that a Class 1 type effect was larger than the partile boundary. It was kind of a Doh! moment to realize, oh, that's what the curve is saying anyway!

Aspect amplitude curves in their non-negative phase are at 80% strength at the Class1 boundary, 50% at the Class 2 boundary, and 0% at the Class 3 boundary. If you set the outside edge (for a minor aspect) at 3°00', then 50% (Class 2) is precisely 2° and 80% (Class 1) falls at 1°14'. That made intuitive. Because TM asks for orb definitions in decimals, I picked 1.25°.

It works the same for minor angles, of course, since the curve is the same shape, except we weight it differently so that the outside Class 3 boundary is "called" 75%. This puts the Class 2 boundary (50% of the way from 75% to 100%) at 87.5% and the Class 1 boundary at 95%. Again, this 75%, 87.5%, and 95% markers hit 3°00', 2°00', and 1°14'.


For your notes on how the SSR PVP aspects have been behaving (a single case, but "case studies" are useful, too), it sounds like you're saying that the Class 1 aspects were generally pretty clearly active, Class 2 were reasonably perceivable, and Class 3 were vague enough not to warrant attention (with the added Eris uncertainty). Is that about right? (Or other similar words.) If so, it's about how these Class drop-offs usually feel.

I want to say that there is a clear and obvious cutoff between the partile and non-partile aspects

In this case, "no-partile" PVP aspects were all outside the 1.25° range also - they started at not quite 1.5°.

[Mike V]

For your notes on how the SSR PVP aspects have been behaving (a single case, but "case studies" are useful, too), it sounds like you're saying that the Class 1 aspects were generally pretty clearly active, Class 2 were reasonably perceivable, and Class 3 were vague enough not to warrant attention (with the added Eris uncertainty). Is that about right? (Or other similar words.) If so, it's about how these Class drop-offs usually feel.

Yeah, I can get behind those articulations of it. Very interesting.

I'm thinking when you implement these you should default to the minor aspect orbs.

This makes a lot of sense in light of this aspect class discussion, though I need to ask - by minor aspect, do you mean octile, for example? And do we still want to make it configurable? (Maybe a small section under "Mundane Aspects" with class 1/2/3 orbs that default to 1.25/2.0/blank?

[Jim Eshelman]

Yes, I meant octile and, yes, it should be user controllable (configurable) - both based on freedom principles and on the fact that there's more than a slight chance we'll change our minds about these things before we're done! (Or at least want to experiment with different values.) - I'd use 1.25/2.0/3.0 (everything I have in the last edition of SMA - which needs to be redone from top to bottom on calculations anyway - used 3° orbs simply because that's what I used for all other squares.

Oh, to be clear, then: For NATAL it should have C1/2/3. For ingresses and returns, probably not. Those go only to Class 1 in the standard default files right now so it makes sense to have these do the same, but perhaps default them to 2°/blank/blank.

You'll also need space for paran orbs when the time comes. (I don't know whether that should be C/1/2/3 or a single entry like midpoints.)

[Mike V]

Oh, to be clear, then: For NATAL it should have C1/2/3. For ingresses and returns, probably not. Those go only to Class 1 in the standard default files right now so it makes sense to have these do the same, but perhaps default them to 2°/blank/blank.

I agree, I think having spots for 3 classes in returns makes sense, and we can just default classes 2-3 to blank.

You'll also need space for paran orbs when the time comes. (I don't know whether that should be C/1/2/3 or a single entry like midpoints.)

I will need to catch up on how these get factored in. I know there threads in various places talking about parans, but they are still above the scope of my practical knowledge.

[Jim Eshelman]

Specific question?

[Jim Eshelman]

The parang discussion is in thr Mundoscope chapter of CSA.