PRIORITY WISH LIST - Add Angles to data table
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
PRIORITY WISH LIST - Add Angles to data table
Mikestar13 and I collaborated on a format for adding lines for the angles at the bottom of the planet data table, including only select information that is relevant to each. The full thread is an interesting read to see how this got sorted out viewtopic.php?f=60&t=8504 - nonetheless, I'm going to edit this copy of that thread to reflect the final outcome.
Goal: Add lines (after the planets) for MC, As, EPa, and Vx. Only show Vx line if the Vertex option is picked in the chart options. Don't populate every column, only those columns that (1) are meaningful or useful for the angle in question and (2) don't cause misunderstanding or a problem by being there.
After this is done, remove EPa and Vx from display on the face of the chart. (Mike N always questioned why we wanted them there when the really meaningful information was always in the angularity columns. Adding these lines to the data table resolves the need for them on the chart face and makes current code unnecessary that handles EPa and Vx display differently from everything else.)
Some key points of discussion/agreement and further details are in the retained posts below.
Goal: Add lines (after the planets) for MC, As, EPa, and Vx. Only show Vx line if the Vertex option is picked in the chart options. Don't populate every column, only those columns that (1) are meaningful or useful for the angle in question and (2) don't cause misunderstanding or a problem by being there.
After this is done, remove EPa and Vx from display on the face of the chart. (Mike N always questioned why we wanted them there when the really meaningful information was always in the angularity columns. Adding these lines to the data table resolves the need for them on the chart face and makes current code unnecessary that handles EPa and Vx display differently from everything else.)
Some key points of discussion/agreement and further details are in the retained posts below.
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: TMSA 0.5 Preview Release
On keeping things simple, I lean toward just adding lines to the bottom of the table that's already there, with possibly excluding data as you say. In that case, I suppose MC, Asc, and EPa would always be there, and Vx added if "display" is selected for Vertex. Something like this:
Is that too complicated and crazy? (Or are some of my choices illogical and crazy on the list?)
Code: Select all
Pl Longitude Lat Speed RA Decl Azi Alt PVL Ang G
MC 1Ta37'59" 0N 0 53°25' 19N12 180° 0' +75°08' 270°00'
As 5Le14' 3" 0N 0 11N42 75°50' + 0°00' 0°00'
Ep 26Cn54'45" 143°25' 90° 0' + 0°00'
Vx 19Sg51' 4" 0N 0 22S43 270° 0' -43°35'
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
-
- Sidereal Field Agent
- Posts: 943
- Joined: Thu Jul 20, 2017 2:13 pm
Re: TMSA 0.5 Preview Release
The idea to list angles in the planetary data table and leave irrelevant columns blank (and omitting Ep and Vx from the chart wheel) is so good that I hereby canonize it. We can firm up details as I code. This discussion has become an important part of the process of making 0.5/1.0 as polished as possible.
Time matters
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: TMSA 0.5 Preview Release
These are excellent points. I was giving old thinking (where the intersection with the ecliptic was critical). On altitude, Ascendant is always 0 (the entire horizon is 0). MC altitude (treated for a moment as the point of intersection with the ecliptic) is always co-latitude plus MC declination. (I only considered this because at least one participant on the site was tracking altitude conjunctions with MC in ingresses, though it didn't stand up when I tested it statistically. I don't see an actual need for it, especially because it can be calculated in seconds with data given; so... include ort exclude?)mikestar13 wrote: Wed May 25, 2022 10:59 am I'm rather dubious of listing the altitude and declination of the major angles, as they are not points, but I suppose that it is harmless to compute them. I know the RA of the Mc is highly meaningful, but what is the declination of the Mc, a great semi-circle that runs pole-to-pole? What is it's altitude?
Declination I considered only because some people want to look at parallels of declination. I don't think there is a bloody thing to them, but Ken Bowser, in his most recent book, openly uses parallels. I was being tacitly supportive of the idea of giving people all the info for checking parallels if they want, while not offering them as a tabulated aspect
This does reduce the differences in how EP and Vx are treated as: (1) EP-a angularity is always included, and its abbreviation given as an angle designation, and the Ang score affected even when the point isn't displayed. (2) Vx never affects angularity score and its abbreviation appears under FG only when its visibility is turned on. [This view later changed. It should always be in the G column.]But at any rate, this idea is becoming quite workable.
Ah! - It all simplifies out if (1) EP and Vx are never listed on the wheel, (2) MC, Asc, and EP are always listed on the table below, and (3) Vx is only listed in the table if it's turned on. -- Oh, yeah, suddenly there is no confusion with why EP-a always counts for angularity but is not on the face of the chart (because it's still always "on," but only displayed below.) The MOST useful information about EP-a/WP-a is in the angularity scores and designations of the individual planets, yet the longitude and (yeah!) RA are still there (easily seen) when needed. It also quietly gives EP the heightened status it deserves as something in active use by some of the first generation Sidereal pioneers (Firebrace and Bradley).
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
-
- Sidereal Field Agent
- Posts: 943
- Joined: Thu Jul 20, 2017 2:13 pm
Re: TMSA 0.5 Preview Release
I'm finding your no downside argument convincing. I also am convinced the items such as the RA of the As, which is easily calculated but potentially misleading should be left blank. I should have a real sample chart to post in two or three days and have a mock up to post this afternoon to look over.
Time matters
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: TMSA 0.5 Preview Release
Stupid little things sometimes lead to great big shifts that people will soon think "this is how it's always been, it makes so much sense."
This was triggered by remembering your original query on why we put EP on the chart in the first place. Now look where it's brought us! Remembering individual articles by Bradley just citing an RA square to MC, of Firebrace experimenting with different ways of displaying the same point, of American Astrology eventually adding the circled-E glyph to all published charts - it's been 60 years of trying to figure out how the damn mousetrap should look.
I think this will be better. Along the way, it shifts (just ever so slightly) the way we think about it.
This was triggered by remembering your original query on why we put EP on the chart in the first place. Now look where it's brought us! Remembering individual articles by Bradley just citing an RA square to MC, of Firebrace experimenting with different ways of displaying the same point, of American Astrology eventually adding the circled-E glyph to all published charts - it's been 60 years of trying to figure out how the damn mousetrap should look.
I think this will be better. Along the way, it shifts (just ever so slightly) the way we think about it.
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: TMSA 0.5 Preview Release
Referring to my previous posted example:
Having RA for MC and EP looks really good: It is an outright instruction that these are RA-based angles and the others are not. One could argue the same for having azimuth only for MC and Vx (it's instructive and shows a framework that they share).
By listing PVL only for Asc and MC, we get this interesting, potentially instructive balance where
Code: Select all
Pl Longitude Lat Speed RA Decl Azi Alt PVL Ang G
MC 1Ta37'59" 0N 0 53°25' 19N12 180° 0' +75°08' 270°00'
As 5Le14' 3" 0N 0 11N42 75°50' + 0°00' 0°00'
Ep 26Cn54'45" 143°25' 90° 0' + 0°00'
Vx 19Sg51' 4" 0N 0 22S43 270° 0' -43°35'
By listing PVL only for Asc and MC, we get this interesting, potentially instructive balance where
- RA has only MC and EP (which are RA-based)
- Azi has only MC and Vx (the relationship of which is measured in azimuth)
- PVL has only MC and Asc (the relationship of which is measured in PVL).
Code: Select all
Pl Longitude Lat Speed RA Decl Azi Alt PVL Ang G
MC 1Ta37'59" 0N 0 53°25' 19N12 180° 0' +75°08' 270°00'
As 5Le14' 3" 0N 0 11N42 + 0°00' 0°00'
Ep 26Cn54'45" 143°25' + 0°00'
Vx 19Sg51' 4" 0N 0 22S43 270° 0' -43°35'
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
-
- Sidereal Field Agent
- Posts: 943
- Joined: Thu Jul 20, 2017 2:13 pm
Re: TMSA 0.5 Preview Release
I like the way this is evolving. Each angle pair having two points of similarity is pleasing.
Time matters
-
- Sidereal Field Agent
- Posts: 943
- Joined: Thu Jul 20, 2017 2:13 pm
Re: TMSA 0.5 Preview Release
Here is the new planetary data section with the angles:
For now omitting the altitude of the vertex while I figure out how to calculate it. Swiss Ephemeris doesn't do it directly I need a formula.
Code: Select all
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%
Se 1Ar50'28" 10S30 + 0'36" 27°54' 0N14 100°56' +16° 8' 343°35' 43%
Mc 20Cp41'10" 317°18' 16S23 180° 0' -50°22' 270° 0'
As 10Ta 7'54" 21N 0 0° 0' 0° 0'
Ep 25Ar36' 1" 47°18' 17N41
Vx 7Li 4'31" 11S54 270° 0'
Time matters
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: TMSA 0.5 Preview Release
Ah! I've got it! Easy indeed.
Think about it: Vertex is always on prime vertical, which is perpendicular to the horizon. Its altitude (like every other point) is the distance along a great circle perpendicular to the horizon which, for Vx, means: How far is it from the horizon along the PV.
Since it's measured along the PV, it's identical with its PVL minus 180!
I just checked with SF. This is exactly right. For example, my Vertex altitude for my home (34N03'46" 118W18'47") is -43 35'.
Think about it: Vertex is always on prime vertical, which is perpendicular to the horizon. Its altitude (like every other point) is the distance along a great circle perpendicular to the horizon which, for Vx, means: How far is it from the horizon along the PV.
Since it's measured along the PV, it's identical with its PVL minus 180!
I just checked with SF. This is exactly right. For example, my Vertex altitude for my home (34N03'46" 118W18'47") is -43 35'.
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
-
- Sidereal Field Agent
- Posts: 943
- Joined: Thu Jul 20, 2017 2:13 pm
Re: TMSA 0.5 Preview Release
Try this:
Code: Select all
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" 0N 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%
Se 1Ar50'28" 10S30 + 0'36" 27°54' 0N14 100°56' +16° 8' 343°35' 43%
Mc 20Cp41'10" 317°18' 16S23 180° 0' -50°22' 270° 0'
As 10Ta 7'54" 21N 0 0° 0' 0° 0'
Ep 25Ar36' 1" 47°18' 17N41
Vx 7Li 4'31" 11S54 270° 0' -21°39'
Time matters
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: TMSA 0.5 Preview Release
I endorse and would like to see added the form in Mikestar13's last table above.
EDIT LATER: Should there be a latitude column - all as 0N00? [I lean slightly toward yes.] - Should there be no EP altitude (in reference to the displayed point's relevance) or should bit be listed as 0°00', which the actual point always is? [I may lean toward no.]
EDIT LATER: Should there be a latitude column - all as 0N00? [I lean slightly toward yes.] - Should there be no EP altitude (in reference to the displayed point's relevance) or should bit be listed as 0°00', which the actual point always is? [I may lean toward no.]
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
Re: PRIORITY WISH LIST - Add Angles to data table
I'm still running 4.9.2 I believe, and as I was checking it out and using it I was so very happy for you all with the wonderful work on this program. It really is quite a gem and a groundbreaking tool. But my inexperience as an astrologer really shined through because on the program I was running it was so difficult for me to discern the angles, I saw them in the wheel ok but down in the lovely tables and lists my mind could not find head or tails of any data to remind me of the positions of the angles. I honestly felt pretty inadequate and stupid for a minute because it seemed like everyone else didnt seem to notice or care that they were not obviously spelled out. So I told myself that since there was a wish list inviting wishes I would wish they were listed in future updates.
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: PRIORITY WISH LIST - Add Angles to data table
That detail is indeed coming soon.
I should mention, though, that you're right, I don't mostly care what the longitudes of the angles are. That rarely tells you how angular a planet is. The current tables tell you when a planet is on an angle and how strongly angular it is.
Nonetheless, there are times you want this info so we're adding it.
I should mention, though, that you're right, I don't mostly care what the longitudes of the angles are. That rarely tells you how angular a planet is. The current tables tell you when a planet is on an angle and how strongly angular it is.
Nonetheless, there are times you want this info so we're adding it.
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
Re: PRIORITY WISH LIST - Add Angles to data table
I'm finally up to working on this (I needed a break with mundane midpoints) and I have a question.
It might just be because I'm brain-fried, but I can't figure out how to calculate declination and altitude for these points (except for the ones that are obviously blank or 0). The Swiss Ephemeris functions don't seem ready-made to calculate these values for these ecliptical points.
Do these points have the values that Sun has when it is at that exact longitude? (Does that ever change, sidereally?)
And a second question: Do we want these added to the data table section for each chart in a polywheel? I.e. do we want the natal angle data to show up in the natal planet data section in a return chart?
It might just be because I'm brain-fried, but I can't figure out how to calculate declination and altitude for these points (except for the ones that are obviously blank or 0). The Swiss Ephemeris functions don't seem ready-made to calculate these values for these ecliptical points.
Do these points have the values that Sun has when it is at that exact longitude? (Does that ever change, sidereally?)
And a second question: Do we want these added to the data table section for each chart in a polywheel? I.e. do we want the natal angle data to show up in the natal planet data section in a return chart?
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: PRIORITY WISH LIST - Add Angles to data table
It hadn't occurred to me that SE was calculating these things for the planets (naive of me: I just figured TM was calculating them each time). I buried my notebook of all these formulae a long time ago and can find them of necessary but, yes, you have the concept.Mike V wrote: Wed Aug 28, 2024 1:08 am It might just be because I'm brain-fried, but I can't figure out how to calculate declination and altitude for these points (except for the ones that are obviously blank or 0). The Swiss Ephemeris functions don't seem ready-made to calculate these values for these ecliptical points.
Do these points have the values that Sun has when it is at that exact longitude? (Does that ever change, sidereally?)
To state it more purely: Right ascension and declination can always be calculated when you know Tropical longitude and latitude and the obliquity of the ecliptic. The ecliptical longitudes of the angles, being always precisely on the ecliptic, have latitude 0°00' and whatever their Tropical longitude is. (This is the same as saying they have the same declination as the sun would have at the same longitude.)
Yes, these change. Right ascension and declination are tropical coordinates so these are affected by precession. Since the input is tropical longitude and latitude, when precession causes the tropical longitude to be displaced, we get a different answer.
Also, when you already have three of the four coordinates - say, longitude, latitude, and RA - getting the fourth is even easier. It's something stupidly easy at that point like (I'm making this up) cos long x cos lat = cos RA x cos Dec (that's probably not it, but it's something that easy).
I don't know how TM is precessing natal positions. The way to do it manually is to subtract SVP of the target date from the Sidereal longitude, use the same latitude (longitude and latitude are Sidereal coordinates), and recalculate RA and Dec from that.
If you need me to dig out these formulae, let me know. As you know, we're racing to get ready to be out town for a week with tons of work to do around the house today to finish getting it ready (laundry, loading and transporting boxes, other things to prep for the trip) and then I'll be away from most of my resources for a week. (We're seeing you this weekend, yes?)
Yes, please. I think they should be standard in the sense of planets.And a second question: Do we want these added to the data table section for each chart in a polywheel? I.e. do we want the natal angle data to show up in the natal planet data section in a return chart?
Secondary reason for this: I've been waiting until that's in place to mention that the aspectarian in return charts should include SSR planets in partile transit to natal angles (in the Other Partile Aspect section; I can't think of any reason they should ever be regarded as foreground objects). Transits to MC and Asc are easy, of course, being just ecliptical aspects. To EP-a/WP-a, it should be taken in RA... only viable after we have the precessed position of EP-a! But, meantime, once they're simply in the list (and we're patiently waiting for the aspect implementation), we can see these transits ourselves on the table. (In my head this has always been a preliminary - a setup - for the feature you wanted of optionally including angle contacts in the aspect table.)
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: PRIORITY WISH LIST - Add Angles to data table
An AI search gives an answer I'm not sure is correct, but I'm putting it here in case it's really this simple:
sin Dec = sin Lat - cos long
I'm not sure how this can be right absent information about the obliquity of the ecliptic, but that's what came up.
sin Dec = sin Lat - cos long
I'm not sure how this can be right absent information about the obliquity of the ecliptic, but that's what came up.
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: PRIORITY WISH LIST - Add Angles to data table
Ah, I found my copy of Noonan. I can probably dig some stuff out of here.
Calculating RA & Dec from Long & Lat:
sin Dec = cos OOE sin Lat + sin OOE cos Lat sin Long
tan RA = -(tan Lat sin OOE)/cos Long + cos OOE tan Long
Notice that if celestial latitude is 0° then (since sin 0 = 0, cos 0 = 1, tan 0 = 0) these simplify to:
sin Dec = sin OOE sin Long
tan RA = cos OOE tan Long
Calculating RA & Dec from Long & Lat:
sin Dec = cos OOE sin Lat + sin OOE cos Lat sin Long
tan RA = -(tan Lat sin OOE)/cos Long + cos OOE tan Long
Notice that if celestial latitude is 0° then (since sin 0 = 0, cos 0 = 1, tan 0 = 0) these simplify to:
sin Dec = sin OOE sin Long
tan RA = cos OOE tan Long
Jim Eshelman
www.jeshelman.com
www.jeshelman.com
Re: PRIORITY WISH LIST - Add Angles to data table
No rush on any of this. I appreciate you looking while you're about to depart. I can also try to research this and come up with an answer if you can't find what you're looking for.
Regrettably I am also traveling, but for work, so I won't be there this weekend
Edit - thank you! I'll get these into TM when I get the opportunity.
Regrettably I am also traveling, but for work, so I won't be there this weekend
Edit - thank you! I'll get these into TM when I get the opportunity.
Last edited by Mike V on Wed Aug 28, 2024 10:11 am, edited 1 time in total.
- Jim Eshelman
- Are You Sirius?
- Posts: 19078
- Joined: Sun May 07, 2017 12:40 pm
Re: PRIORITY WISH LIST - Add Angles to data table
See what I posted immediately above.
Jim Eshelman
www.jeshelman.com
www.jeshelman.com