Time Matters 0.6.0a Alpha Pre-Release - Windows

[Mike V]

This post and discussion is for the Windows release specifically. I will make separate threads for the Linux and MacOS releases, since those will probably have their own unique bugs to work through. Those will come a little while after this Windows pre-release, and will probably be at the beta level of stability, as opposed to this more unstable alpha.

This is the alpha release for 0.6.0, which is likely the single biggest release of Time Matters that will happen up through (and including) 1.0.0. As such, I expect way more bugs now than in any upcoming release.

The primary reason for this is that I significantly rewrote the core chart calculation logic for readability and extensibility: there's over 2,500 lines of new + repurposed code. This represents roughly 1/3 of the codebase. Accordingly, there is a lot of new surface area for bugs to hide in. The result of this rewrite, though, was that I was able to crank through most of the remaining major wishlist items in about a week, which is must faster than it would've been otherwise.

That means that there are a ton of new features to tempt you into testing it!

I have done my best to test this locally, but assume that this pre-release is unstable. It is a good idea to back up your TMSA directory if you have important charts and options files.
I sincerely apologize if files get corrupted or deleted. I do not expect this will happen, but it is always possible, especially with options - more on that below.

Here is a list of changes:

• Rewrote most chart code as mentioned - uniwheels and biwheels now share 95% of the same code. (Triwheels work too, as tested with anlunars... but there's not yet stable code to find the various minor return charts. I just hacked stuff together, then hid it for this public pre-release.)
• All of the midpoint logic has been rewritten from scratch based on Jim's instructions.
• Enabled PVP aspects. These can be toggled as well as configured in chart settings (there's a new button and input screen for them). You don't have to blank out orbs in order to toggle them off!
• Added calculations for planetary stations. This is not yet user-configurable.
• Enabled the Needs Hierarchy scores for planets in natal charts, including scores for planetary stations. This is not yet user-configurable (like variable dignities affecting what counts as a luminary sign ruler).
• Added angles to the data table (90% finished; see lower section).
• Removed Ep/Vx from the chart face.
• Fixed natal ecliptical aspects from showing up in return charts. Mundane aspects between radical planets will still be shown if the mundane aspect is closer than the ecliptical one.
• Background options: renamed "At Cadent Cusps" to "TMSA Classic" and renamed "Eureka Curve" to "Cadent Cusps." Your settings won't change, only the name in the options menu. (The arrangement of these options in the menu is unchanged.)
• TM now attempts to migrate default option files from "Default_XYZ.opt" to "XYZ_Default.opt" on startup. This is just a change in the file name.
• Option defaults are in the code itself now; if you delete a default option file, TM will write a new one from its own code.
• Included TM version in the data file for each chart. If you go to calculate a solunar return for an older chart which is earlier than some given version which I indicate in the code, you will be asked if you want to recalculate it. The options for the recalculated natal should be the same options file it was last saved with, but let me know if this behavior seems messed up. If that file doesn't exist anymore, it looks for Natal_Default.opt.
• TM attempts to fetch the version number from the chart file itself if it's not in the data file (which is the case for all charts made up to this point). If a chart was calculated prior to 0.5.7 (or TM can't find the original chart file for any reason), you will get the prompt to recalculate. As new versions come out, this "last supported version" number may go up if new logic becomes incompatible with older chart versions.

Here are known bugs or other unfinished pieces:

• While mundane midpoints work for ingresses, I'm sure I misunderstood one or another line of logic there, so I assume I will need to make adjustments to that. (The main thing I may have misunderstood: I have separate entries in the Cosmic Report for Angle, Ea, E, and Z, based on which one has the closest orb for 2 planets that are both on that axis. The lines only appear if there are entries to show. Maybe it should've all been listed under Angle.)
• PVP aspect strength seems scored off of a higher orb than the aspects are actually calculated with.
• I haven't figured out how to calculate altitude for Mc and Vx in the angle section of the data table, so those columns are just blank. In general, I'm not confident that all of the values I do have are completely right.
• Aside from the Needs Hierarchy, I don't yet include planetary stations anywhere (although they are calculated for every planet); we'd have to figure out where on the chart face or data table to indicate stations.
• I'm sure there are edge cases where my implementation of the Needs Hierarchy differs slightly from Jim's current calculations for it, and your angularity model will affect these scores since it affects the angularity strength of planets - but my initial testing makes me think the logic is 95%+ correct.
• Alignment for aspect columns can get a little weird when there are multiple columns.
• Rarely, I have seen what looks like weird natal precession happening in return charts. This has been hard to reproduce. I suspect this was an artifact of me testing with 2 different TM versions at the same time, but in case it's not - let me know.

If you choose to work with this alpha pre-release, I thank you for the time spent, and your patience in going back and forth with me on bugs. It helps me get these tested sooner and therefore allows me to get full releases out sooner.

The next few days are very busy for me, so I'll be able to respond but probably won't get to iterate code changes very much until the weekend or next week. I expect that there will be a long iteration process fix my misunderstandings and identify new bugs, so this thread will probably become very long by the end of that process.

As usual: let me know what I broke!

UPDATED (0.6.0a8):
https://mega.nz/file/gXskUCQI#qjgCfwion ... wQb4gFOsPs

[Jim Eshelman]

Woohoo! OK, diving in and replacing my installed version (after the recommended backup). I'll inch my way through the list.

Thanks for all this work, Mike! This is a big step forward. (Stabilized code that you and others can more easily modify and extend.)

[Jim Eshelman]

I'll work through this, gradually reducing the list, as a checklist to work off.

First: Installed. First impression is landing page, which seems to have been revisualized a little. At least on my desktop at home, there is no squeezing or evident distortion (we'll see if this persists on other screen sizes). After the title, the next paragraph is clearly smaller (non-overlapping) and the others all match each other. Buttons scale fine.

Pulled up my stored natal. As expected, it showed as last calculated. Tried to run current SSR, did not get a request to recalculate, just got the usual error message. Recalculated it and it calculated fine. - But it still won't calculate a solar return. Here is the error page. - CORRECTION: It gives the following error screen AND calculates the return chart anyway. (BTW, Default_X seems consistently converted to X_Default.)

[Jim Eshelman]

Enabled PVP aspects. These can be toggled as well as configured in chart settings (there's a new button and input screen for them). You don't have to blank out orbs in order to toggle them off!

The "Enable PVP As... is cut off on half-screen btw, but it's a nice way to do the page. This does not catch my Moon-Pluto PVP square (setting Moon's ML 180°14', Pluto ML 178°17', default orbs should catch the 1°57' square in Class 1. Similarly, my current demi-lunar for Grand Junction, CO should have a few PVP aspects with the due-east transiting Saturn and these do not appear.

Added calculations for planetary stations. This is not yet user-configurable.

It appears this was done since Anna-Kria's Uranus has Needs score 75%.

This should be indicated also on the data tables. I think I had never noticed that we don't have a column to mark for Retrograde (R) - I'm sure because you don't really need it since the Speed is a negative number. But stationary should be clearly marked somewhere - a blank space somewhere that the blank won't be missed. If nothing else, but an S in the blank space column after Speed?

Enabled the Needs Hierarchy scores for planets in natal charts, including scores for planetary stations. This is not yet user-configurable (like variable dignities affecting what counts as a luminary sign ruler).

I'm very excited to see this! - I was surprised to see where it landed on the report (surely because I was unclear). For esthetics and usability, my thought is to allocate four columns to the immediate left of the vertical bar for this. Your thoughts? Mine would then look like this:

Code: Select all

                                  Cosmic State                                   
Mo Aq  F  97%| sx Ma  1°31'    tr Ve  4°29'    tr Ur  5°56'    
             | tr Ju  6°13'    oc Sa  2°33'    
Su Vi     57%| Mo Aq-
             | co Ne  8°14'M   sq Ma  6°28'    
Me Li     90%| Su Vi+
             | co Sa  2°24'    
Ve Sc-     0%| Su Vi-
             | sq Pl  0°13'    tr Ur  1°27'    tr Ju  1°44'    
             | sx Ma  2°57'    tr Mo  4°29'    
Ma Sg     50%| sq Ne  0° 7'M   sx Mo  1°31'    sx Ve  2°57'    
             | op Ur  4°25'    op Ju  4°41'    sq Su  6°28'    
Ju Cn+    50%| co Ur  0°17'    tr Ve  1°44'    sq Ne  2°16'    
             | op Ma  4°41'    tr Mo  6°13'    
Sa Li+    42%| co Me  2°24'    oc Mo  2°33'    
Ur Cn     90%| Mo Aq+
             | co Ju  0°17'    tr Ve  1°27'    sq Ne  2° 0'    
             | op Ma  4°25'    tr Mo  5°56'    
Ne Li     50%| Su Vi-
             | sq Ma  0° 7'M   sx Pl  0°46'    sq Ur  2° 0'    
             | sq Ju  2°16'    co Su  8°14'M   
Pl Le      1%| sq Ve  0°13'    sx Ne  0°46'    
             |    Ne/Mc 33'd      Ur/As 44'd      Ju/As 52'd      

I'll check these as I go and see if I get the same result. I think odds are you got the logic right, but there might be some confusion. I have samples in the Needs Hierarchy chapter of CSA that I can use as a comparison. Once I make sure I'm calculating with the same orb and angularity defaults used in CSA:

My chart - matches exactly.
Anna-Kria's chart - matches exactly.
Trump's chart - matches exactly.

[Mike V]

Regarding the solunar calculation error: Whoops

How about this?

https://mega.nz/file/UesDmaSb#6XpZomv8E ... NigmeRy9zY

This should at least stop the solunar return error message from happening.

The "Enable PVP As... is cut off on half-screen btw, but it's a nice way to do the page. This does not catch my Moon-Pluto PVP square (setting Moon's ML 180°14', Pluto ML 178°17', default orbs should catch the 1°57' square in Class 1. Similarly, my current demi-lunar for Grand Junction, CO should have a few PVP aspects with the due-east transiting Saturn and these do not appear.

Ah, I know why this is. It's preferring Class 1 orbs over everything else. If you set Class 1 orbs to 3.0 for example, it does catch the aspects correctly. It seems to do it as well with your CO DSLR. I'll disentangle that one when I have some more time.

[Jim Eshelman]

Removed Ep/Vx from the chart face.

Confirmed.

Added angles to the data table (90% finished; see lower section).

Excited to see this! (So many things this will solve!) Now that I see it, I'm thinking we need something (a series of periods? - only out to the PVL column) in the blank areas for the table not to look like something is wrong.

Ascendant RA has no practical use. I think this should be removed.

I haven't figured out how to calculate altitude for Mc and Vx in the angle section of the data table, so those columns are just blank. In general, I'm not confident that all of the values I do have are completely right.

I forgot that SE doesn't have a direct calculation (I could find a formula on Wikipedia, I'm sure). Altitude of MC is co-latitude plus MC declination. Vertex altitude is PVL minus 180°. (There is a reasonable debate to be had on whether these are needed. At the moment, I can think of few things for which it matters at all.

[Jim Eshelman]

PVP aspect strength seems scored off of a higher orb than the aspects are actually calculated with.

I don't know what this means and, since I can't see them yet, I can't test. - Per our discussions, under present theory (with these defaults) they should match what you get for octiles also set with Class 3 ending at 3°.

Background options: renamed "At Cadent Cusps" to "TMSA Classic" and renamed "Eureka Curve" to "Cadent Cusps." Your settings won't change, only the name in the options menu. (The arrangement of these options in the menu is unchanged.)

Confirmed. - I think the two should change positions in the Options setup as a clear step in keeping-while-deprecating ("soft deprecating"?) the Classic option.

Alignment for aspect columns can get a little weird when there are multiple columns.

Confirming this is so. I have on Class 3 aspect that starts one column early. (Any idea why? These are all fixed length fields with fixed-width fonts.)

Rarely, I have seen what looks like weird natal precession happening in return charts. This has been hard to reproduce. I suspect this was an artifact of me testing with 2 different TM versions at the same time, but in case it's not - let me know.

This would be impossible to test without two versions of the program running for comparison. I'll ignore this for now, let me know if you need me to do more.

[Jim Eshelman]

How about this?
https://mega.nz/file/UesDmaSb#6XpZomv8E ... NigmeRy9zY

This should at least stop the solunar return error message from happening.

Confirming: No more error message.

Looking at a two-wheeler, now... things I noticed before also look nice here.

One clue on aspectarian column misalignment: The 100% starts in the same column as 99%, rather than one column earlier. This knocks some things off. Here e.g. is the aspectarian on my current solar. Look e,g. at Pluto transits to natal Jupiter and Uranus:

Code: Select all

    Class 1 Aspects      Other Partile Aspects                          
tMa sq tPl  1°24' 96%    tVe op tSa  0°47' 99%                          
tJu sq tPl  2°28' 88% M ------------------------                        
------------------------tSu co rSu  0° 0' 100%                          
tMo co rPl  3°19' 88% M tMa sq rMa  0°11' 100% M                        
tMa sq rJu  0°36' 99%   tMa co rNe  0°31' 100% M                        
tMa sq rUr  0°53' 98%   ------------------------                        
tJu op rMe  1° 2' 99%   rMa sq rNe  0°20' 100% M                        
tJu op rVe  2°48' 92% M                                                 
tJu sq rJu  1°51' 93% M                                                 
tJu op rSa  1°31' 97% M                                                 
tJu sq rUr  2°14' 90% M                                                 
tUr op rVe  2°11' 95% M                                                 
tPl sq rMe  2° 3' 92% M                                                 
tPl op rJu  0°37' 100% M                                                
tPl sq rSa  0°57' 98% M                                                 
tPl op rUr  0°14' 100% M                                                
------------------------                                                
rMe sq rJu  2°39' 86% M                                                 
rMe co rSa  2°24' 94%                                                   
rMe sq rUr  2°17' 90% M                                                 
rJu sq rSa  0°20' 100% M                                                
rJu co rUr  0°17' 100%                                                  
rSa sq rUr  0°43' 99% M                                                 

I do now see (using my Colorado Demi-Lunar) one PVP aspect - t Mercury-Saturn (27'). It should also catch:

t Sun-Saturn sq 0°22' p
t Saturn sq r Moon 1°19' p

[fivesight]

I've been trying to get TMSA running for a while. I finally got the program to open, but for some odd reason, the installer is not installing the default chart/options files, so I can't create anything.
Is it possible that one of you could send me a copy of the default files that it needs to work? I created my own directories for them and for the errors, but the folders come up empty when I try to do anything with the interface (which I am finally able to see.)
I've been really busy these last few weeks and haven't had time to work with it until today when I took the time from my writing projects. I really need TMSA to work because of the number of new clients (I have had to put some off already) I'm expecting this month and beyond, which would be difficult to handle without the instant mundane calculations - I hate approximations and guesswork.
Plus I really would like to ask more questions and share my discoveries with the forum, and not having TMSA to make samples is really a problem.

[Jim Eshelman]

Again, this sounds like a security issue. Since the installer does create folders ans unpack files to them on your platform, I find myself wondering what could keep it from doing so on your particular computer. That would usually be an unusually aggressive anti-virus or firewall program, or a standard one with non-standard settings, or POSSIBLY Windows security policies or settings that block folder creation by external programs. - - Just thinking aloud.

PS. Mike said thst on this current version, if the options folders aren't found, they are automatically generated so it isn't even a download or unpack issue. Again, this seems like some sort of write protection.

[Jim Eshelman]

Regarding uneven aspectarian columns, here is Trump's natal:

Code: Select all

    Class 1 Aspects         Class 2 Aspects         Class 3 Aspects     
Mo op Su  1°39' 96% M     Mo tr Ma  5°34' 59%      Su sq Ne  8°22' 13% M
Ve co Sa  0°59' 99% M     Mo sx Ju  3°45' 81%      Me sq Ju  7°25' 30% M
Ju tr Ur  0°26' 100%     Mo op Ur  3°10' 87% M     Ve sq Ju  7°52' 22% M
                          Su sx Ma  3°51' 80%        Ma sx Ur  8°53' 2% 
                          Su tr Ju  5°29' 61%       Ju sq Sa  6°22' 48% 
                         Su co Ur  4°49' 69% M      Ju sx Pl  7°25' 30% 
                          Me sq Ne  3° 1' 88%       Ur sx Pl  7°51' 22% 
                          Ne sx Pl  4°12' 77%

Looking at Class 2, the third row is off and this is on a row with 100% in Class 1, but the effect is the opposite of what I'd expect: Delete the space in front of "100%" and the misalignment gets worse.

I think, though, that there is a problem for mundane aspects: the "<space>M" seems not to occupy blank spaces but, rather, to take up additional spaces. If I drop two spaces in the first two rows to compensate for that, it fixes those, except... I haven't a clue when the fourth through eighth rows in Class 2 are off, since there are only spaces before them.

And I'm probably wrong about the "<space>M" because I now see that the "Class 2 Aspects" header is no longer centered when I take out those extra two spaces. It MIGHT, though, be the other way around: non-mundane aspects don't have two spaces added where "<space>M" would go.

Warning: This entire post might simply be rambling that gets us nowhere.

If I adjust Sun conjunct Uranus (no clue why it's off in the first place), this leaves at least five out of seven rows misaligned in Class 3; and even the two that are most left-aligned are not centered under the Class 3 header. Yet there are 9 spaces between the Class 1 and 2 headers AND the Class 2 and 3 headers.

From the end of the first entry in Class 1 (a mundane aspect), there are five spaces until the first Class 2 aspect. From the end of the third entry in Class 2 (also a mundane aspect), there are also five spaces to the misaligned Class 3 entry (which is clearly too far right).

Not making sense to me.

BTW I do see that the Class 3 Mars-Uranus sextile (2% strength) should have a space in front of the 2 (the flip side of the 100% issue.

I've counted up and down the rows and columns - which should be totally stable - and make no sense of it. For example, I can get everything making sense except the headers. Ah, part of it is that the Class 1 header starts on Col. 5 of those aspects, Class 2 starts on Col. 3, and Class 3 stars on Col. 1 (once the other line-ups are done). They're each losing 2 columns as one moves across. If that's all it is, the easiest fix is to take out two spaces between each of the aspectarian columns (three spaces after M instead of five). That would give this look:

Code: Select all

    Class 1 Aspects         Class 2 Aspects         Class 3 Aspects     
Mo op Su  1°39' 96% M   Mo tr Ma  5°34' 59%     Su sq Ne  8°22' 13% M
Ve co Sa  0°59' 99% M   Mo sx Ju  3°45' 81%     Me sq Ju  7°25' 30% M
Ju tr Ur  0°26'100%     Mo op Ur  3°10' 87% M   Ve sq Ju  7°52' 22% M
                        Su sx Ma  3°51' 80%     Ma sx Ur  8°53'  2% 
                        Su tr Ju  5°29' 61%     Ju sq Sa  6°22' 48% 
                        Su co Ur  4°49' 69% M   Ju sx Pl  7°25' 30% 
                        Me sq Ne  3° 1' 88%     Ur sx Pl  7°51' 22% 
                        Ne sx Pl  4°12' 77%                           

[Jim Eshelman]

That's not it exactly. Regrouping:

I go back to the beginning and make only these changes:

• Make sure "100%" uses the leading space (and a similar fix for the "2%")
• Drop two spaces after mundane aspects (spaces already taken by the M notation)
• Drop one space between Class 2 and Class 3 aspects (which use 6 instead of 5 spaces)

Then the headers are properly centered, the gap is the same between columns, and the only weird thing is that the fourth through eighth Class 2 aspects start several spaces too late. These are the ones that have no Class 1 aspects in front of them so I have no idea how that's happening. It looks like this:

Code: Select all

    Class 1 Aspects         Class 2 Aspects         Class 3 Aspects     
Mo op Su  1°39' 96% M   Mo tr Ma  5°34' 59%     Su sq Ne  8°22' 13% M
Ve co Sa  0°59' 99% M   Mo sx Ju  3°45' 81%     Me sq Ju  7°25' 30% M
Ju tr Ur  0°26'100%     Mo op Ur  3°10' 87% M   Ve sq Ju  7°52' 22% M
                          Su sx Ma  3°51' 80%     Ma sx Ur  8°53' 2% 
                          Su tr Ju  5°29' 61%     Ju sq Sa  6°22' 48% 
                         Su co Ur  4°49' 69% M   Ju sx Pl  7°25' 30% 
                          Me sq Ne  3° 1' 88%     Ur sx Pl  7°51' 22% 
                          Ne sx Pl  4°12' 77%

If I just manually fix the Class 2 column, everything else fixes, too; so whatever is causing the "nothing in Class 1 on this row" to be other than 24 spaces is the problem.

Code: Select all

    Class 1 Aspects         Class 2 Aspects         Class 3 Aspects     
Mo op Su  1°39' 96% M   Mo tr Ma  5°34' 59%     Su sq Ne  8°22' 13% M
Ve co Sa  0°59' 99% M   Mo sx Ju  3°45' 81%     Me sq Ju  7°25' 30% M
Ju tr Ur  0°26'100%     Mo op Ur  3°10' 87% M   Ve sq Ju  7°52' 22% M
                        Su sx Ma  3°51' 80%     Ma sx Ur  8°53' 2% 
                        Su tr Ju  5°29' 61%     Ju sq Sa  6°22' 48% 
                        Su co Ur  4°49' 69% M   Ju sx Pl  7°25' 30% 
                        Me sq Ne  3° 1' 88%     Ur sx Pl  7°51' 22% 
                        Ne sx Pl  4°12' 77%

[Jim Eshelman]

I was going to use my chart as another example to test these rules, but I have everything piled up in Class 1 with nothing in the correspond C2 and C3 columns. Nonetheless, if I apply these three rules, it leaves only one screwed-up alignment, the last aspect in C3:

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%     Ma op Ju  4°41' 76%      Mo oc Sa  2°33' 26% 
Ve sx Ma  2°57' 83%     Ma op Ur  4°25' 79%      Mo tr Ur  5°56' 35% 
Ve tr Ju  1°44' 94%                              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%

I think that's all I've got in me for this. It's too hot!

[Jim Eshelman]

Calculating Kamala Harris' Demi-SLR tonight in Pittsburgh (I use a birth time one minute earlier than the birth certificate time). Current program version gives these foreground aspects:

Code: Select all

    Class 1 Aspects                                                     
tMo sq tPl  1°26' 96%                                                   
tUr sq tPl  0° 3' 100% M                                                
------------------------                                                
tMo op rMo  0° 0' 100%                                                  
tMo co rSu  0°10' 100%                                                  
tMo co rMe  3°49' 84%                                                   
tUr co rJu  0°35' 100% M                                                
tPl sq rMo  1°26' 96%                                                   
tPl sq rSu  1°16' 97%                                                   
tPl sq rMe  2°23' 89%                                                   
tPl sq rJu  0°32' 99% M                                                 
------------------------                                                
rMo op rSu  0°10' 100%                                                  
rJu op rNe  3°49' 84% M

There are several categories we don't ever need to see (and therefore probably don't want to see). Here's what hits my eye:

• t Moon op r Moon (or co in a full SLR). We know this already <vbg>.
• Ecliptical aspects of t Moon to natal planets. (These are the same as natal Moon-planet aspects.)
• Ecliptical aspects of t Moon to t planets. (These are just ecliptical transits to natal Moon In the present chart, see t Moon sq t Pluto, which is really t Pluto sq r Moon.)

I think there are others I'm too burnt out to think about right now. They probably are subtleties of mundane vs. ecliptical of transiting vs. natal Moon (but maybe I've indirectly caught those in what I just wrote). Applying the three points above to this chart, it changes the aspectarian to this:

Code: Select all

    Class 1 Aspects                                                     
tUr sq tPl  0° 3' 100% M                                                
------------------------                                                
tUr co rJu  0°35' 100% M                                                
tPl sq rSu  1°16' 97%                                                   
tPl sq rMe  2°23' 89%                                                   
tPl sq rJu  0°32' 99% M                                                 
------------------------                                                
rMo op rSu  0°10' 100%                                                  
rJu op rNe  3°49' 84% M

[Jim Eshelman]

Mike, an interesting example came up with Flo's prospective SSR. She was born Oct 24, 1960, 1:10 PM CET, The Hague, Netherlands. I was looking at her forthcoming SSR set for Vagharshapat, Armenia.

The PVP math (at least in this case - my first test case) is flawless. There is, however, a logical decision that leaves out one aspect that I think should be included. Here is the aspectarian that appears when I enable PVP aspects with max orb piled in Class 1. (It's so excited seeing the three PVP aspects pop up all on their own! It was also my first chance to use the angle data lines to quickly get the orb for Uranus on Zenith, another sweet discovery.)

Code: Select all

    Class 1 Aspects      Other Partile Aspects                          
tMo sq tSu  0°50' 99% M tSu co rSu  0° 0' 100%                          
------------------------tVe sq rPl  0° 6' 100%                          
tMo sq rSu  0°50' 99% M ------------------------                        
tMo sq rNe  0°47' 99%   rMa op rSa  0°30' 100% M                        
tMe sq rUr  2°48' 85% M                                                 
tUr op rMe  1°51' 96%                                                   
tUr sq rUr  0° 7' 100%                                                  
tUr sq rPl  1°15' 97% M                                                 
------------------------                                                
rMa sq rUr  0°19' 99% p                                                 
rSa sq rUr  1°50' 61% p                                                 
rSa sq rPl  1°49' 61% p

This chart produces an unusual PVP case, though, that requires a procedural ("how to handle") decision.

Flo has a natal Mars-Saturn opposition 1°06'. In this SSR, if is only 0°30' wide mundane and appears under "Other Partile Aspects." This means it's already in the top list aspect list, but in a column we wouldn't normally read to get a primary feel of the chart.

Then natal Mars-Saturn shows up as a PVP opposition exactly on the east-west line, orb 1°52'.

Code: Select all

Pl Longitude   Lat   Speed    RA     Decl   Azi     Alt      ML     PVL    Ang G
                               Transiting Planets                                
Ur  1Ta 5' 6"  0S16 - 2'13"  53°55' 19N 2 163°50' +68°12'  67°23' 276°21' 100% Z 
Me 22Li 4'57"  1S19 + 1°29' 224°19' 18S13   8°25' -67°52' 247°39'  86°36'  97% I 
---------------------------------------------------------------------------------
                                 Radical Planets                                 
Ur  0Le57'58"  0N42 + 2' 0" 148°33' 13N30  72°43' + 0°34' 179°50' 359°24' 100% A 
Me 29Li14'14"  3S 4 +22'18" 231° 9' 21S50 349°44' -71°25' 251° 8'  93°26'  97% I 
Pl 13Le23'18" 12N23 + 1'21" 165° 0' 19N50  57°13' - 6°24' 183°29'   7°36'  88% A 
Ma 19Ge56' 8"  0N52 +18'27" 106°25' 23N27  90°12' +38°20'   0° 9' 321°40'  14% Av
Sa 18Sg49'33"  0N12 + 3'38" 285° 5' 22S30 272° 4' -38°49' 181°40' 141°10'  15% Vx

Mars-Saturn doesn't appear as a PVP aspect either because that's the larger orb (1°52') or because you have it programmed not to list PVP aspects that have already appeared in the "Other" list.

I think we should not count "Other Partile Aspects" as already in aspect, so that this 1°52' PVP aspect appears in the main aspect list if PVP aspects are enabled. This is a new scenario in returns since these aspects generally occur without the planet being foreground, so it may just be a sequence of operation matter.

PS - As part of the fine tuning, t Sun co r Sun shouldn't appear in a solar. t Moon sq t Sun (mundane) shouldn't appear since it's the same aspect as t Moon sq r Sun. (This one mundane case will always be the same natal-to-transit, even mundanely, because natal and transiting Sun will always have the same latitude - unlike Moon in a lunar return.

[Jim Eshelman]

My July 15, 2025 SLR:
viewtopic.php?f=21&t=8808#p61195

TM correctly catches t Ju sq r Pl 0°12' p

It misses a harder-to-catch one. The PV planet is t Jupiter azimuth 89°48', ML 179°46'. Transiting Mercury is marked closely angular for EP-a but - were it not for that - it would be widely foreground on Ascendant with PVL 351°46' and 10° orbs set. With ML 178°25', Mercury is in 1°21' PVP square to Jupiter.

BTW, the June 18, 2025 catches all seven PVP aspects exactly right. I'm displaying this just to show how crazy things start looking sometimes if we decide these are solidly reliable in return charts:

Code: Select all

    Class 1 Aspects     
tVe sq rSu  0° 6'100% p
tVe op rMe  0° 3'100%  
tVe op rVe  2°25' 94% M 
tVe sq rJu  0° 9'100% M
tVe op rSa  1°58' 96% M 
tVe sq rUr  0°30'100% M
------------------------
rSu sq rMe  1°39' 68% p                                                 
rSu sq rVe  1°18' 80% p                                                 
rSu sq rMa  1°50' 61% p                                                 
rSu sq rJu  2°59'  1% p                                                  
rSu sq rSa  0°38' 95% p                                                 
rSu sq rUr  2°44' 16% p                                                 
rMe sq rMa  2°42' 86% M                                                 
rMe co rSa  2°24' 94%                                                   
rVe sq rJu  2°33' 87% M                                                 
rVe sq rUr  2°54' 84% M                                                 
rMa sq rNe  2°25' 89%                                                   
rJu sq rSa  1°49' 94% M                                                 
rJu co rUr  0°17'100%                                                  
rSa sq rUr  1°28' 96% M

Without PVP aspects, the list is still long, but much clearer in meaning at a glance:

Code: Select all

    Class 1 Aspects     
tVe op rMe  0° 3'100%  
tVe op rVe  2°25' 94% M 
tVe sq rJu  0° 9'100% M
tVe op rSa  1°58' 96% M 
tVe sq rUr  0°30'100% M
------------------------
rMe sq rMa  2°42' 86% M                                                 
rMe co rSa  2°24' 94%                                                   
rVe sq rJu  2°33' 87% M                                                 
rVe sq rUr  2°54' 84% M                                                 
rMa sq rNe  2°25' 89%                                                   
rJu sq rSa  1°49' 94% M                                                 
rJu co rUr  0°17'100%                                                  
rSa sq rUr  1°28' 96% M

[Jim Eshelman]

Another fringe case: My May 21, 2025 SLR. It missed two PVP oppositions. Azimuths:

89°26' - t Pluto
270°11' - r Jupiter
270°45' - r Uranus

This should give:
t Pluto op r Jupiter 0°45' p
t Pluto op r Uranus 1°19' p

BTW, as I mentioned the ones missed, I should also mention that the program is catching several that I missed even after we had the Vx markings and ML. (Eye-balling the aspects has weaknesses.) For example, I missed two of the six PVP aspects in my January 4, 2025 SLR until the program found them for me. Neat!

[Jim Eshelman]

My November 11, 2024 SLR has natal Mars and Neptune angular, correctly marked for EP and MC respectively. These two planets are in 2°25' ecliptical square; but their square did not appear in the aspect list on 0.6a. (It must have appeared in the earlier versions because I have it written down in the post of all of next year's lunar returns that I plowed through quickly, just copying from TM's output.)

Code: Select all

Pl Longitude   Lat   Speed    RA     Decl   Azi     Alt      ML     PVL    Ang G
                               Transiting Planets                                
Ve  4Sg53'33"  2S 9 + 1°12' 269°59' 25S36 123°58' + 3° 5'   1°44' 356°17'  97% A 
---------------------------------------------------------------------------------
                                 Radical Planets                                 
Ne  1Li20'24"  1N39 + 2'13" 205° 7'  8S39 177°21' +47°15'  47°13' 272°27'  99% M 
Ma 28Sg55'21"  2S50 +36'43" 296°26' 24S 6 108°48' -15°40' 354°50'  16°30'  96% E 
Su 22Vi27'42"  0N 0 +59'17" 196°11'  6S53 190°42' +48°30'  48° 0' 260°40'  79% M 
Pl  2Le 6' 8"  9N55 + 1'20" 153° 2' 21N44 267°56' +44°22'   2° 1' 224°23'  35% Vx
---------------------------------------------------------------------------------
    Class 1 Aspects      Other Partile Aspects                          
tVe sq rPl  0°18' 99% p  tMe sq tSa  0°58' 98%                          
------------------------tMa op tPl  0°37' 100% M                        
rNe sq rPl  0°35' 96% p ------------------------                        
                        tMo co rMo  0° 0' 100%                          
                        tMa sq rSa  0°33' 99% M                         
                        tUr sq rPl  0°58' 98% M                         
                        tPl sq rSa  0° 3' 100% M 

I just noticed something similar in my Oct 15, 2024 SLR: The aspectarian correctly catches t Mercury-Pluto square but missed the natal Mercury-Saturn conjunction, even though natal Mercury and Saturn are marked foreground. (The aspect is tightened to 0°24' mundo.)

There may have been other natal aspects missed - I wasn't watching those closely as I went through (I was looking for PVP aspect examples). I'll watch more closely as I go through the demis in a few minutes.

DIAGNOSIS: It may be this simple: It seems not to be listing the natal aspects. Here is the aspectarian from my Aug 25, 2025 demi-lunar. You can tell from the aspects listed that my natal Jupiter-Uranus conjunction (square Neptune) is foreground, but my natal Jupiter-Uranus-Neptune aspects don't appear. - Now that I'm looking for it, I see that this section isn't present in any of the lunars I'm checking.

Code: Select all

    Class 1 Aspects      Other Partile Aspects                          
tVe op tPl  2°44' 92%    tSu sq tUr  0°39' 99%                          
------------------------tSa co tNe  0° 4' 100% M                        
tVe co rJu  0° 1' 100% M------------------------                        
tVe co rUr  0° 3' 100% MtMo op rMo  0° 0' 100%                          
tVe sq rNe  2°44' 86%   tVe sq rMe  0°57' 98% M                         
tJu sq rPl  0°26' 98% p  tJu sq rSu  0°59' 98%                          
tPl op rJu  3°12' 89%   ------------------------                        
tPl op rUr  3°28' 87%   rMe sq rJu  0°58' 98% M                         
                        rMe sq rUr  0°54' 98% M                         
                        rVe sq rPl  0°13' 100%                          
                        rMa sq rSa  0°12' 100% M

AND YET: I just noticed that the Apr 10, 2025 demi displays natal Mars-Jupiter and Mars-Uranus oppositions! (Now I'm less clear what's going on. Is it only missing this section when there is also a PVP aspect in the list???)

That may be: The next one to miss was the 3/14/25 demi. I had previously calculated the aspectarian as:

t Mars sq r Sun 0°14' M
r Jupiter-Uranus co 0°14' M
r Uranus-Neptune sq 0°32' M
r Jupiter-Neptune sq 0°47' M
r Mars-Neptune sq 2°25'

t Uranus sq r Neptune 0°09'
t Uranus sq r Sun 1°17'

TM 0.6a gives it as:

tMa sq rSu 0°14'
t Ur sq rSu 1°17' p

So it does have a PVP aspect and it did miss the four foreground natal aspects. That may be what's happening.

It also missed one PVP aspect that I'd previously calculated, t Uranus sq r Neptune. Thias is another one of those fringe cases where Neptune is identified as on EP-a rather than Asc but, were it not on EP-a, it would still be 5°38' from Asc and in 0°09' ML square to Uranus.

There may be a larger issue with EP-a angularities and aspects. Look at my 12/21/24 demi. No PVP aspects (correct). It does catch natal Jupiter-Uranus. It does not, however, include natal Jupiter-Neptune and Uranus-Neptune, even though natal Neptune is marked foreground and correctly shows a transit from Mars.

[Jim Eshelman]

Fixed natal ecliptical aspects from showing up in return charts. Mundane aspects between radical planets will still be shown if the mundane aspect is closer than the ecliptical one.

I wonder if this is the cause of the problem above. We, of course, do not want natal ecliptical aspects to show in the "Other Partile Aspects" column, but we do want them to show if foreground. I think they are probably coded to do exactly that, since at least some of them show (and, mostly, all of them show if foreground and there are no PVP aspects in the list). Nonetheless, I wanted to mention the possible (but I think unlikely) connection.

But these seem not to be gone from the "Other Partile Aspects" section either. Look at, say, my 9/8/25 SLR which I accidentally calculated for birthplace, Rochester, IN. My ecliptical natal Ve-Pl and Ju-Ur both appear:

Code: Select all

    Class 1 Aspects      Other Partile Aspects                          
tMo sq tUr  1° 6' 85% p tPl op rJu  0°55' 99% M                         
------------------------------------------------                        
tMo co rMo  0° 0' 100%  rVe sq rPl  0°13' 100%                          
tMo sq rVe  1°58' 55% p rJu co rUr  0°17' 100%                          
tJu op rMa  2°51' 91% M

[Jim Eshelman]

Option defaults are in the code itself now; if you delete a default option file, TM will write a new one from its own code.

OK, let me be brave and test this

1. Ensure that my natal is last calculated with Natal Default.
2. Rename Natal_Default.opt.
3. Recalculate my natal with no changes. Get error, "Unable to open 'Natal_Default.opt'."
4. Exit program. Relaunch.
5. Check Chart Options and confirm that there is a new Natal_Default.opt file that looks like the program defaults (does not have my customizations).
6. Recalculate my natal with this options file and, of course, it recalculates with those options.
7. Go back and delete Natal_Default.opt and restore my previous Natal_Defaut.opt file.

[Jim Eshelman]

Included TM version in the data file for each chart. If you go to calculate a solunar return for an older chart which is earlier than some given version which I indicate in the code, you will be asked if you want to recalculate it. The options for the recalculated natal should be the same options file it was last saved with, but let me know if this behavior seems messed up. If that file doesn't exist anymore, it looks for Natal_Default.opt.

I see the version number in the data file. Picking Mike Nelson's chart (last calculated 5/2023 under 0.4.9.2), I try to calculate his current SSR and get, "Do you want to recalculate the radix chart to the newest version?" - Resisting the temptation to see what happens if I say No, I click Yes and get his current SSR for Upland, CA complete with two exactly angular Mercuries among other things (and all the new bells and whistles). When I click Back and then display his natal from the chart list, it comes up in the current version (complete with Moon and Neptune on Vx axis and his natal Mars-Neptune PVP square but missing the Moon-Neptune PVP opposition across the Vx axis; but that's for another post).

Neat!

[Jim Eshelman]

TM attempts to fetch the version number from the chart file itself if it's not in the data file (which is the case for all charts made up to this point). If a chart was calculated prior to 0.5.7 (or TM can't find the original chart file for any reason), you will get the prompt to recalculate. As new versions come out, this "last supported version" number may go up if new logic becomes incompatible with older chart versions.

Mike's mate Terry's chart was last calculated in Feb 2023. I'm not sure when this prompt appears. I click to show the chart and it opens the existing file, showing it was calculated under 0.4.9.2. Should I have gotten the prompt by this point?

[Jim Eshelman]

All of the midpoint logic has been rewritten from scratch based on Jim's instructions.

Are these now operative in all varieties of charts, or in the same limited way as before?

Setting all midpoint orbs to 60' (all four types) and running my natal, I get this from my TM midpoint report option file:

Code: Select all

Mo Aq    |    Su/Pl  7'd      Su/Ve 14'i      
Su Vi    |    Mo/Me  5'd      Sa/Mc 54'i      
Me Li    |    Ve/Ur 15'i      Ur/Pl 22'd      Ve/Ju 24'i      Ju/Pl 30'd      
         |    Ne/Pl 38'i      Ve/Ne 44'd      
Ve Sc-   |    Ne/As  2'i      Ne/Mc 20'd      Ur/Mc 40'i      Ju/Mc 49'i      
         |    Ur/As 57'd      
Ma Sg    |    Mo/Ve 43'd      Mo/Pl 50'i      Su/Ju 53'i      
Ju Cn+   |    Su/Sa  5'd      
Sa Li+   |    Mo/As  4'i      Mo/Mc 22'd      Ve/Ma 27'i      Ma/Pl 34'd      
Ur Cn    |    Su/Sa 22'd      Ju/Ne 51'i      
Ne Li    |    Ma/Ju  4'd      Ma/Ur 13'd      Ve/Mc 29'i      Pl/Mc 36'd      
         |    Ve/As 46'd      Pl/As 53'i      
Pl Le    |    Ne/As 16'i      Ur/Mc 27'i      Ne/Mc 33'd      Ju/Mc 35'i      
         |    Ur/As 44'd      Ju/As 52'd      
As Vi    |    Ve/Ur 16'd      Ur/Pl 23'i      Ve/Ju 24'd      Ju/Pl 31'i      
         |    Ne/Pl 37'd      Ve/Ne 44'i      
Mc Ge    |    Ne/Pl  3'd      Ve/Ne 10'i      Me/Sa 37'i      Ve/Ur 50'd      
         |    Ur/Pl 57'i      Ve/Ju 59'd

Comparing to Solar Fire (1° orb, 45° sort) I get exactly the same except it looks like you removed the M/A midpoint. This probably was a courtesy to me since I am extremely skeptical of it, but I think it should be included for others - as a general thing. If I said differently before, I apologize. (There is a rare 1' variation from SF on orb, probably because they truncate some things instead of round. MC = Me/Sa was 2' different.)

TM gave me no natal mundane midpoints to angles and, in fact, there are no direct midpoints to the angles. (The Ju/Pl and Ur/Pl midpoints are exactly at mid-quadrant, i.e., 45° from angles in PVL.)

It looks like midpoints are not implemented yet in return charts (which makes complete sense).

I attempted to recalculate my last (2023) SSR to see if midpoints would show under the Default Return options. I got this error:

Error.png

Checking ingresses (where I thought these were only enabled as mundane midpoints involving foreground planets and angles), I discover we have all selected midpoints showing - nice discovery. I don't know how relevant this might be (but that's because we haven't had them easily accessible before). One wonders, for example, if it's important that the precisely angular Neptune in the current Washington, DC Liblunar is not only square Mars but also on Ur/Pl and (groan) Ve/Sa. New tool!

But none of the four current solar and lunar ingresses for Washington (eight charts) has any mundane midpoints to angles. Is this not implemented? (This was there before, and I know you rewrote everything from scratch. Maybe these eight charts just happen not to have any of those. I'll check later.

Ah, wait, you left a note on this:

While mundane midpoints work for ingresses, I'm sure I misunderstood one or another line of logic there, so I assume I will need to make adjustments to that. (The main thing I may have misunderstood: I have separate entries in the Cosmic Report for Angle, Ea, E, and Z, based on which one has the closest orb for 2 planets that are both on that axis. The lines only appear if there are entries to show. Maybe it should've all been listed under Angle.)

I'll return to think through and discuss how many lines to display. Right now, I'm concerned about whether these are appearing or not. I'll run the same eight charts in SF (then edit the exact time to match TM) and see if there are any mundane horizon and meridian midpoints it should have caught.

LATER (listing non-dormant ingresses):

Capsolar: Allowing only Jupiter and Uranus, there are none.
Arisolar: Allowing only Mars, Jupiter, Saturn, and Uranus, there are none.
Libsolar: Allowing only Mars and Pluto, there are none.
Caplunar: With only Neptune angular, there are none. (PS it nicely caught the Sa-Ne PVP sq.)
Arilunar: Allowing only Moon and Pluto, there are none. (It caught the Mo-Ju PVP sq, though.)
Canlunar: With only Pluto angular, there are none. (It caught the Ju-Pl PVP sq nicely.)
Liblunar: Allowing only Moon, Mars, Jupiter, and Neptune, there are none.

OK, so that may be why it didn't show any I'll have to find other examples from SMA.

[Jim Eshelman]

While mundane midpoints work for ingresses, I'm sure I misunderstood one or another line of logic there, so I assume I will need to make adjustments to that. (The main thing I may have misunderstood: I have separate entries in the Cosmic Report for Angle, Ea, E, and Z, based on which one has the closest orb for 2 planets that are both on that axis. The lines only appear if there are entries to show. Maybe it should've all been listed under Angle.)

EP-a and WP-a contacts exist only mundanely. It makes sense to me, therefore, to have an Ep line like the As and MC lines but, of course, ONLY take RA contacts to it.

In a natal, this raises questions that have (more or less) never been addressed. Should ALL planets be able to have midpoints in RA on EPa-WPa (which btw is exactly the same as saying they have 90° RA midpoint contacts to MC)? It's always possible that they should, but I lean against the idea. I think only planets that are in defined orb of EPa or WPa already should count. If I'm wrong, then... well, no other program existing addresses the question at all, so we're still ahead of the curve (and you or somebody can modify the behavior in the future). I think, therefore, that only planets already marked as on WPa or EPa get counted for this. The behavior, then, would be consistent across all categories of charts.

Notice that about half of these may require special handling (different code for this kind of midpoint): It's easy as peas if both planets straddle the EPa or both straddle WPa. However, suppose one planet is 2°00' before EPa and another is 2°00' after WPa. This is absolutely the kind of midpoint to the angle that we'd be looking for, but the RA half-sum of these two planets would fall on the MC-IC axis, not the EPa-WPa axis. I suppose you'll identify the "qualified" planets then do a mod 90° to get the orb or some such thing.

"Mundane" midpoints to EPa should always be on if midpoints are on. They're a different category since they are the equivalent of ecliptical contacts to MC or Asc.


Switching to Zenith-Nadir and (ecliptical) EP-WP: If at least 90° midpoint contacts are turned on, these contacts will always show as midpoints to Asc or MC. For natals, it would seem very strange to have a separate line for this. (If someone has midpoints turned on at all, almost 100% of the time they will have squares turned on.)

But what about other kinds of charts? We can ignore return charts for now because these aren't enabled for biwheels. That leaves the question of ingresses.

Let's take the current Arisolar (Washington) as an example. In this, we find:
19°59' Aqu - Saturn
20°07' Tau - Asc
21°14' Aqu - Ma/Sa
22°28' Aqu - Mars

It isn't partile, but let's pretend it is. In fact, I'll increase my orb to 75' in TM and recalculate. I immediately notice a problem because the midpoint table only lists:

Code: Select all

As Ta    |    Mo/Ju 15'd      Mo/Ur 49'd      

This should have included: Ma/Sa 67'd. Apparent bug. Not sure why.

In any case - presuming this displayed as expected - every Z/N or E/W contact is going to be visible in ecliptical squares to Asc or MC.

In ingresses, this could be a minor problem because there may be nothing to filter it out. In this case, there is a 2°02' Mars-Saturn mundane conjunction and 2°29' ecliptical conjunction, so we see the Mars-Saturn connection. However, one could easily have each of them 2°30' either side of Z/N/E/W, or 5° apart, and there wouldn't be the aspect so we'd want Z = Ma/Sa (or As = Ma/Sa) to pop out at us without digging too hard.

One way, of course, is to have separate Z and E lines on the Cosmic State table (lines that, as you said, only appear when something is on them). And, of course, it would only allow planets already identified as being on Z/N or E/W (not all planets). This might be the best solution. In that case, the lines for Z and E should appear under the Angle line (if it's present) so as to easily visually filter these contacts as different from the usual As or MC contacts.

The other approach (I favored it when I started typing this, but I'm not so sure anymore) is that the only midpoints allowed on As and MC lines are those of foreground/angular planets. I think now that this is not quite as good because it doesn't instantly distinguish those (e.g.) aligned with Asc ecliptically from those aligned with Zenith ecliptically.

Picking the first of these two ideas may also make the decisions easier later when we come to return charts and other biwheels. I'm not sure that midpoints are going to prove of any serious value in return charts (though I could be wrong - we've never been able to systematically study this easily, and it's been a minor question). But if they are, I have a sneaking suspicion that we'll find that the ecliptical ones are the ones that matter. (I could be wrong about that, too, since it's only a hunch. Another example of why we need to be able to test.)

[Jim Eshelman]

I think that's all the points raised. More stuff if I find it.

[Mike V]

Okay, I'm finally back at my computer and have time today to start looking through the points you raised. Thanks for spending all of this time digging into these different cases. Since the surface area of this alpha pre-release is so large, and I expect this thread to grow even larger by the time we've worked out all the kinks, I'm making a new column on the Trello board specifically for these bugs... otherwise it'll get hard to track what I did and didn't fix yet.

Let me rip through the thread really quick and make bullet points for all of these before I dig into specifics.

• "Enable PVP aspects" is truncated on half screen
• Some Lunar Return PVP aspects not getting caught (this may be completely due to Class 1 orbs being given special treatment, or only partially due to this)
• Needs hierarchy - move percentages to the left of the vertical pipe (I agree with you, that's much more readable)
• Stationary planets - add an S in the blank column after speed
• Add series of periods for empty columns for the angles in the data table
• Remove Ascendant RA from data table
• Add altitude of MC, VX
• Switch TMSA Classic and Cadent positions in the options menu
• Fix aspectarian column misalignment (including headers)
• Remove same-planet to same-planet aspects in solunar returns
• Remove ecliptical aspects of transiting solunar planet to natal planets and transiting planets
• PVP aspects - include PVP aspect when otherwise "other partile" would have eliminated it
• Ingresses no longer getting marked dormant
• PVP aspects - planets in foreground and also on PV aren't caught for PVP aspects

(I'll come back to this)

[Jim Eshelman]

I thought I saw this yesterday, but didn't stop to confirm.

Ingresses meeting the dormancy criteria are no longer being marked as dormant. Use the current Cansolar for Washington as an example.

I can get by working this out by hand for the moment though it's a gigantic advantage to have them flagged.

[Jim Eshelman]

Caplunar 9/13/2024 23:25:51 UT Washington, DC

Neptune is correctly marked as on Ascendant, with PVL 2°14'.

But Neptune is also on Antivertex (and correctly not marked) with azimuth 90°25'.

Therefore, Neptune makes three PVP squares with planets near the horizon. MLs:

359°59' Neptune
180°14' Sun
180°40' Saturn
182°27' Mercury

I suspect this wasn't caught because Neptune wasn't overtly flagged as Av or Vx.

[Jim Eshelman]

PVP aspects - include PVP aspect when otherwise "other partile" would have eliminated it

It occurs to me that I may not have been detailed in my vision as we build layers of types of aspects. Here is my view:

In all cases where "Partile" ("Other Partile Aspects") is enabled, the sequence is:

1. Calculate and list all aspects otherwise defined and enabled.
2. Then separately tabulate any enabled partile aspects of planet pairs nor already found to be in aspect.

We now have three types of aspects. (There will be a fourth.) The basic flow would be:

1. If ecliptical aspects are enabled (defined) - the usual situation - calculate all defined ecliptical aspects.
2. If mundane aspects are enabled (defined) - as they usually will be - add all of these to the list. If the same planet pair makes both ecliptical and mundane aspects, the closer orb wins (only list that one.)
3. PVP aspects are experimental at the moment, so are treated differently: If PVP aspects are defined and enabled, add these to the list if the same planet pair is not already in the list for an ecliptical or mundane aspect. Do not apply the "closest wins" rule. [NB: "Closest" should probably means "highest score," not smallest orb, it just occurred to me.]
4. When all aspects are thus calculated, if "Partile" box is checked then also tabulate the partile aspects of planet pairs not already listed.

The reasons for treating experimental aspect types differently are: (1) We want to be able to assess whether these are valid. The first step, then, is to filter out cases where there is already an accepted aspect between them. (2) We don't know the orb-curve behavior so might make significant mistakes in trying to sort out "stronger."

At some point, parans will be added as a fourth type of aspect. At that point we can decide where in the calculating sequence it goes. (They will surely begin as "experimental.")


There will also be variations in how these are treated for different types of charts, but I think this is already handled under existing rules. If All aspects re selected, all appear (and the "Partile" category falls away since there will be nothing to populate it.) If 1+ FG is selected, everything works the way we're used to it. If 2 FG is picked, as it usually will be for return charts, the only exception is that PVP aspects are allowed if one planet is foreground and the other flagged for Vx/Av. Parans will need no special treatment.

[Mike V]

Thanks for bearing with me; I've been very busy the past few days. I think I'm fully caught up and have some time to try to take a crack at these. My biggest targets are the actual error messages (like when you tried to recalculate an SSR single wheel), and dormant ingresses not getting marked dormant.

Mike's mate Terry's chart was last calculated in Feb 2023. I'm not sure when this prompt appears. I click to show the chart and it opens the existing file, showing it was calculated under 0.4.9.2. Should I have gotten the prompt by this point?

It only asks you to recalculate when you're trying to run solunar returns. Otherwise, you have the choice to view the chart (which just opens the chart file of course, with no changes), or to recalculate it if you are so inclined. It seemed excessive to force recalculation on everything.

PVP aspects - include PVP aspect when otherwise "other partile" would have eliminated it

It occurs to me that I may not have been detailed in my vision as we build layers of types of aspects. Here is my view: [...]

Although TM computes these in a different order (it just checks all the possible combinations one time, and then decides what to show later), it should be compatible with the flow you listed in this post, except that, like you pointed out in a different post, "other partile" overrides PVP aspects currently. This is because TM currently considers it as an existing ecliptical or mundane aspect, regardless of class or category.

[Mike V]

https://mega.nz/file/BTVCVQBK#NolmNzoRf ... 2q0qpwzJ08

0.6.0a2 can be found here. Hopefully it fixes a couple of things:

- Dormant ingresses should be listed as dormant now. The bug was a check that was never going to pass so everything was listed as non-dormant. Whoops!
- Aspects are categorized by strength % rather than orb. I think this shouldn't really be noticeable in most cases. Let me know if aspects are screwed up.
- Single-wheel solunar returns are now valid chart types and shouldn't throw errors.

[Jim Eshelman]

Installed at work (no time to finish on the home computer) and link updated above.

- Dormant ingresses should be listed as dormant now. The bug was a check that was never going to pass so everything was listed as non-dormant. Whoops!

My spidersense detects ANDs that should have been ORs? "Mark only if it's March AND it's August?"

In any case... Cansolar is correctly marked Dormant. (Nit-picky: An unnecessary space under the "Dormant ingress" line.) - However, after the "Dormant Ingress" notice, the chart then terminates. Even dormant ingresses need to display Moon aspects, i.e., any that it would show regardless. (To make it easy, there's no reason it shouldn't show everything it would display normally - no reason for separate treatment - and just have the addition of the Dormant notification. [Moon aspects are operative worldwide, including areas that have nothing distinctive on the angles.]

I just confirmed that the most recent Arilunar and Canlunar were also correctly identified as dormant, and the recent Liblunar was correctly NOT identified as dormant.

- Aspects are categorized by strength % rather than orb. I think this shouldn't really be noticeable in most cases. Let me know if aspects are screwed up.

It may be hard to notice these, as you say - and I'll keep an eye open. Since the aspectarian uses planet sequence, this will only show I think in the Cosmic State report.

Single-wheel solunar returns are now valid chart types and shouldn't throw errors.

Confirmed, using my next SSR for Roggen, CO. - BTW, this chart reminded me that I really LOVE having the angles listed in the data tables!

[Mike V]

My spidersense detects ANDs that should have been ORs? "Mark only if it's March AND it's August?"

It was actually even simpler than that, although more techy - I use classes to represent these different types of things, including chart types. So I’ll construct a chart along the lines of chart = Chart(type=ChartTypes.CAN_SOLAR). It’s a bit more involved than that but that’s the gist of it.

The problem is that checking to see if ChartTypes.CAN_SOLAR is equal to the text string “Cansolar” will never be true, and I missed that part it’s a simple fix, because ChartTypes.CAN_SOLAR.value does equal “Cansolar”, but this behavior of Python enums (enumerations; constant classes basically) is different from the Typescript enums that I work with all day at work, so I forget there’s an extra step when checking equality.

This isn’t the only thing that got weird because of that detail!

[Mike V]

Incidentally, that’s exactly the same cause as the error you got “Solar Return Single Wheel is not a valid ChartType.” Because it wasn’t!

I also didn’t have the single wheels in that enumeration anyway, so it was doubly-bugged, but fixing it required both adding it and then doing the check correctly.

[Patrick Machado]

Been messing around with it a bit and found no additional issues. The way the program is being revised/expanded seems really solid and promising.

A minor gripe (perhaps as minor as can be) that I've had for a long time with the planetary data table:

The first cell (upper left corner) being labelled Pl. It's bothered me that that first column both started with it and (for Pluto) ended with it. It looked... unaesthetic? A bookend that, being unintentional, felt like it didn't belong.

And now that the angles are listed alongside the planets, on top of the Pl(anet) label being ugly, it is inaccurate. We know what the table is about -- it's why we came to the party; that first cell needn't tell us.

I propose that the Pl label be removed (replaced by two spaces). The data table will look more elegant that way.

Related, but less bothersome: The G label of the last column doesn't make much sense. It should either be replaced, or blanked too. Most of what's exhibited below it are specifications of just one of the three possible grounds (i.e., the angles). And now, again, not even it being ground-related is accurate since we have Vertex/Antivertex there. If, like me, one has it set up to not mark background, then what ground it is never is listed under there, so G doesn't directly correspond to what is shown below it. Rather, what is shown under the last column is broadly part of angularity and should probably just share the Ang label of the angularity percentages.

[Jim Eshelman]

This is good feedback, Patrick. There are several possible approaches to this. I'll just give some opinions here. Mike may have some others.

• It had never occurred to me that the Pl and Pl were matching (never noticed). I completely agree that it is no longer accurate with angles added, and we only have two spaces to play with. I don't mind removing the column caption altogether; at the moment, it seems the best, esthetically cleanest idea.
• Something you didn't raise, but consistent with the "cleaner look: Even though the full word Longitude fits, we don't need it (nothing else is that long) and it happens to be ONE character two short to fill the column width. I suggest reducing it to Long (cf. "Lat" right next to it), centered on the column (moved in three spaces). [Decl could be shortened one character for similar balance and to match the more usual abbreviation.]
• The G doesn't bother me; nor do I have any strong reason for it to be there. It might be confusing to some people, in fact (though less so to those using the defaults which mark background: the b is a little strange hanging out there). But if the front end of the header row is softened, removing the G gives a more consistent esthetic.

 
Example:

Code: Select all

---------------------------------------------------------------------------------
      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang 
Mo  3Ar23'48"  4S16 +14°18'  27°12'  6N39 109° 3' +32°51'  11°54' 325°40'   4%   
Su  3Li33'48"  0S 0 +59'40" 205°49' 10S42 286°23' -36°31' 191°48' 142°21'  12%   
Me  7Li12'49"  0N19 + 1°38' 209°25' 11S41 282°43' -34°23' 188°34' 144°57'   6%   
Ve 23Le39' 2"  1N 5 + 1°11' 169°17'  5N47 338°43' -44°11' 222°10' 110°28'  55%   
Ma 27Cn 3' 2"  1N27 +33'44" 144°10' 15N47  11°49' -35°36' 215° 1'  74° 2'  45%   
Ju 29Ar45'41"  1S15 - 6'35"  51°57' 17N34  82°57' +20° 7' 177°26' 339°45'  23%   
Sa  4Aq12'58"  1S42 - 1'11" 331°13' 13S36 183°37' +38°31'  38°28' 265°29'  95% M 
Ur 19Le 0'46"  0N45 + 2'57" 164°51'  7N16 345°10' -43°50' 222°52' 104°56'  67%   
Ne 22Li35'24"  1N43 + 2' 9" 224°52' 15S14 269°13' -24°21' 359°39' 155°38'   8% Vx
Pl 21Le12'29" 13N47 + 1'40" 172°11' 18N24 339°52' -31°17' 209°43' 119°31'  50%   
Mc  7Aq53'41"               310°19' 18S18 180° 0'                 270° 0'
As 29Ta56'16"                       20N 8           0° 0'           0° 0'
Ep 11Ta46'12"               244° 8' 15N22
Vx 20Li19'57"                        7S57 270° 0'        
---------------------------------------------------------------------------------

[Mike V]

I vote for removing the Pl(anet) and G labels. Jim's example looks really clean.

I agree with Jim's example breakdown there, with Longitude -> Long, Decl -> Dec, etc.

I personally have never liked " b" as the background marker. It has also added minor complication to a whole bunch of checks due to the leading space. (Much, much less pronounced since my refactor, but it's worth mentioning that it was annoying! )

With that said... I kind of feel like it's easier to read with it being somewhat distinguished from the other grounds, i.e. " b" doesn't line up with anything else. I originally wanted to vote in favor of removing the preceding space... but I actually am neutral about it upon further review.

[Jim Eshelman]

I suggested it be offset because I didn't want it getting visually confused with angularity mariers.

Most of us turn on background markers rarely or never. I think, though, thst if you turned it on all the time (to get the experience of people who want it), you'd find the offset to be important

[Mike V]

I personally always leave it on. I'm coming to agree that the offset is indeed helpful.

[Patrick Machado]

Perhaps the mere fact of it being a single lowercase letter (which is actually fitting since we generally don't capitalize background etc.) is distinguishing enough? And in a sense, by having it on one already has "signed on" having extra information displayed, so it might not be a big deal having to process it lined up with the angles.

PS - As is, the b does line up with the a of Ea, the x of Vx, and the v of Av.

[Jim Eshelman]

It boggles my eyes to have it in the same column. I wanted clear "don'r have to think about it" right brain spatial distinction. (Absent use of color and shapes, it's very difficult to take a list of numbers and have it engage a rational parts of the brain, so I try for little hints of spatial distinctions when I can get it.)

[Jim Eshelman]

By chance are Grounds determinations working differently in natals and returns?

I'm speaking of the renamed "At Cadent" (formerly "Eureka") option. I thought I recalled (but can't find an example at the moment) that - since its boundaries aren't exactly bilaterally symmetrical - this was showing slightly different bounds like 11° foreground on the angular side etc. because it was using the % to determine it. Returns, however, are using the hard-coded boundaries: See e.g. Joe Biden's next SLR for Washington where Venus is 80% strong, outside the 10° specified foreground zone, and not marked foreground.

I remain ambivalent on which way this should be (longer conversation) but think they should match. I also know this is a work in progress, so the fair simple answer may be, "Yeah, they're different right now."

But thought I'd ask.

[Mike V]

The grounds determinations shouldn't be working differently in natals and returns - in fact, it's the exact same code that runs for both; it doesn't matter which "wheel" is being checked (or how many), or what the name of the body is, it only looks at the various orbs (PVL, RA, longitude squares to Asc/MC) compared to the options received.

With that said, it works based only on the orb specified. Angularity strength % is for visual display only, no other logic refers to it.

[Jim Eshelman]

Got it. I misremembered how it worked. Thanks

[Jim Eshelman]

I think this is already in the queue, but examples probably help: Here is another discovered example of aspectarian problems in returns.

My September 17 SLR calculated for my office (34N03'31" 118"W24'59"). It correctly gets that my natal Mars and Neptune are foreground but doesn't list my natal Mars-Neptune square as a foreground aspect. (I think this is an example of a natal-natal not being caught if there is a PVP aspect, such as the very interesting r Neptune sq r Pluto in this one - btw, it's been really nice having these in the aspectarian).

Another one where we might still be fine-tuning the rules: Under Other Partile Aspects, my natal Jupiter-Uranus doesn't show. (I'm not sure I'd have interpreted anything from it, but it is a factor theoretically relevant for the interpretation rules.) Natally it's ecliptically 0* 17' but (based on earlier calculation of the chart) it tightens to 0* 03' M in the lunar.

[Mike V]

Yes, this is in the queue but I always appreciate examples. I'm hoping to get a couple of these fixes in today. Thanks for being patient, my life has been super duper busy and I haven't had leftover gas in the tank to solve intellectual puzzles

[Jim Eshelman]

I forgot to ask - how did the Boston presentation go?

[Mike V]

Everything was fine! It's been a busy few weeks with work in general but objectively, everything has gone fine. (And busy is good for job security, though it's no guarantee of anything. I'm not getting crushed by work or anything. I just haven't had a lot of extra bandwidth left over.)

[Mike V]

Okay, finally, here's another iteration (0.6.0a3).

https://mega.nz/file/ZPMHQBQA#c9MtlGNuA ... fVJGVZkTuc

I believe that I fixed the following bugs:

• Needs hierarchy - moved percentages to left of the vertical pipe
• Renamed "Enable PVP Aspects" to just "Enable" so it won't get truncated
• Shortened column labels as discussed, e.g. "Longitude" -> "Long," removed "Pl" and "Ang," etc
• Stationary planets - added an S instead of the +/- in the speed value. (I tried it to the right of the speed value, but it looked awful and was super easy to miss.)
• Missing class 2/3 PVP aspects should now show appropriately if they are within orb
• Added periods for empty values in the angle section on the data tables
• Removed Ascendant RA from data table
• Added altitude of MC and Vertex. I am not positive I calculated this correctly, I would love a double check.
• Switched positions of TMSA Classic and At Cadent Cusp options
• Include in-orb PVP aspects when they would otherwise show up under "Other Partile" (as a mundane aspect, for example)
• Removed same-planet to same-planet aspects in solunar returns, i.e. t. Sun (any aspect) r. Sun

[Jim Eshelman]

Wow. That was one helluva night's work! - OK, I've updated the link, will install, and will test as the day goes.

Mike, thanks for all of this great progress.