TMSA 0.5 Preview Release

[mikestar13]

Here is my chart with zero suppression, with the exception that zeros in the tens column of minutes and seconds of times in the hh:mm:ss format are retained, which is the usual custom at least in the US. Working on the other changes.

Code: Select all

 +-------------14Aq42-----------20Cp41----------- 1Cp58--------------+
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |Ve 14Pi13 25° 2 |                |                |                |
 |Su 17Pi32 26° 8 |                |                |                |
 |                |                |                |                |
 23Pi33-----------+----------------+----------------+-----------11Sg19
 |                |                                 |                |
 |Me 29Pi41  3°21 |                                 |                |
 |Mo  2Ar18  3°47 |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 |Er 14Pi44 14°53 |                                 |                |
 |                |                                 |                |
 |   Ep 25Ar36    |                                 |                |
 |                |                                 |Sa 20Sc 6  9°28 |
 |                |         Nelson, Michael         |                |
 |                |              Natal              |                |
 |                |     1 Apr 1957  8:23:00 PST     |                |
 |                |     Huntington Park, CA USA     |                |
 10Ta 8-----------+      33N58'58" 118W12'43"       +-----------10Sc 8
 |                |   UT 16:23:00 RAMC 317°17'55"   |                |
 |Ma 15Ta 9  2°52 |   OE 23°26'36" SVP  5Pi51'11"   |                |
 |                | Sidereal Zodiac Campanus Houses |                |
 |                |           AA from BC            |                |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |Ne  7Li37 10° 7 |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 |                |                                 |                |
 11Ge19-----------+----------------+----------------+-----------23Vi33
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |Ur  8Cn45 11° 8 |                |                |
 |                |                |                |                |
 |                |                |                |Ju  0Vi51 15°33 |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |                |                |
 |                |                |Pl  4Le 7 28°11 |                |
 +------------- 1Cn58-----------20Cn41-----------14Le42--------------+
 
--------------------------------------------------------------------------
 Pl Longitude   Lat   Speed    RA    Decl    Azi     Alt     PVL    Ang FG
 Mo  2Ar18'11"  2N 4 +12°30'  23°46' 12N 8  92°48' +26°11' 333°47'   4%  b
 Su 17Pi31'46"  0  0 +59'12"  10°44'  4N37 108°19' +32°30' 326° 8'   1%  b
 Me 29Pi40'55"  0N35 + 1°56'  21°50'  9N48  96° 8' +26°31' 333°21'   3%  b
 Ve 14Pi13' 7"  1S22 + 1°14'   8°13'  2N 4 112°33' +32°51' 325° 2'   2%  b
 Ma 15Ta 8'36"  1N14 +37'44"  67°24' 23N 4  59°52' - 2°29'   2°52'  98% A 
 Ju  0Vi50'53"  1N33 - 7'12" 176° 1'  3N25 307°49' -37°46' 135°33'  14%  b
 Sa 20Sc 5'56"  1N49 - 0'52" 253° 8' 20S42 238°15' + 8° 4' 189°28'  77% D 
 Ur  8Cn45' 1"  0N37 - 0'28" 125°20' 20N 7  13°42' -34°43'  71° 8'  30%   
 Ne  7Li37'12"  1N48 - 1'31" 210°14' 10S24 270°43' -19°53' 160° 7'  25%   
 Pl  4Le 6'55" 11N23 - 1'01" 154°40' 22N43 341°16' -30°56' 118°11'  44%   
 Er 14Pi43'47" 23S 6 + 0'42"  17°29' 17S40 121°59' +12°54' 344°53'  49%   
 --------------------------------------------------------------------------
 Created by TMSA 0.5.0.0 (26 May 2022)

[Jim Eshelman]

Ah, that explains the difference. OK, I'm good with that. At least getting the INITIAL 0 gone adds to readability - I still could argue the "before the minutes" either way.

[mikestar13]

More detailed descriptions of zero-suppression:

For degrees, convert zeros in the tens and hundreds places to spaces, for degrees, minutes, and seconds if present: 6° 4' 2"
For time, convert a zero in the tens place to a space for hours only: 6:04:02

Agree 0 0 looks weird and confusing. By the conventions I am aware of, exactly 0°0'0"" latitude is arbitrarily designated N (since N is positive when expressing latitude in +- form: +0 vs -0 as it were); likewise exactly 0°0'0" longitude is arbitrarily designated E.

[mikestar13]

Still working on chart options and then on to implementing cycloid curve angularity, and redesigning aspect and midpoint calculation. In the interest of getting version 1.0 out sooner, I am going to postpone the export as .csv feature to version 1.1.

[mikestar13]

Slow going with coding, life is in session. My original guess of a July 4 release looks more reasonable than mid-June (which is to say now).

[Patrick Machado]

This is the output for my June 17 SLR's aspects:

Code: Select all

    Class 1 Aspects         Class 2 Aspects      Other Partile Aspects  
tMo co rMe 02º12' 86%   tPl co rMe 04º23' 48% M  tSu sq tNe 00º27' 99% M
tMo co rUr 02º43' 80%   tPl co rUr 03º55' 58% M  tVe sq tSa 00º30' 99% M
tPl co rNe 01º18' 95%                             ----------------------
----------------------                           tMe op rPl 00º17'100%  
rMo co rMe 01º00' 97% M                           ----------------------
rMo co rUr 01º28' 94% M                          rMa sq rPl 00º27' 99% M
rMe co rUr 00º28' 99% M                                                 

Do we want these transiting Moon aspects to appear? This discussion had me thinking that we didn't.

[Jim Eshelman]

This is the output for my June 17 SLR's aspects:

Code: Select all

    Class 1 Aspects         Class 2 Aspects      Other Partile Aspects  
tMo co rMe 02º12' 86%   tPl co rMe 04º23' 48% M  tSu sq tNe 00º27' 99% M
tMo co rUr 02º43' 80%   tPl co rUr 03º55' 58% M  tVe sq tSa 00º30' 99% M
tPl co rNe 01º18' 95%                             ----------------------
----------------------                           tMe op rPl 00º17'100%  
rMo co rMe 01º00' 97% M                           ----------------------
rMo co rUr 01º28' 94% M                          rMa sq rPl 00º27' 99% M
rMe co rUr 00º28' 99% M                                                 

Do we want these transiting Moon aspects to appear? This discussion had me thinking that we didn't.

Looking over what we have here:

First, the two Moons are foreground, so this is a "foreground to foreground" aspect, not a "we always want Moon aspects" thing.

But the two transiting Moon aspects are wider than the natal Moon equivalents - at least, in this chart where natal Moon has tighter mundane orbs.

Transiting Moon's ecliptical orbs, of course, are exactly the same as those of natal Moon. The only difference is in mundo, where (in the framework of the SLR) natal Moon is closer than usual and transiting Moon is wider than usual.

So I'm not sure why the transiting aspects appeared - under the rule of, "in a lunar return there is no transiting Moon unless it distinguishes itself by being closer in mundo." If I saw them on a printout, I'd just look past them, of course, but ideally they shouldn't be there.

[mikestar13]

This will definitely be fixed in version 1.0. When I rewrite the aspect and midpoint routines, Solar aspects in Solar returns and Lunar aspects in Lunar returns and Anlunars will special cased so that ecliptic aspects of the transiting luminary are never listed, and the mundane aspects (and parans if selected) will be listed if closer than the strongest SThGscorresponding aspect to the radical luminary. I was trying to do this with version 0.4.7, but the implementation is imperfect. The secret is to calculate the radical luminary aspects first then save them, and add aspects by the transiting luminary if and only if they are closer than the aspects to the radical luminary. In 0.4.7 I add transiting luminary aspects to the list and try (not fully successfully) to comb them out later.

[mikestar13]

This will be slightly more sophisticated than Jim's class handout: transiting Sun doesn't exist in a SSR, transiting Moon doesn't exist in a SLR. If a mundane aspect of the transiting luminary is closer than the corresponding aspect of the radical luminary, it will be noted. The tighter orb may have interpretive significance, though the aspect per se won't. "Does not exist" would be simpler to program.

[Jim Eshelman]

I know "doesn't exist" would be easier to program and, btw, that works for Sun in full and demi-SSR (but not in quarti or Enneads).

Unfortunately, I've seen too many examples where natal and transiting Moon latitude is quite different and, therefore, their angularity or mundane aspects are different. It's hard to forget charts like Arena meeting the love of her life with SLR Moon partile conjunct natal Sun (when no such aspect, ecliptically or by natal Moon, exists), and my suggesting that a significant new relationship might be popping up. (Or something like that.)

[mikestar13]

Agree, too much would be missed. Does not exist is a reasonable approximation if and only if you are only using ecliptic aspects.

[Jim Eshelman]

Mike, an inquiry on planetary speed. (You may not have an answer, but you might.)

My father, John Eshelman, was born October 22, 1929, 5:30 PM, Rochester, IN. Solar Fire 8 shows Pluto's motion as -0°00'22". TMSA shows it as -0°00'03".

The reason it caught my eye, of course, is that I was scanning to see if anything was stationary. I hadn't previously noticed him having a stationary Pluto. For most purposes, it doesn't matter, but OTOH this seems like a big difference and could certainly affect identifying stations.

The other speeds are a match between TMSA 0.4.7 and SF 8 within one unit of arc. Pluto surprised me, though.

Animating Dad's chart in SF, it displays as stationary on October 20-21. At that point, TMSA also shows motion 0'00", so it seems the converge at or near the station.

[mikestar13]

Not sure about this. Speed is calculated directly from the SE, neither TMSA nor Solar Fire do anything to it except express it in dms form. I will search the SE documentation.

[Jim Eshelman]

It's probably just an SE improvement, then.

[mikestar13]

I just checked. Per TMSA, Pluto doesn't reach -0' 22" speed until 11/4/1929. I also reviewed all my Swiss Ephemeris interface code for correctness. BTW I use a SE flag that uses very accurate speed calculations. Perhaps Solar Fire doesn't? The inaccuracy would be near nil for planets in most of their orbits, but would be most noticeable for slow moving planets near station!

[mikestar13]

Btw, I have simplified error reporting for unexpected errors, reformatting and simplifying the message displayed, eliminating lines that refer to internal Python dynamics and showing only source code, thus making it easier to post bug reports, and easier to read them. A recent example:

Code: Select all

Traceback (most recent call last):
  File "C:\TMSA-1.0\src\planet_options.py", line 52, in dignities
    DignityOptions(self.name, self.retdict, self.finish_di)
  File "C:\TMSA-1.0\src\planet_options.py", line 70, in __init__
    self.dignities[i].append(checkbutton(self, "", 6 + i * 1.5, i + 2, 1.5))
NameError: name 'checkbutton' is not defined

And I can instantly see that I should have capitalized Checkbutton. BTW, the error file is currently C:\tmsa_errors\error.text, but I'm relocating it to (TMSA folder)\errors\error.txt.

[mikestar13]

I have also added a header line with date and time:

Code: Select all

TMSA 1.0.0 20 Jun 2022 15:00:21 error:
 Traceback (most recent call last):
  File "planet_options.py", line 52, in dignities
  File "planet_options.py", line 71, in __init__
NameError: name 'checkbutton' is not defined

Now error listings are appended to the file (which the user can rename or delete if the file gets too long). Note when an error is printed when it occurs in running the compiled executable, the actual source code is not printed, but the filename and the line number are, allowing me to find the error easily.

[Jim Eshelman]

Mike, does SE have a standard function for planetary distance values?

Cosmobiology (at least for a time) made heavy use of planetary distance values. It never caught on with anyone else. Every planet was scored on a 0 to 100 basis for its distance from Earth compared to its minimum possible distance from Earth (score 100) to its maximum (0).

I don't know if there is anything to it. If pressed, I'd say there probably isn't. OTOH, the work I did on retrogradation today seems to suggest that, if there is anything to retrogradation (big if), it is a strengthening of planetary themes; and planets when retrograde are all closer to Earth than when they are direct.

So... just curious... does SE give you a direct tap on DV?

[mikestar13]

Yes SE can does that in terms of distance from the Sun in AU, from which a percentage can be calculated, given a list of max distances.

[Jim Eshelman]

I'm not sure where to get min and max. I'll keep my eyes open. Hardly more important than so many other things.

[mikestar13]

Finally figured out how to relocate the ephemeris files, so the will no longer be required to be at C:\sweph

[Jim Eshelman]

That's pretty cool.

[mikestar13]

I'm not sure where to get min and max. I'll keep my eyes open. Hardly more important than so many other things.

Not very important, but fairly easy to get planet by planet from wikipedia. Jupiter for example: https://en.wikipedia.org/wiki/Jupiter has Aphelion 5.4570 AU and Perihelion 4.9506 AU. So given Jupiter's actual distance in AU at the moment, it is dead easy to convert to percentage of the range. But this assumes we are measuring in terms of distance from the Sun. The min max of distance from the earth is a PITA. It's not as simple as adding 1 AU to the aphelion and subtracting 1 AU from the perihelion--accurate calculation also requires knowledge of the angle between Jupiter's perihelion and Earth's which of course changes over time.

[Jim Eshelman]

Jupiter has Aphelion 5.4570 AU and Perihelion 4.9506 AU. So given Jupiter's actual distance in AU at the moment, it is dead easy to convert to percentage of the range. But this assumes we are measuring in terms of distance from the Sun. The min max of distance from the earth is a PITA. It's not as simple as adding 1 AU to the aphelion and subtracting 1 AU from the perihelion--accurate calculation also requires knowledge of the angle between Jupiter's perihelion and Earth's which of course changes over time.

Yeah, it's the geocentric distance that matters. If you have the helio difference, the geo distance should be trivial - just a simple triangle with Sun, planet, and Earth at the points. It's plane geometry.

But figuring out the least and greatest Jupiter distances possible would be tedious. (I suppose it's Earth's aphelion + planet's aphelion for max, planet's perihelion minus Earth perihelion on the minimum, if these figures are stable enough.)

[mikestar13]

I doubt the figure are stable. The distances themselves shift over time as do all orbital elements. They could be simplified by assuming the min max distances at a certain epoch (say Jan 0, 2000) are fixed for all time, but that will be increasingly inaccurate for ancient dates.

[Jim Eshelman]

True. The effective question (since it's a 0-to-100 scale) is whether the min/max would shift enough to affect the result by 1%. It probably would be stable since orbital shifts would have to be quite large, e.g., the Earth orbital distance varying by about a million miles. That seems like a lot.

[Jim Eshelman]

Small layout request:

On the Select Chart page, whatever chart is currently selected appears at the top; but one has to know the program to know that.

I suggest putting (all caps, bold if possible) put something like SELECTED CHART: on a line above the selected chart. (There's plenty of vertical room on the page.)

[Jim Eshelman]

Cosmetic simplification:

On the front (splash or home), the Solunars links don't need the https://. If you start typing them in a browser address bar (or even a Run box) starting with the www, the browser handles it fine. This might simplify the look. (Probably works for the gnu.org link, too, but I didn't test it.)

[mikestar13]

IIRC, the python code which launches the browser doesn't do that, but I'll try it.

[mikestar13]

It does work so I will change the opening page accordingly.

[mikestar13]

Got planet options working (including dignities) on to angularity.

[mikestar13]

Well I didn't make the fourth of July estimated release date. For the last week I've been fighting a nasty bug in one of the new chart options forms. The problem is this. If an error occurs in the Python code itself, the interpreter states the error and ***where in the source code the error is***,but this error is throw by the Tkinter Graphics toolkit which doesn't identify where the error occurs. I've being tying my mind in knots trying to find it, so much so that I needed to take a couple of days off from coding to clear my head. I will need to go over the form one line at a time till I find and squash the bug. After that, I need to write the new aspect forms, update the code for the aspectarian and the cosmic state report, add any last minute touches, rewrite the help files, test, test, test,and build the install. I think we are looking at August 1st.

[Jim Eshelman]

I'm glad you haven't been fighting nasty bug in your body at least! While I'm very eager to see what you've been working on so diligently, we can be patient - there are other threads starting to pop up on using the existing version.

[mikestar13]

I'm now devising the Aspect Options page which may be subdivided into ecliptic and mundane aspect pages if space requires. There will also be options for parans of two classes: major angles only and those involving minor angles, with class 1, 2, as 3 orbs. Jim, Steve, anyone, what would you suggest for the maximum allowable orb? Fairly sure it's less than the 15 degrees I allow for major ecliptic aspects. Perhaps the 5 degree maximum I allow for minor ecliptic aspects? Of course most of us will use narrower orbs. Parans will be off by default so I don't need sensible default values.

[Jim Eshelman]

If you can keep mundane and ecliptical aspects on the same page, that would be great, since (though different) they are related (in the sense that I pick one in relation to what I'm picking for the other, so it's good to see what's there). - But, of course, do what you have to do.

There will also be options for parans of two classes: major angles only and those involving minor angles, with class 1, 2, as 3 orbs.

Classes 1-3 orbs for parans is a novelty with flexibility I don't think any other software allows. I can see a practical reason for two classes since sometimes we look at them as "I want this within 1° but one could argue that each planet can be 1° from the angle, so a second layer of allowing 2°.

I guess the whole vision for allowing three classes is that some Siderealists - Ken Bowser and those who train with him, in particular - that use parans as their mundane aspects the way I use PVL aspects, so they might want full large-orbed options. No reason not to give it to them (and, hey, it's always possible we want that option at some point, too).

Jim, Steve, anyone, what would you suggest for the maximum allowable orb? Fairly sure it's less than the 15 degrees I allow for major ecliptic aspects. Perhaps the 5 degree maximum I allow for minor ecliptic aspects? Of course most of us will use narrower orbs. Parans will be off by default so I don't need sensible default values.

You mean for parans? If you're going to go the full development of allowing three classes, I don't see a justification for limiting them any more than ecliptical aspects.

In practice, I'll probably list Class 1 only (1°) but maybe (at least sometimes) but a Class 2 of 2° in. But if I decide to contrast how PVL vs. paran shows as mundane aspects, I'll likely do at least a full Class 1/2 matching my eclipticals (and maybe the same for Class 3). Bottom line, I tend to vote against unnecessarily limiting things.

[SteveS]

Mike asked:

Jim, Steve, anyone, what would you suggest for the maximum allowable orb?

When I was first introduced to Parans, I asked Matthew what constituted the proper definition of a Paran. Matthew told me two or more planets mundane position had to be bodily (?) on the angles by 1 degree or less. I really did not fully understand Matthew’s explanation how to view or calculate a Paran since this was before I knew how to cast a mundoscope with a computer program. Later when I joined Jim’s Solunars Forum, Jim taught me how to cast and view a true mundoscope using Solarfire option of Z-Analogue Prime Vert.

So, using Matthew’s definition of a Paran with a Planet being bodily on an angle 1 degree or less: When I view a Solarfire Mundoscope (Z-Analogue Prime Vert) I need to see two or more Planets partile (1 degree or less conjunct a Z-Analogue Prime Vert scope angle. This means I need to see the numbers of 29 or 0 for two or more planets on the Z-Analogue Prime Vert scope angles to know the Planets are actually partile (1 degree or less) conjunct an angle , correct Jim?

To me—this simply means two or more planet’s mundane position must be partile conjunct a chart’s angle, or in other words, “Partile aspects Reign Supreme.” I have always included a planet partile conjunct a chart’s angle in mundo as a powerful aspect within itself—being in its most powerful position on a chart. Therefore, when I see two or more planets partile mundo conjunct a chart’s angle, I believe as Fagan, we are seeing/feeling the most powerful aspect known in astrology, a true Paran.

Mike-Jim, I leave it to you two to sort this Paran business out with TMSA, awaiting to understand what true Paran orbs I am seeing/optioned with TMSA.

[mikestar13]

Though I suspect few will use orbs that wide, I will allow major angles parans up to 15 degrees and minor anlge parans up to 5 degrees, exactly the same as elliptical and mundane aspects, A redesign of Select Chart page isn't hard. I will take your suggestion.

[mikestar13]

As you may have inferred from my posts in other threads, my work on TMSA 0.5 (now rechristened 1.0) has been on hiatus while I dealt with other things. It's one of the pitfalls of a one person programming team. Today I am coding in earnest, writing the last option page.

To Do:

1. Redo the aspect code and include parans.
2. Make some tweaks to the Cosmic State report.
3. Rewrite help files.
4. Test, Test, Test.
5. Make sure I haven't forgotten anything planned for this version.
6. Build the install and release.

Can't predict the time frame. But I would assume before October. Got some really heavy s*** out of my psyche, and come to terms with much that won't come out on this side. My name is Michael, from the Hebrew Micah-El the Image of God. By the grace of God I am a survivor, an astrologer, and a programmer. In can think of few better trinities and many worse.

[Jim Eshelman]

This is so ambitious! (I knew you could do three things at once.)

But... before October? Ah, nice for my birthday but you have my appetite well-whetted even for small improvements I know you already have completed - but I know this redesign is a big, important thing to you for 1.0.

BTW, my preferred translation of Michael (Heb. Miykha'el) is "[he who is] like unto God." A wider, more inclusive meaning. The Hebrew preposition k- means "like" or "as," the initial miy is an interrogative usually meaning "who?", so MY-K-AL is literally, "Who [is the one that is] like God?" Perhaps too immodest sounding on first pass, but, hey, he led the celestial hosts in the war between heaven and earth and personally wrestled Satan into the pit, so there you have go. (Buy him a beer.)

[SteveS]

Mike wrote:

By the grace of God I am a survivor, an astrologer, and a programmer.

Indeed you are Mike!

[mikestar13]

Indeed I've seen several translation all of which have the same general meaning. I choose the one I feel the most fitting for the shape of my soul.

[Jim Eshelman]

Thread deprecated at Mike's request, with continued discussion moving to the TMSA 1.0 thread.

[mikestar13]

Thanks, Jim