Add Angles to data table

[Jim Eshelman]

Mike, I've been thinking of something you wrote near the beginning of this project. It's triggering a suggestion, but I'm not sure it's a good suggestion so I'm going to "think it out" in writing and see where it lands.

Since the EP-a position on the face of the chart isn't a thing itself - it's just a marker to let us know where a planet MIGHT be on angle (requiring us to check in RA) - you asked why we bother to put this point on the chart face at all.

Since the RA aspect is calculated (and a strength score is given), I saw the validity of the question. I likely answered something to the effect that we need to be able to tell exactly what angle a planet is on and anticipate a time that something might be there (including by transit, quotidian, etc.).

At least some of this need will vanish when 0.5 appears with an indication of what angle a foreground planet is on. We won't have to look back at the chart and figure it out. For transits and progressions etc. it might still be nice to know the approximate point of the hit (although, in practice, other forthcoming features in TMSA may obviate that need). The fact that a planet can be on EP in longitude OR right ascension is handled by the labelling.

So my suggestion was: Maybe add an option not to display the EP-a on the face of the chart - as is done with Vertex.

It's a simple suggestion, a simple amendment or addition to the code - but the EP and Vx aren't the same in this. We recently talked about adding a Vx marker in the Foreground column of a planet is on the Vx axis mundanely PROVIDED the Vx is selected "on." This wouldn't be what we'd want for the EP, since we'd always want the angularity captured, just might not want the angle drawn. We want all of its functionality to show.

Therefore, while it would be nice to have (the option of) a cleaner chart face by dropping the displayed angle, we don't want any change of functionality, measuring angularity and midpoints and the rest. This would create confusion for the Vertex operating differently.

Thoughts?

[mikestar13]

A possibility: Mark neither Ep-a nor Vx on the chart face (which rather simplifies wheel-drawing code), and let whether vertex-related calculations are done be controlled by the aspect section of Configuration Options. (Check or uncheck a PVP box). The Vx marks in the planetary data--angle marks would be controlled by the current Vertex setting. Personally, I rather prefer this.

[Jim Eshelman]

A possibility: Mark neither Ep-a nor Vx on the chart face (which rather simplifies wheel-drawing code), and let whether vertex-related calculations are done be controlled by the aspect section of Configuration Options. (Check or uncheck a PVP box). The Vx marks in the planetary data--angle marks would be controlled by the current Vertex setting. Personally, I rather prefer this.

Continuing the conversation, trying to feel through this...

If somebody wants these positions, they'll want to see the longitude, I think - meaning, it should be available somewhere. (I know, for instance, that if I were writing about an EP contact in a future version of SMA or other work, I'd better be prepared to say, "The EP at 26°55' Cancer," etc.) There might, of course, be a different place to list this, such as in the data table below (or something else I haven't thought of).

The one thing we'd talked about the Vx on-off is that Vx contacts would be shown in the FG column (but not modify the angularity strength score). The EP-a would work different than this (which is my hang-up in all this), in that we want its presence and its effect on the angularity score regardless of whether its longitude is displayed because, by now, we know that it is quite basic to angularity (one of those "don't give people an option" things) .

PVP aspects (mundane aspects between a planet on the PV and a planet on the horizon or meridian) are independent of all this. They should be able to be on or off (in the same way as parans are on or off) independent of whether Vertex is shown on the chart or Vx contact is displayed on the FG column.

My only ambivalence in all of this is that all the scenarios show EP and Vx being functionally treated differently (because, in fact, they do behave differently LOL).

[mikestar13]

Proposal: separate options for "vertex in chart wheel" and "vertex in angle marks" (may not phase it exactly that way but this is the concept). Add an option "eastpoint in chart wheel", but no corresponding option in angle marks. I may also try some other ideas (an angle data section similar to planetary data ?).

[Jim Eshelman]

I do like the earlier, simpler idea that if people pick Vertex, it shows up in the FG section (when there is a contact). I proposed that approach to make things simpler. Am I over-simplifying? (Your proposal overcomes the "why are we treating these differently" problem by letting the user decide whether to treat them differently LOL.)

Adding them to the table might be the data section might be the way to handle their visibility (no need for a separate "angle section, just added lines). If you do this, then Asc and MC should probably be there routinely (I have mostly liked their NOT being there, though sometimes thought it would be handy to have them there.) Having MC or EP on that table means I don't have to scroll to the top to get the RAMC for EP-a orbs <s>.

Other programs (SF and others) do list these lines, with various consequences for whether the points are turned on. Here are some quirks of the lines:

• It would routinely provide the longitude for the angles. For Asc/MC this is visible on the wheel, but some might also like it on the table. For EP/Vx it solves the "how to display these" without adding them to the wheel.
• Latitude of all of them is 0°00'.
• Speed is weird. That is, SF lists speed values that make no sense to me, I'm not sure what they are. For every other point, this is the daily motion, meaning where the point is 24 hours later, so they should all be something close to 361°. I'd suggest leaving this column blank for the angles unless you have a clever solution in mind. It's not really useful and seems to be misleading.
• RA and Dec are valid measurements (and RA is of practical importance for MC and EP). Any of the points could have a valid RA/Dec to display, but of what use? (Very minor problem that people do weird things trying to use RA of Asc, etc.) I suppose list them anyway just to keep it simple?
• MC and Vx azimuth are always a fixed value, the other two are unique but mostly meaningless. Altitude is always 0 for Asc but might be of minor interest for the others. (EP will always be confusing and meaningless on this because it will be the ecliptical degree that fulfills the RA requirement, whereas the actual EP is always altitude 0.)
• PVL could be listed as much as a reference point as anything else, but no angularity score (it would be visually confusing).

Thoughts of the moment... My simple suggestion for simplification wades into all kinds of piddling little complexities.

[mikestar13]

Musing on the separate angle section idea, what information will be wanted for each angle? For Mc/Ic/Ep/Wp, we will want longitude and RA, for As we will want longitude and OA, for Ds longitude and OD, for Ze/Na, just longitude, for Vx/Av longitude and hypothetically azimuth, but since the azimuth is fixed by the definition of azimuth, we only need to list longitude. Basically there would be columns for everything, but some which make no sense for angles (RA of As, for example) can be omitted or repurposed.

[Jim Eshelman]

Musing on the separate angle section idea, what information will be wanted for each angle? For Mc/Ic/Ep/Wp, we will want longitude and RA, for As we will want longitude and OA, for Ds longitude and OD, for Ze/Na, just longitude, for Vx/Av longitude and hypothetically azimuth, but since the azimuth is fixed by the definition of azimuth, we only need to list longitude. Basically there would be columns for everything, but some which make no sense for angles (RA of As, for example) can be omitted or repurposed.

LOL, I anticipated the question and answered immediately above. - BTW I don't think you need an extra section - just optional additional lines - unless you see another significant advantage in marking a new section (e.g., space use).

Are OA and OD really needed? (Useful to anybody these days?) I don't think Zenith longitude is needed since MC longitude is given (ditto EP-L).

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 and Asc would always be there, EP and Vx added if "display" is selected. Something like this:

Code: Select all

Pl Longitude   Lat   Speed    RA    Decl    Azi     Alt     PVL    Ang G
MC 01Ta37'59" 00N00          53°25' 19N12 180°00' +75°00' 270°00'
As 05Le14'03" 00N00                 11N42  75°50' + 0°00'   0°00'
EP 26Cn54'45" 00N00         143°25' 14N30                 
Vx 19Sg51'04" 00N00                 22S43 270°00' -43°35'

Is that too complicated and crazy? (Or are some of my choices illogical and crazy on the list?) BTW, the only reason I could think to list PVL of Vertex is the surprise feature that planets square Vx in longitude (NP, SP) also square it in PVL; but with the longitude visible, the PV connection is redundant at best.

[mikestar13]

I'm also skeptical of listing items that are true by definition such as altitude of the ascendant being 0 degrees, but 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.

[Jim Eshelman]

I would have doubts about expressing 00Pi31'57" as Pi31'57", however, nor do I think reasonable to express the Sun's latitude as N00 or the like. One leading zero in the units column should be retained rather than leaving the degree portion of the entry blank.

One leading 0 makes sense in those cases. - On latitude 0°00'00.0" one wonders if N or S is warranted, though it certainly makes sense at, say, 0S00'01" as 0S00.

Should the leading zeros in the tens column of minutes and seconds also be zero suppressed? I'm beginning to think so.

No strong opinion. In astronomical references that come to mind, they are left in place, but maybe that's changed (I'm thinking of references I last saw decades ago).

Correction: At least this one standard reference from NASA drops internal leading zeroes:
https://eclipse.gsfc.nasa.gov/TYPE/mercury2.html#me2002

Thus, for example (draw your own conclusions on readability, I might be of two minds on this):

Code: Select all

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

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?

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 (treated for a moment as the point of intersection with the ecliptic) is always co-latitude plus MC declination, it's altitude being the co-lat. (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.)

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

But at any rate, this idea is becoming quite workable.

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.

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, in which case its abbreviation appears under FG. -- 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 is 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]

I'm also skeptical of listing items that are true by definition such as altitude of the ascendant being 0 degrees, but 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.

Agreed. It makes the table slightly longer, but that's OK - it's for a good cause.

And see my last answer (while you were posting this), especially the last paragraph - thinks simplify considerably.

[Jim Eshelman]

I'm also skeptical of listing items that are true by definition such as altitude of the ascendant being 0 degrees

This might be useful as a reference point, e.g., Vertex azimuth 270°00' attaches the idea of "where we are looking in azimuth for Vx/Av contacts."

OTOH, this is only necessary when the program isn't filtering out the Vx/Av contacts. (SF doesn't, TMSA will.)

On the other other hand, these are legitimate (and, one could argue, meaningful) measurements. They're not junk data. At worse they are not useful. I could argue that they are correct measurements, have no downside ever, and might have an upside for a given astrologer (if nothing else, for education purposes).

But I'm not stuck on any of this.

[mikestar13]

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.

[Jim Eshelman]

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 something I was thinking about reminding me of your original query on why we put EP on the chart in the first place - and 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 work.

I think this will be a better one. Along the way, it shifts (just ever so slightly) the way we think about it.

[Jim Eshelman]

Referring to my previous posted example:

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° 0' 270° 0'
As  5Le14' 3"  0N 0                 11N42         + 0° 0'   0° 0'
EP 26Cn54'45"  0N 0         143°25' 14N30                 
Vx 19Sg51' 4"  0N 0                 22S43 270° 0' -43°35'

If you think it important enough to do the extra labor, Speed is an easy calculation. In all cases, the RAMC increases a stable amount in 24 hours, 24h + 3m56.56s IIRC. I imagine you are getting Speed from function or hook built into the SE, but for the angles it amounts to increasing RAMC 3m56.56s, recalculate the angle, subtract blah blah blah.

After my "throw this together as a sample without thinking too hard," I find that 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). On my "throw it together," I left Asc azimuth in solely for rare astronomical curiosity thinking someone might want an easy way of seeing whether Ascendant is north or south of due east at any given moment. However, probably anyone who would think to ask themselves that question would also know that the VP's longitude slices the zodiac in half and answers the question, any Asc between 5° Pisces and 5° Virgo rising and setting south of due east, anything in the other half setting north of due east. - In other words, it's probably not worth having there (and things might be simpler and more useful without it).

Altitude of Asc instructive, altitude of EP is nonsense (the real EP always has zero altitude, and this ecliptic point isn't a thing by itself). Outlook of MC may be considered nonsense (since it's the intersection point only), may be interesting, but in any case is always Dec + co-latitude. Vx altitude might be a curio (how far is that point off the horizon? does Vx behave differently when REALLY not foreground?) or may simply be misleading (because it makes the ecliptical intersection seem important). I have no clear opinion on whether MC and Vx altitude should be included. (Since we have the column, I think Asc alt should be and EP alt should not.)

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), and PVL has only MC and Asc (the relationship of which is measured in PVL).

[mikestar13]

I like the way this is evolving. Each angle pair having two points of similarity is pleasing. Speed of the angles is not useful enough to justify reformatting the page to fit the 361-ish numbers involved.

[Jim Eshelman]

Got it! (And you're right - it would be an average of 361°, not an average of 1°. I temporarily forgot that. It will make intuitive sense why the angles have no values in the Speed column.)

Should Ang for angles be blank, or should it have something like three or four dashes (---)? (I think blank, but the question arose.)

[mikestar13]

I think with computer output it's fairly intuitive that if something is blank, it is intentionally so, a much less certain inference when data is written by humans.

[mikestar13]

Here is the new planetary data section with the angles:

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%   
 As 10Ta 7'54"                       21N 0           0° 0'   0° 0'
 Mc 20Cp41'10"               317°18' 16S23 180° 0' -50°22' 270° 0'
 Ep 25Ar36' 1"                47°18' 17N41 
 Vx  7Li 4'31"                       11S54 270° 0' 
 -------------------------------------------------------------------------

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.

[Jim Eshelman]

Overall impression: Cool! (The FG column looks REALLY good imvho.)

Sun's latitude: I know exactly why you did it this way and it still looks weird. It's exactly right but it LOOKS broken. Some other solution? One weird possibility: ONS0?

I thought your last word on dropping lead zeroes for minutes and seconds was that you would do it for TIME but not degrees. Did I misunderstand? I don't really care either way (and I think the above looks good): I'm echoing back what I thought you had said,

I'll think about Alt of Vx. It seems it should be easy. I'll let you know if I figure it out.

[Jim Eshelman]

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'.

[mikestar13]

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%   
 As 10Ta 7'54"                       21N 0           0° 0'   0° 0'
 Mc 20Cp41'10"               317°18' 16S23 180° 0' -50°22' 270° 0'
 Ep 25Ar36' 1"                47°18' 17N41 
 Vx  7Li 4'31"                       11S54 270° 0' -21°39'
 -------------------------------------------------------------------------

[Jim Eshelman]

Exactly! (Calculations confirmed, too.)

[mikestar13]

Now onto revising the chart options page!