Time Matters 0.5.0 alpha

[Mike V]

This is an alpha version, which means "I think everything mostly works correctly, but there could be lots of things wrong still." If you're not into the idea of potentially messing around with unstable code (which, in the worst case scenario, might break your existing charts or settings), then skip this and wait for the full (or at least beta) release. (A beta release means "it's not guaranteed to be any more stable, but at least I'm not actively still working on things.")

Here are the changes slated for this release:

Things you will notice:

• Change strength calculation for minor angles (reduction in displayed strength)
• Display meridian longitude
• Add indicator for Vertex/Antivertex contacts in azimuth
• Stop autotabbing while typing in form fields
• Add vertical scaling to title screen text (this is not functional yet)
• Add text wrap to buttons to prevent text from getting chopped off
• Enable the single-formula "Eureka" angularity curve (available under chart options)
• Include the downloadable zip file in the Github source code (this hasn't happened yet)

Things you won't notice (or shouldn't if I did them correctly):

• Make a whole lot of file path logic portable between operating systems (remove most Windows-specific stuff). You should NOT be able to detect any difference on Windows.
• Refactor uniwheel and biwheel code
• Use Blue for Python code formatting
• Add a lot of in-code documentation (variable/function names, comments)
• I made a manual port to Linux, and it functions, but it's not completely ready for use yet. (I have to lock down file system locations where things get stored, and properly deal with removing them upon uninstall)

Known things that are broken:

• Azimuth values for uniwheels go over 360*. Oops. I am pretty sure Vx/Av contacts still work properly. This doesn't appear to be broken for biwheels.
• Text under title is much smaller for Jim than for me

REVISED LINK (Alpha 6):
https://mega.nz/file/8O9VRThT#0x6tChsDR ... xqiN3MIq9o

[Mike V]

Let me also post my proposal about version numbering for these next few specific releases, while going through the wishlist items. I am happy to discuss, and this is a matter in which l ultimately defer to Jim's preference. But still, let me make my case...

I propose that actual feature releases, with features (or changes) that are clearly visible to users, get their own minor version number bump, starting with this 0.5.0, and increasing 0.6.0 -> 0.10.0 and beyond as needed (although I don't expect the numbers to get that high prior to a 1.0.0 release). This is how Python versions their releases for example. This is also how the Trello board is currently labeled, although I can easily change the version numbers there to whatever we want and rearrange items between those version columns.

Within the context of any current feature release, stuff that I broke or that otherwise needs an obvious patch gets a patch release, 0.5.0 -> 0.5.1, 0.5.2, etc. If everything goes according to plan, there will never be patch releases, but things never go completely according to plan!

When testing a new minor version release (like this one), I'll start with a beta version (or an alpha, in this case) so we can quickly iterate and iron out obvious bugs up front. After we think it's stable, it gets formally released as 0.X.0 with its own forum post, and anything that gets found and fixed later will get a patch release (or get fixed in the next minor release if it can wait).

When all of the primary wishlist items are complete - i.e. on what would be the last minor version release - we version up to 1.0.0. Any further development would then follow the same versioning system.

The reason I recommend this specifically, as opposed to using 0.5.x for all releases before 1.0.0, is that it's easier to conceptualize and refer to specific version eras as we go, 0.4.x vs 0.5.x vs 0.6.x and so forth. It's also smoother than jumping from 0.5.25 (or something) straight to 1.0.0.

[Jim Eshelman]

Agreed in versioning.

If you really feel the need to have actual alpha or beta 0.x versions, that's fine, though I'm also comfortable with "call it 0.x and .y it when we find the bugs." Could we, though, have a more obvious "ion your face" numbering for alphas and betas? Though it's probably not standard professional procedure, I'd suggest putting an A or B in front of the name - A0.5.0 - so it doesn't get confused with sub-versioning and people know it's an alpha or beta before going further?

[Mike V]

Could we, though, have a more obvious "ion your face" numbering for alphas and betas? Though it's probably not standard professional procedure, I'd suggest putting an A or B in front of the name - A0.5.0 - so it doesn't get confused with sub-versioning and people know it's an alpha or beta before going further?

That's a good idea, and I'll figure out a way to implement that. The reason I say "figure out a way to implement" is that cx_freeze imposes a certain format for me when building installers, which is why I had to make it 0.5.0a1 and not anything longer, or with hyphens, etc.

I can still display the title text however we want, so I'll add some logic to determine if the compact version number is an alpha/beta release or a full release.

[Mike V]

If you really feel the need to have actual alpha or beta 0.x versions, that's fine, though I'm also comfortable with "call it 0.x and .y it when we find the bugs."

I don't need to separate beta and full releases necessarily. In some instances, though, like this one, where there are cool features that are (hopefully) finished and working, but other stuff isn't, it's a sneak preview.

[Jim Eshelman]

It's not that big a deal - especially if not happening often. Also, I don't know how many people are installing these. Still, if it can be done, it would have an advantage for a general user group.

[Jim Eshelman]

Installed. Version number shows at the top. First paragraph is very tiny (and if you want it that tiny then it could go immediately under the title (that might be a nice effect). No scrunching further down. Button scaling looks good (things can always be better, but this is looking pretty good! - Chart For Now on two lines and centered really caught my attention).

BUG FOUND: Marion's chart. Azimuth column has five planets more than 360° (e.g., Moon 500°35' azimuth). - Oops,. I just saw that you know about this.

Change strength calculation for minor angles (reduction in displayed strength)

Marion is my test case. Both Nadir points have exactly the right score. Yippee, I may not need that spreadsheet anymore!

Display meridian longitude

It's there. Other than quadrant correction (which I haven't done on my spreadsheet), test chart produces these exactly right! (Yippee!! Now, I won't need that spreadsheet either!!!)

Now I just have to train my eye to see and read this column correctly. The secret is going to be only look at that column if Azi is nearly 90° or 270°

Add indicator for Vertex/Antivertex contacts in azimuth

My pet Vertex test case is retired Justice Breyer. This correctly caught and labelled his four planets on Vx and Antivertex. Interestingly, it caught this test against 90°/270° even though, as in Marion's chart, several planets are more than 360° azimuth.

Code: Select all

Pl   Azi     Alt      ML     PVL    Ang G
Mo 441° 1' +24°14'   4° 1' 204°30'  51%   
Su 271°33' +25°29'   0°44' 334°31'      Av
Me 269°53' + 5° 0' 179°59' 355° 0'      Av
Ve 259°53' -17°28' 183°10'  17°43'  63%   
Ma 272°35' +32°25'   1°38' 327°33'      Av
Ju 448°33' -20°10' 359°28' 159°49'      Vx
Sa 433°15' +27°25'   8°30' 208°26'  44%   
Ur 420°20' +55°58'  36°14' 239°35'   0%  b
Ne 262°53' - 0°56' 180° 7'   0°56' 100% A 
Pl 276° 7' +47°12'   6°33' 312°38'  19%  b

BUG FOUND: Most angle scores are missing. Was this intentional? They seem to be the ones where the Vertex markers are. (We still want the normal angularity scores from that. Perhaps I confused when I said the Vx/Av wouldn't affect the angle score - or however I badly said it.)

Stop autotabbing while typing in form fields

Confirm. (Thank you <s>.)

Add text wrap to buttons to prevent text from getting chopped off

Confirmed above.

Enable the single-formula "Eureka" angularity curve (available under chart options)

BUG FOUND: Turning this on only in the Temporary button (which should enable the future), it makes no change from the Cadent option.

Turning it on in Chart Options, the setting "sticks" (I can find it under the Temporary button after loading Natal_Default) but it still uses the Cadent option. (My Jupiter, Uranus, and Neptune should all be exactly 50% IIRC. They stay 35-ish.)

Request: Can we rename it Eureka in options? "Single-equation" won't be meaningful. (Maybe Eureka won't either, but it's a name <g>.)

Things you won't notice (or shouldn't if I did them correctly):

I haven't so you probably did

[Mike V]

BUG FOUND: Most angle scores are missing. Was this intentional? They seem to be the ones where the Vertex markers are. (We still want the normal angularity scores from that. Perhaps I confused when I said the Vx/Av wouldn't affect the angle score - or however I badly said it.)

Yes, this was intentional as I thought we didn't want it. I misunderstood, and can easily add them back.

[Mike V]

BUG FOUND: Turning this on only in the Temporary button (which should enable the future), it makes no change from the Cadent option.

Turning it on in Chart Options, the setting "sticks" (I can find it under the Temporary button after loading Natal_Default) but it still uses the Cadent option. (My Jupiter, Uranus, and Neptune should all be exactly 50% IIRC. They stay 35-ish.)

Request: Can we rename it Eureka in options? "Single-equation" won't be meaningful. (Maybe Eureka won't either, but it's a name <g>.)

Ugh, I know exactly why that's happening. Easy fix; I can do it today.

Sure, Eureka is shorter and more catchy anyway

[Jim Eshelman]

Vertex axis has nothing to do with a planet's strength (angularity), so we still need this provided from the normal curve.

[Jim Eshelman]

Sure, Eureka is shorter and more catchy anyway

I didn't bother mentioning that the half-screen Options paged are still scrunched. I suspect you know that. This means it is really called "Single-Equat". <vbg>

[Jim Eshelman]

This is really a great step forward, Mike. I'm going to celebrate by knocking some things off the list.

[Jim Eshelman]

A measurement of how significant this stage is:

28°57' Cap - MC when Astro (aka TM) was announced
29°29' Ari - t Uranus today

With Jupiter currently at 7°58' Taurus, I'm curious what will (if anything) when it reaches these locations:

12°00' Tau - TM's r Moon (6/25/24)
12°06' Leo - TM's r Sun (6/25/24)
18°53' Tau - TM's r Asc (7/29/24)

FWIW

[Mike V]

This is really a great step forward, Mike. I'm going to celebrate by knocking some things off the list.

A measurement of how significant this stage is:

28°57' Cap - MC when Astro (aka TM) was announced
29°29' Ari - t Uranus today

With Jupiter currently at 7°58' Taurus, I'm curious what will (if anything) when it reaches these locations:

12°00' Tau - TM's r Moon (6/25/24)
12°06' Leo - TM's r Sun (6/25/24)
18°53' Tau - TM's r Asc (7/29/24)

FWIW

Well, I'm very much in the groove with working on TM (and have been enjoying writing some Python for a change), so I wouldn't be at all surprised if 0.6, 0.7 etc get released around then (although, honestly, 0.6 at least should be sooner than 6/25).

First paragraph is very tiny (and if you want it that tiny then it could go immediately under the title (that might be a nice effect). No scrunching further down.

I think you must be seeing something different than what I'm seeing on my monitor. Can you share a screenshot of this?

Here is a second alpha release which fixes:
Actually using the Eureka angularity curve once enabled (that would be helpful, eh? );
Azimuth display - the calculations were fine, but for some reason I was displaying azimuth + 180 mod 360; no idea what that was about. The raw value matches Solar Fire;
Showing angularity scores even if a planet is on Vx/Av.

I also added some more hyphens to the chart info section so that, while it's wider than the chart, at least nothing is "spilling over."

<This download link also removed>

I'm removing the old download link from my first post to prevent any confusion.

[Mike V]

Wow, that's funky. I actually have no idea why that's smaller. I'll have to investigate. On my screen, all of the non-title text is the same size.

[Jim Eshelman]

You see why I suggested it could go immediately under the title?

[Jim Eshelman]

Second Alpha interesting behavior: It's the first time my taskbar pinned shortcut didn't work. It turned white, had to be unpinned, then repinned from a new launch.

[Jim Eshelman]

Here is a second alpha release which fixes:
Actually using the Eureka angularity curve once enabled (that would be helpful, eh? );
Azimuth display - the calculations were fine, but for some reason I was displaying azimuth + 180 mod 360; no idea what that was about. The raw value matches Solar Fire;
Showing angularity scores even if a planet is on Vx/Av.

Confirmed.
Confirmed.
Confirmed.

Btw, my chart is a great example of why we don't want to miss the angularity score on a Vx contact:

Code: Select all

Pl  2Le 6' 8"  9N55 + 1'20" 152° 4' 22N 5  87°13' +31°40' 178°17' 328°19'   1% Av

[Jim Eshelman]

I don't know why Marion's Pluto and Jupiter are not marked Background, though her Moon is. (This is on Eureka but that should be a separate issue, yes? It's clear that background marking is turned on.) - On Cadent model they are marked background.

Code: Select all

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

Also, on my chart, Eureka wrongly marks Mercury and Saturn background and misses the Venus. (It may have missed Pluto, too, but Vx by design overwrites that.) I suspect the Mercury and Saturn are marked b because there is code that for middle third of succedent houses forces background definition (that's part of the Cadent model). I'm not worried about that right now, therefore. I'm more concerned with it missing the clear 0% lows that are exactly at the cusp.

Code: Select all

Pl Longitude   Lat   Speed    RA     Decl   Azi     Alt      ML     PVL    Ang G
Mo 27Aq24' 0"  4N46 +14°42' 350°20'  1N 1 274°11' - 3°14' 180°14' 176°45'  97% D 
Su 22Vi27'42"  0N 0 +59'17" 195°16'  6S31  81°47' -19° 8' 182°50'  19°19'  57%   
Me 17Li21' 3"  3S10 +44'52" 218° 0' 18S18  75°14' -43°36' 193°39'  44°34'  34%  b
Ve  1Sc52'48"  5S48 +29'45" 232°10' 24S54  70° 7' -57°58' 208°33'  59°32'   0%   
Ma 28Sg55'21"  2S50 +36'43" 295°23' 24S16 294°46' -60° 0' 215°57' 117°40'  50%   
Ju  3Cn36'46"  0N 9 + 6'44" 119°50' 20N46 114°28' +54°36'  30°14' 302°54'  50%   
Sa 14Li56'37"  2N10 + 6'50" 217°22' 12S28  69°57' -39°17' 195°39'  41° 2'  42%  b
Ur  3Cn19'58"  0N30 + 1'17" 119°37' 21N10 114°12' +55° 1'  30°22' 302°33'  50%   
Ne  1Li20'24"  1N39 + 2'13" 204°12'  8S18  76°50' -26°56' 186°36'  27°33'  50%   
Pl  2Le 6' 8"  9N55 + 1'20" 152° 4' 22N 5  87°13' +31°40' 178°17' 328°19'   1% Av
Er 14Pi 1'12" 24S 0 - 0'38"  17°14' 18S46 241°45' + 3° 1'   1°26' 183°26'  97% D 

[Mike V]

I think this is fixed, though only for uniwheels; I'm sleepy and didn't touch the biwheel code, which will still have broken background detection for the Eureka curve only. (I think I'm gonna break it more if I try to do that one tonight.) The existing detection for background relied on the minutiae of quadrant position and orb classes, and ignored angularity score, so I refactored it to only care about angularity score being 25 or less so it's model-agnostic. (It missed your Venus because I half-updated things that checked angularity score and didn't update the other half.)

One of my "stuff you won't see or directly detect" goals as I go is tightening the way our astrological model is, well, modeled in the code. It'll make explaining (and preventing) mysterious behavior like this easier. There are a lot of different code paths at the moment, and things can easily fall into the cracks between them.

By the way, I see that there's a "don't mark background" option in the options menu and also in the code, though it seems like it's gotten a bit scrambled in terms of what it effects. Do you remember what parts of the info table are not supposed to get marked if that is enabled?

Here's the alpha 3 version with uniwheels fixed (I think): https://mega.nz/file/RbkR1KwR#zueqFBgyU ... kLKOghnEWE

[Jim Eshelman]

If "don't mark background" is selected, I think it only blocks the b at the end of the line. I keep it that way most of the time (and just scan the % column for single digits).

I think using the 25%/75% thresholds is the way to go on these markings. I just checked, and the Cadent model (which extends background much farther into the succedent or mid-quadrant area) does get the % part right so it can be used as a guide. I'm actually surprised Mike N didn't do this since he was so keenly focused on those thresholds.

[Jim Eshelman]

As a comparison, here is how the three angularity models treat my chart. First, the "Background at Cadent" that has been the standard for a long time. Since I'm still on alpha2, I've manually marked the b markers

Cadent - Eureka! - Mid-Quadrant

Code: Select all

Mo - 97% D - 97% D - 97% D
Su - 60%   - 57%   - 57%
Me - 15% b - 23%   -  0% b
Ve - 0% b  -  0% b - 34%
Ma - 45%   - 50%   - 39%
Ju - 36%   - 50%   - 29%
Sa - 23% b - 42%   -  4% b
Ur - 37%   - 50%   - 30%
Ne - 46%   - 50%   - 39%
Pl - 0% b  -  1% b - 31%

[Jim Eshelman]

Alpha 3 installed. (That title is now HUGE width, so my idea wasn't a good one.)

Background markers fixed.

[Veronica]

Very exciting! Congratulations on this great milestone. So glad it's all coming together so nicely.

[Jim Eshelman]

Please show Vertex or Antivertex mundane contacts in the planetary data table in the G ("Grounds") column. [...]

1. If the planet is already angular (already has an angle value in the "G" field), do nothing.
2. If a planet's azimuth is within ORB of 270°, put Vx in the "G" field. If within ORB of 90°, put Av in that column.

Donald Bradley's chart has Uranus marked as Antivertex overwriting its EP-a angularity.

Code: Select all

Ur  0Pi58' 5"  0S45 + 2' 4" 355°24'  2S48  92°29' - 1°25' 359°56'   1°25' 100% Av

May 16, 1925, 2:40 AM CST, Geneva, NE

[Jim Eshelman]

I just noticed something strange in the aspectarian of my upcoming demi-lunar. Here's the aspectarian:

Code: Select all

    Class 1 Aspects      Other Partile Aspects                          
tMo sq tSu  1° 5' 98%   tJu sq tSa  0°44' 99% M                         
----------------------   ----------------------                         
tMo sq tMe  0°22'100%   rVe sq rPl  0°13'100%                           
tSu co tMe  0° 6'100% M  ----------------------                         
----------------------  rJu co rUr  0° 2'100% M                         
tSu co tVe  2°34' 72% M                                                 
tMe co tVe  2°40' 70% M                                                 
----------------------                                                  
tSu sq rMo  1° 5' 98%                                                   
tMe sq rMo  0°22'100%

Notice that the Class 1 Aspects section has multiple divides and yet all aspects listed are transiting-to-transiting aspects except the last two. - I think the list of aspects is correct (they match what I calculated previously), they are just divided strangely.

The Other Partile Aspects column is a little off, too, since the last two aspects are both natal-to-natal but have a divider. I think something has slipped in here.

I just ran my current SLR (for Wright City, OK). Same thing. Dividers between every aspect (almost).

Code: Select all

    Class 1 Aspects      Other Partile Aspects                          
tMa sq rMa  0°25'100%   tSu co tVe  0°46' 97% M                         
----------------------   ----------------------                         
tMa op rNe  2°50' 66%   tMe co tUr  0°40' 98%                           
----------------------   ----------------------                         
tPl sq rSu  1°52' 93% M rMe co rSa  0°43' 98% M                         
----------------------   ----------------------                         
tPl op rJu  1°54' 84% M rVe sq rPl  0°13'100%                           
----------------------                                                  
tPl op rUr  2°21' 76% M                                                 
----------------------                                                  
rSu sq rJu  0° 2'100% M                                                 
----------------------                                                  
rSu sq rUr  0°29'100% M                                                 
----------------------                                                  
rMa sq rNe  2°25' 89%                                                   
----------------------                                                  
rJu co rUr  0°17'100%                                                   
----------------------                                                  
rJu sq rNe  2°16' 90%                                                   
rUr sq rNe  2° 0' 92% 

[Mike V]

I overlooked the first point; sorry about that. Fixed and will put it out soon along with with a few other fixes.

FWIW, TM shows angularity for Uranus as Ascendant rather than EP-a; 1°25' PVL conjunction is being evaluated as stronger than the 31' RA orb. Let me get some exact numbers for that...

Using the presently-named Eureka curve:

mundane_angularity_strength: 100
square_asc_strength: -2 (means that it's judged as not applicable, as expected)
square_mc_strength: 92
ramc_square_strength: 99

[Jim Eshelman]

The 2024 Capsolar for Washington, DC shows as Dormant despite the fact that it also correctly shows close angularities:

Code: Select all

Pl Longitude   Lat   Speed    RA     Decl   Azi     Alt      ML     PVL    Ang G
Mo 28Aq27'41"  2S13 +14°28' 354°57'  4S36 124° 4' +28°45'  17° 5' 326°29'   3%   
Su  0Cp 0' 0"  0S 0 + 1° 1' 297° 1' 21S 7 191°55' +29° 5'  28°33' 249°38'  23%   
Me  6Sg44'47"  1N 7 + 1° 9' 271°58' 22S19 215°34' +20° 2'  16°31' 212° 5'  50%   
Ve 25Sc33'58"  1N24 + 1°14' 259°55' 21S42 225°42' +14°26'  10°11' 199°47'  56%   
Ma 13Sg15' 3"  0S41 +45' 7" 279° 7' 23S52 208°32' +21°36'  19°11' 219°39'  45%   
Ju 10Ar55'37"  1S 7 + 3'12"  34° 4' 12N28  82°44' +10°57' 178°36' 348°57' 100% E 
Sa  9Aq35'18"  1S37 + 6'12" 337° 7' 11S18 145°32' +33° 0'  28°10' 311° 4'  42%   
Ur 24Ar 4'18"  0S18 - 0'36"  46°47' 17N13  71°16' + 4°17' 178°37' 355°29'  95% A 
Ne  0Pi16'26"  1S14 + 1'20" 356°13'  2S59 121°45' +29° 9'  16°21' 326°45'   2%   
Pl  4Cp45'12"  2S47 + 1'57" 302°38' 22S54 185°46' +27°59'  27°52' 259°17'  72%   
---------------------------------------------------------------------------------
                                 Dormant Ingress                                 
---------------------------------------------------------------------------------

Somehow it is not detecting the Jupiter exact angularity which is 0°12' wide (easily close enough to displace dormancy).

I just checked the Arisolar - same thing. (In case it's relevant, the wo close angularities are both squares to angles, i.e., EP and Zenith, though if the angularity score is being used it's plenty high).

I just ran a series of Capsolars: All are marked dormant regardless of close angularities. I think all ingresses are suddenly being marked dormant.

[Mike V]

I just noticed something strange in the aspectarian of my upcoming demi-lunar. Here's the aspectarian...

Thanks for catching that. I've been refactoring how that aspect-displaying code is arranged so I'm not terribly surprised that "divide actual categories" became "divide literally everything." I'll figure that out and include it in the next update; it'll be out at some point today.

[Jim Eshelman]

I'm not sure what chart this refers to, but...

FWIW, TM shows angularity for Uranus as Ascendant rather than EP-a; 1°25' PVL conjunction is being evaluated as stronger than the 31' RA orb. Let me get some exact numbers for that...

For a 0°31' minor angle contact, I get a 99.1% score. For distance below Asc, my spreadsheet shows 1°00' 99.8%, 2°00' 99.0%, so 1°25' is going to be approximately 99.4%. Yup, Asc contact is stronger.

Using the presently-named Eureka curve:

mundane_angularity_strength: 100
square_asc_strength: -2 (means that it's judged as not applicable, as expected)
square_mc_strength: 92
ramc_square_strength: 99

[Mike V]

The 2024 Capsolar for Washington, DC shows as Dormant despite the fact that it also correctly shows close angularities...

I just ran a series of Capsolars: All are marked dormant regardless of close angularities. I think all ingresses are suddenly being marked dormant.

They are. The reason for this is my brilliant decision to move the check for dormancy into each check for planetary angularity. So if any planet isn't angular, it's a dormant ingress.

It looks like the original intention is basically that it's a dormant ingress unless some planet has a Class 2 or better angularity for any angle. Am I reading that correctly?

I'm not sure what chart this refers to, but...
...Yup, Asc contact is stronger.

This was in reference to Donald Bradley's Uranus. Glad I got the correct relative weighting of the factors.

This 4th alpha should fix the dormancy issue with ingresses, and Vx/Av overwriting angular grounds. I have been looking through the code for the reason why we are getting so many dividers in biwheel aspectarians, and can't figure it out yet. That's my next target.

https://mega.nz/file/dDVWQSLD#M2umknGWt ... hO_zCtxMeM

I'll update the download link in the initial post.
Actually, I can't! Probably too much time has passed.

[Jim Eshelman]

They are. The reason for this is my brilliant decision to move the check for dormancy into each check for planetary angularity. So if any planet isn't angular, it's a dormant ingress.

That's an exceedingly clear definition

It looks like the original intention is basically that it's a dormant ingress unless some planet has a Class 2 or better angularity for any angle. Am I reading that correctly?

No. The formal definition is major angle within 3° or minor angle within 2°. At least one planet has to fit this. See the current edition of Sidereal Mundane Astrology, p. 10. (The definition given there is slightly more complicated and I think it better to use the crisp one: Within 3° of a major angle or 2° of a minor angle.

I thought Mike N had hard coded those. If not, then it would have been Class 1 major angle, Class 2 minor angle. - Oh, wait! Mikestar saw this definition as an inconsistency, it's what prompted him to define the minor angle curve so that 2° was treated as a minor angle Class 1 boundary to match 3° as a major angle Class 1 boundary. So... I'm not sure what he ended up doing, he might have then coded it to all be Class 1 or something.

I'd just hard-code it as 3° major, 2° minor; but if you think it should be user-adjustable (I think that undercuts the SMA work done), it would be Class 1 major, Class 2 minor.

This 4th alpha should fix the dormancy issue with ingresses, and Vx/Av overwriting angular grounds. I have been looking through the code for the reason why we are getting so many dividers in biwheel aspectarians, and can't figure it out yet. That's my next target.

Ah, yes, that's the distinction - biwheel. Not getting it in natals, not getting any aspects in ingresses <g>.

Thanks, I'll start the download and update the link.

[Jim Eshelman]

The pinned taskbar shortcut problem of the last two alpha versions didn't occur this time. Now on to the main stuff.

This 4th alpha should fix the dormancy issue with ingresses, and Vx/Av overwriting angular grounds. I have been looking through the code for the reason why we are getting so many dividers in biwheel aspectarians, and can't figure it out yet. That's my next target.

Dormancy problem partly fixed only: The current Washington Capsolar is not wrongly marked dormant (victory). It also doesn't have any aspects (it should)! - If I switch to All Aspects, they show (but, of course, not filtered by ground). - If I click any of the first three settings but Partile, I get "Other Partile Aspects" PLUS Moon aspects.

Ingresses should always should Moon aspects regardless of ground. (I think Mikestar did that by defining Moon as always foreground in ingresses when he ran aspects.) At the moment, they are appearing only if I check Partile box (regardless of which of the first three is picked).


Vertex-overwrite issue: Fixed. Bradley chart shows Asc. - However, the fix was too enthusiastic: The intention was that it not overwrite foreground (angle abbreviation) but DOES overwrite background (since it becomes relevant then and the % next to it makes the meaning unmistakable). Example: My Pluto shows as background, which it is; but it is also azimuth 87° 33' and should show as Av in the G field.

Inch by inch... Thanks for all this work and progress.

[Mike V]

Here's the alpha v5: https://mega.nz/file/QP8CHLJJ#9EM-CPE7l ... Z4Qg1jUEAE

Biwheel aspect table should be fixed. I spent like 2 hours figuring out what it was and it was so dumb you would not believe it. (I changed array indexes in a lot of places when I added meridian longitude to the data table. One of those places was not actually related to this at all. End result: every aspect was its own entire type of aspect.)

I think I fixed the dormancy problem (or got it closer to being fixed); for example, the current Capsolar (for DC) is not dormant, and I do see just a few aspects for it; the upcoming Cansolar (for DC) is dormant, but that chart still shows Moon aspects.
There may still be missing aspects, but I think there aren't; I didn't change any of the actual ingress code, just "what constitutes dormancy."

I'd just hard-code it as 3° major, 2° minor; but if you think it should be user-adjustable (I think that undercuts the SMA work done), it would be Class 1 major, Class 2 minor.

I went with hardcoding 3° major, 2° minor. I'm far weaker at mundane astrology than other techniques, but from what I do understand, this is less of a preference thing and more of a definition thing - so I'm happy to take this one out of users' hands.

Vertex-overwrite issue: Fixed. ... However, the fix was too enthusiastic... Example: My Pluto shows as background, which it is; but it is also azimuth 87° 33' and should show as Av in the G field.

This should be fixed now.

The pinned taskbar shortcut problem of the last two alpha versions didn't occur this time.

This is still odd and I don't currently have any theory about it. Let me know if you see it pop up again and I'll investigate the most recent suite of changes to see if it could possibly be related.

I think I'm caught up with bugs, besides that, and figuring out why the sub-title text is so much smaller for you than it is for me... but let me know what broke this time!

Inch by inch... Thanks for all this work and progress.

It always is with software, especially with any "first release" type of deal, this being my first TM release with actual new content and real refactoring/tightening. I'm hopeful that I've mostly gotten these bugs under control, and we're getting closer to this being a stable release. Thanks for bearing with me

[Jim Eshelman]

Had to leave home before 5:30 this morning but did get 8t installed (Will put on my personal laptop at work later today but it's going to be an insane first day back.) Taskbar icon issue (I'm sure that's as much a Windows issue as anything unless the installed program name is different.). Had time to confirm the Vx display and I'm sure you caught the ingress matter (I'll check all later).

[Jim Eshelman]

Installed on the other laptop.

Ingresses: I get no aspects in the 2024 Capsolar for Washington with the default ingress "1+ FG" settings. I should get two Moon aspects and the Jupiter-Pluto mundane square IIRC per this:
viewtopic.php?f=32&t=8452

Upcoming Cansolar correctly marked dormant.

Next October's Libsolar has no aspects marked even though I know there are several. If I mark to show all partile (while still on 1+ FG), I get Class 1 and Class 2 Moon aspects. If I pick All (with partile picked), I get two planet aspects, Sun-Mars (should not have shown before on 1+) and Venus-Uranus (should have shown before since both are foreground. If I leave on ALL and uncheck Show Partile, I get the same aspects.

(Too much going on here at work for me to filter out these behaviors so I'm just dumping the observations. The 2024 Libsolar looks like a reasonable test chart.)

OTOH (as a measure of progress), the 2024 Libsolar correctly identifies Sun as on Vx which lets me scan Sun-Pluto azimuth (2°15' PVP square) and Sun-Uranus ML (1°43' PVP square if we allow it for Uranus > 3° from horizon). Regrettably, both of these aspects show the overthrow of a seated president. Nonetheless, the ability to see these at all - and without extra software or special calculations - is cool!

[Mike V]

Ingresses: I get no aspects in the 2024 Capsolar for Washington with the default ingress "1+ FG" settings. I should get two Moon aspects and the Jupiter-Pluto mundane square IIRC per this:
viewtopic.php?f=32&t=8452

Next October's Libsolar has no aspects marked even though I know there are several. If I mark to show all partile (while still on 1+ FG), I get Class 1 and Class 2 Moon aspects. If I pick All (with partile picked), I get two planet aspects, Sun-Mars (should not have shown before on 1+) and Venus-Uranus (should have shown before since both are foreground. If I leave on ALL and uncheck Show Partile, I get the same aspects.

Ahh, now I'm seeing what you're seeing. I completely forgot that ingresses and natals were using separate sets of options. (Sounds obvious when I say it, but I've never done work with ingresses before; their options weren't really on my radar as a distinct thing.) I'll take a look this evening and figure out what's going on.

[Mike V]

This discussion is reminding me of the usefulness of unit testing. At some point between this release and the next one (and possibly as a patch release, which users shouldn't detect any difference in), I'll start making test cases for all of these types of things. This should make future changes less volatile and less reliant on spot testing.

[Mike V]

Okay, here's a 6th alpha iteration. I figured out why aspects weren't showing in ingresses - it had to do with me dropping a place where planets got included in a list of foreground planets; when we checked it later to see if aspects should be included... of course they all got eliminated, since the list was empty. This should be fixed now.

Next October's Libsolar has no aspects marked even though I know there are several. If I mark to show all partile (while still on 1+ FG), I get Class 1 and Class 2 Moon aspects. If I pick All (with partile picked), I get two planet aspects, Sun-Mars (should not have shown before on 1+) and Venus-Uranus (should have shown before since both are foreground. If I leave on ALL and uncheck Show Partile, I get the same aspects.

What orbs do you use for ingress aspect classes? I am reproducing the behavior that you're seeing, I think - but I'm not totally clear on what the expected behavior should be with 1+ FG, "all partile" not checked (except that it should ignore non-foreground, non-Moon partile aspects). I compared my current code to the previous (around 0.4.13) relatively untouched code, and the behavior of aspect classes looks pretty much the same, from what I can tell.

https://mega.nz/file/8O9VRThT#0x6tChsDR ... xqiN3MIq9o

[Jim Eshelman]

Installing A6 at work now. Half-way through I got a surprise box asking if I wanted to repair or remove TM, I went ahead and told it to repair, will report on what happens next.

I'll write up something when I get time about the whole aspect-variation. To answer your one specific question, though, for ingresses I'm currently using 3° Class 1 orbs for conjunction, opposition, and square, ecliptic matching mundane. I've added 4° orb for conjunctions and oppositions (since that's what the original research in SMA used, and that's where the con/op curve tapers etc. etc.). For ingresses I want "1+ FG" meaning at least one planet foreground (but not requiring both).

[Jim Eshelman]

It looks like it installed. Alpha 6 running on this box. Current DC Capsolar has all the aspects I expected. Upcoming Cansolar correctly marked dormant and correctly shows lunar aspects anyway. Upcoming Libsolar seems right with two Class 1 Moon aspects (and one Class 2 3°46' Moon aspect) and the foreground Venus-Uranus.

[Jim Eshelman]

I'll summarize how the aspect options are intended to work and try to anticipate the questions or unclarities that might help you. (One of my firm's post-Covid, mixed-presence slogans is, "make the implicit explicit" - so I'll try to do that here.)

Besides setting individual orbs from ecliptical and mundane aspects, per aspect, per Class, the chart options offers four aspect options: All; 1+ FG; and 2 FG; plus a check box for Partile (meaning all partile, even if not caught in the others).

ALL means all aspects defined in the table. This is the standard selection for natal charts since generally want to see everything (and aspects in all parts of the quadrant are important). (As with all of these, however, the user can make modifications, create special purpose option lists, etc.)

1+ FG Means at least one of the planets is foreground (1+ for "one or more"). This is the default select for ingresses because, while we primarily want only aspects where both planets are foreground, there is abundant evidence that non-fore planets aspecting foreground planets have a supplemental effect. (Tactically, I read these by ignoring them until I read the fore-to-fore stuff, to get the main thrust of the chart, then make room to consider the fore-to-non-fore in ways that don't contract the first layer.)

2 FG mean both planets in the aspect are foreground. This is the default setting for return charts because (with the exception of the "partile rule") returns behave like non-foreground planets aren't even in the chart.

Partile. This check box means that any partile aspects defined in the orbs table will be listed in an "Other Partile Aspects" column if they do not mean the requirements of the option picked above; e.g., if at least one planet isn't foreground for "1+ FG" or if either planet is not foreground with "2 FG." - I don't think this has a practical use for ALL, though in theory someone could (for example) set a half-degree or for Class 1, and no wider orbs. (I doubt anyone ever will do this, though it is a good enough reason not to disable the box if ALL is selected.


The other main consideration is that ingresses and solar (but not lunar) returns have a different behavior than natals and lunars: For all ingresses and for solar returns, Moon aspects are always shown (whatever aspects are defined in the orbs definition table).

I think those are all of the main points though, of course, ask any questions.

[Jim Eshelman]

Hey, you fixed the aspect separator items? (I missed you saying that.) My current SSR has them properly divided:

Code: Select all

    Class 1 Aspects         Class 2 Aspects      Other Partile Aspects  
tMa sq tPl  1°24' 96%   tMo co rPl  3°19' 54% M  tVe op tSa  0°47' 97%  
tJu sq tPl  2°28' 88% M                           ----------------------
----------------------                           tMa sq rMa  0°11'100% M
tMa sq rJu  0°36' 99%                            tMa co rNe  0°31' 99% M
tMa sq rUr  0°53' 98%                             ----------------------
tJu op rMe  1° 2' 95%                            rVe sq rPl  0°13'100%  
tJu op rVe  2°48' 67% M                          rMa sq rNe  0°20'100% M
tJu sq rJu  1°51' 93% M                                                 
tJu op rSa  1°31' 90% M                                                 
tJu sq rUr  2°14' 90% M                                                 
tUr op rVe  2°11' 80% M                                                 
tPl sq rMe  2° 3' 92% M                                                 
tPl op rJu  0°37' 98% 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' 75%                                                   
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 

Same with my current SLR (for Wright City, OK):

Code: Select all

    Class 1 Aspects      Other Partile Aspects                          
tMa sq rMa  0°25'100%   tSu co tVe  0°46' 97% M                         
tMa op rNe  2°50' 66%   tMe co tUr  0°40' 98%                           
tPl sq rSu  1°52' 93% M  ----------------------                         
tPl op rJu  1°54' 84% M rMe co rSa  0°43' 98% M                         
tPl op rUr  2°21' 76% M rVe sq rPl  0°13'100%                           
----------------------                                                  
rSu sq rJu  0° 2'100% M                                                 
rSu sq rUr  0°29'100% M                                                 
rMa sq rNe  2°25' 89%                                                   
rJu co rUr  0°17'100%                                                   
rJu sq rNe  2°16' 90%                                                   
rUr sq rNe  2° 0' 92%

[Mike V]

Hey, you fixed the aspect separator items? (I missed you saying that.) My current SSR has them properly divided...

Yep! Here's my spiel again because I think it's amusing:

Biwheel aspect table should be fixed. I spent like 2 hours figuring out what it was and it was so dumb you would not believe it. (I changed array indexes in a lot of places when I added meridian longitude to the data table. One of those places was not actually related to this at all. End result: every aspect was its own entire type of aspect.)

Thank you for the details on ingress behavior; I'll re-review when I'm a little more awake. I'm glad that it seems like things are stabilizing.

[Jim Eshelman]

Just installed at home. All looks good.

I've lost track: Have we squashed all the bugs and the coast looks clear?

[Mike V]

I think so, yes! I'll need to double check. I also did want to try to fix vertical scaling in this release, although it can wait.

If you're comfortable with this release being 0.5.0, I can rebuild it with the version updated (without the alpha tag) and we can move on from there.

[Jim Eshelman]

Let's go!

Start a new thread to replace the 0.4 one and I'll mKe it a top level post.