TMSA 1.0 progress

[mikestar13]

I'm back to working on TMSA 1.0 and am making improvements to the 0.4 codebase. The last change just finished today has a new way of finding the tmsa charts and options. First, the environment variable TMSA_PATH is checked. The value if set is the full path to the tmsa folder. So for example mine is D:\documents\TMSA, it would be possible to use a different folder name if desired such as C:\astrology. You only need to keep your charts in your documents folder if you wish to, but of course most users will. Mine is on a removable drive backed up to the cloud (not in the user documents folder), thus ready to transfer to the new computer whenever I get that worked out. If TMSA_PATH is not set, TMSA finds the users document folder and the path will be (document folder)\tmsa. On a new installation the tmsa folder and its subfolders (charts, options, and errors) are created. It's perfectly possible to store other files/subfolder in your tmsa folder, as tmsa only uses these three subfolders. On the rare system where TMSA_PATH is not set and the documents folder can't be found, the TMSA folder will be at C:\TMSA.
I've found a workaround for the finding timezones. Timezonefinder 6 depends on h3 which I can't build (I'm consulting with our other Python programmer named Mike about that), however the almost as good timezone 5 finder does not! I will also look into timezone finding from TMSA directly from Uber's web page, which will assure the timezone info is up to the minute current.

The 0.5 Preview thread is getting awfully long, and is now not accurately titled as the upcoming version is 1.0 now. I will announce progress in this thread from time to time, and all other discussion of version 1.0 is order. Jim you may wish to demote the 0.5 preview thread to a regular thread.

[Jim Eshelman]

Good to hear about the progress. Demotion in progress!

[mikestar13]

A productive day today, wrote lots of code for the aspect and midpoint listings. The framework is in place for enumerating all the bodies in up to three wheels in correct order. I'm in the midst of writing the code for checking what aspect if any is in effect for each pair of bodies such as trMa and rSa.

The procedure:

1. Check for any ecliptic aspect, save the aspect and strength score.
2. Check for any mundane aspects, and one exists if it is stronger than the ecliptic aspect (if it exists), save it.
3. If the user has not enabled parans, goto step 5.
4. Calculate the parans that exist (if any) and choose the one with greatest strength. If this stronger than the stronger of the ecliptic and mundane aspects, save it.
5. Return the saved aspect or return "no aspect" if none were saved.

Of course at each step I'm checking if Eris and Sedna are in use and which version of the Node (if either). The aspectarian and midpoint code is the most complex I'll need to write, but it is much better organized and hopefully more efficient than the code in 0.4, though TMSA calculates a chart so fast I doubt anyone will notice one way or the other.

I had a fairly lengthy dark night of the soul about TMSA, but I seem to have much of my old fire back.

[Jim Eshelman]

"Joy turned to ashes" followed by "The Return of the Phoenix," aka, Resurrection

Almost a digression because you probably have this in your mind, but: This complexity raises the question of what the base chart is (for use as a root epoch for precessional matters and the operational geographical coordinates).

[mikestar13]

"Base chart" is my generic term for the chart that is the base from which other charts, transits, progressions, or directions are derived. Normally it will be a nativity or event chart, but it might be an SSR (anlunars, SQ, PSSR) or an ingress, or any chart the user is calculating a novien for. I might have called it "root chart".

As for "The Return of the Phoenix" event, if I thought it were significant enough to constitute an actual new birth, I would treat a chart of the moment as the base chart. However, though it's important, I don't regard it as quite that important.

Noel Tyl wrote a delightful short story "The Case of the Missing Moon" about an astrologer who at end of the story cast as new birth chart for himself at the time of a life changing event. https://books.google.com/books/about/Th ... svDwAAQBAJ

[mikestar13]

I have the last Chart Option page (aspects) written covering ecliptical and mundane aspects and parans, the former two enabled by default, the last disabled. Managed to get everything on one page.

[Jim Eshelman]

Whee! - How soon before we get to start playing with it?

[mikestar13]

Not at all sure but I'm aiming at late this month/early March.

[mikestar13]

After consideration, I've decided not to implement Bradley's cycloid curves for angularity and aspects. For aspects, I'm simply convinced that the sinusoidal curve is correct. For angularity, cycloids put the background in the wrong place for natals and solunars (mid-quadrant rather than cadent cusp) and give different %strength values for the edge of the foreground(10°). And that's just the major angles, I've no idea about minor angles. Possibly after a month or two of studying cycloid curves thoroughly, I might be able to tweak Bradley's cycloid model, but even so, there would be considerable complication in the code.

I'm not willing to put that much effort into a model that (with due respect to Bradley) I'm convinced is erroneous.

Good news: I will have the ability to cast the novien of any chart in 1.0.

[Jim Eshelman]

I'll remove the cycloidal items from the wish-list and archive threads about it. At this point, my only reason for wanting to see it is out of respect for Bradley and because we've never exhaustively tested it, though I have really high confidence that we would end up rejecting it. At best, it would be a low-demand feature. We can easily let it go.

And the Noviens are good news. Are you using the proposed reports in the Noviens thread? Any vagueness or uncertainty that needs discussion?

[mikestar13]

The novien report will be a much simpler version of a typical report, as the following are not considered in noviens: angularity, mundane aspects, parans, midpoints. We still could have both classes of aspects and a limited comic state report with aspects to each planet sorted by orb. I assume the wheel will be drawn in the customary Moon on first cusp equal house format, though it's quite doubtful signs are relevant in the novien, and certain that houses are not. The default for aspects I think will be class 1 major dynamic aspects class 1 at 3° and class class 2 at 5°, with class 3 not used. I'm inclined to let the user choose the orb, but not to make soft aspects available as there seem to be no indication these are valid. These options are so simple I will let the user change the orb values when the chart is cast, also allowing the choice of single wheel (just the novien positions) or double wheel (also base chart positions--usually but not always a nativity).

[Jim Eshelman]

I agree with the above. - Possible exception, some think that soft aspects are equally valid so, presuming it's no trouble to leave it in, perhaps let them dissuade themselves of this in practice <g>. - I'm working up a mock-up of what I think might make good basic tables based on the Novien brainstorming thread (almost done once I add the aspects), I'll post it on that thread when done. (It's a LITTLE overboard, but there is a lot of space.)

[mikestar13]

Thanks Jim. That will help inspire me. Soft aspects will be made available, but off by default, and I will use option files for noviens as well.

[Jim Eshelman]

I've shown the first four Noviens of Moon and Sun (it fills out the space) but these should probably be off by default, too.

[mikestar13]

The problems with timezonefinder continue. On Windows 11, loading it causes the Python interpreter to crash with a null pointer exception. Previously versions of TMSA built on Windows 10 will still run on Windows 11, but I can't built or test a new one unless I disable the timezone lookup feature (latitude and longitude lookup use a different library and aren't affected. The world clock website allows users to lookup up timezone information by lat and long for dates 1/1/1970 and after. I can automate the process of querying the site and have the page with start/end dates, but user would have to fill in the time zone fields in TMSA manually. I hope this is not a dealbreaker.

[Patrick Machado]

For what it's worth, that feature is not a necessity, let alone a priority, for me.

[mikestar13]

I'm doing maintenance on my offline storage today. I've removed the downloads for TMSA versions prior to the current one (0.4.2) and I hereby withdraw the from circulation.

[mikestar13]

Found an online DB that only wants $5/month for premium service. I will be setting up a free account to test it. Given coordinates, date and time, it returns timezone info in .json format, which Python has no trouble parsing.

[mikestar13]

I'm doing maintenance on my offline storage today. I've removed the downloads for TMSA versions prior to the current one (0.4.2) and I hereby withdraw the from circulation.

Typo in he above, current stable version is 0.4.9.2

[mikestar13]

The online time zone DB I'm working with looks like it will do the job. While I'm developing my free account will give me enough queries and then some, but when it's time to release, solunars.com will need to pay the $5/month for premium access which says no limit on queries. This page gives details: https://timezonedb.com/premium

[Jim Eshelman]

Deal.

Please let me know when you need me to take this step. I'm also unclear how an account/purchase I make gets linked to TMSA (e.g., does it need to have an account name to embed etc.? - this will determine how I set it up).

[mikestar13]

Will do, I'll find more info when it gets closer to release, during development and testing, my free account key is more than enough. The procedure seems simple enough: you would purchase a $5 monthly subscription and receive a key, which you will send me via PM, so I can embed it the TMSA code, in lieu of my free code, which I will retain as a fallback in case the subscription should ever lapse. Lookup would still work, but lookups would be limited to one per second, all users world-wide. No apparent limit on total number of lookups. I will contact them and make certain I understand the terms correctly. Maybe my free key would be adequate for a while until user base grows a bit. The issue is not total number of lookups, but how many users will attempt to look up a location in the same second. My impression is that timezonedb is intended to be a free service, with heavy users subsidizing their costs.

[Jim Eshelman]

I think the free one is fine for the near future. The $5/mo isn't a problem, I'll sign up at once when needed, but I don't think we'll have that demand for a little while. (Once 1.0 is out, we need to talk about more aggressively circulating it.) I also wish we could get you a security certificate that would end Windows treating it like a suspicious program.