50 by JoeQuarry Joao, Looks good! Do you plan to add more features for use in Horary? Quote Thu Feb 19, 2015 9:36 pm
51 by jventura JoeQuarry wrote: Looks good! Do you plan to add more features for use in Horary? Hi Joe, I'm currently working on a desktop and android versions of Charts. After that, my plan is to start a more featured application (called Elements). Elements should have features for Natal and Horary Astrology (temperament, almutem, essential and accidental dignities, etc.). But let's see how things run with Charts first.. Quote Thu Feb 19, 2015 10:49 pm
52 by johannes susato Hi Jo?o, thank you so much for your programme! It's a real pleasure to work with and to look at. To see the terms is more than helpful. But if there would be small lines or marks, even very short lines or only smallest points on the outer line of the circle to mark the positions of the planets again, their positions with regard to the terms could be seen absolutely certain then. Johannes Quote Thu Mar 05, 2015 12:23 am
53 by irisalbus Hello Joao, thanking you again for the nice app, I would like to note that Saturn is supposed to have turned retrograde on the 14th March 2015 but Flatangle apparently puts it as retrograde only from the 15th. Cheers Iris Quote Mon Mar 16, 2015 7:05 am
54 by zoidsoft irisalbus wrote:Hello Joao, thanking you again for the nice app, I would like to note that Saturn is supposed to have turned retrograde on the 14th March 2015 but Flatangle apparently puts it as retrograde only from the 15th. Cheers Iris I think that is probably due to location. It would be the 15th in some parts of the world and the 14th in others. Curtis Manwaring Zoidiasoft Technologies, LLC Quote Mon Mar 16, 2015 10:24 am
55 by jventura Hi Iris, Curtis is right, it depends somewhat on time and location. But there is also the issue about Saturn being stationary. I found this skyscript thread (http://skyscript.co.uk/forums/viewtopic.php?t=7066) which talks a little bit about the problem, although it doesn't talk too much about "numbers". In my own code, I'm setting that a planet is stationary when its movement is less than 4 arc-seconds, that is why Saturn was only considered retrograde (by my software) after 5 am UTC of the 15th of March. I can't find any sources that define "stationary". Is it when the velocity is 0.0000, or there is an interval here? Can anyone share any ideas about this? Jo?o Ventura Last edited by jventura on Tue Mar 17, 2015 10:43 pm, edited 1 time in total. Quote Mon Mar 16, 2015 5:36 pm
56 by irisalbus Hello all, I was not doing a theoretical debate on when Saturn turned retrograde ? of course the exact time depends on location, too, but when I use a software that calculates a chart, I would expect that, inserting a given location (as I did), the correct time of retrogradation is calculated to that location. So I guess the real issue is, as Joao says, when the state of being stationary is considered to be ended and retrogadation is considered to be begun. Thanks for clarifying it. Unfortunately I cannot add anything regarding the rest of the question. Cheers Iris Quote Tue Mar 17, 2015 9:36 pm
57 by jventura Hello again Iris, no problem! It is just one of those things that is not clarified, therefore the open question to anyone who can answer. Jo?o Ventura Quote Tue Mar 17, 2015 10:45 pm
58 by james_m here is one of a few threads on what defines a stationary planet.. http://skyscript.co.uk/forums/viewtopic ... ry+planets Quote Tue Mar 17, 2015 11:07 pm
59 by zoidsoft irisalbus wrote:I was not doing a theoretical debate on when Saturn turned retrograde ? of course the exact time depends on location, too, but when I use a software that calculates a chart, I would expect that, inserting a given location (as I did), the correct time of retrogradation is calculated to that location. Software can calculate the time of a station with iteration, but when calculating a chart for the moment this is not done (at least this is not the case with the Swiss Ephemeris). The more iterations the more accurate, but there is a point of diminishing returns with iteration calculations where smaller increases in accuracy consumes more processing power especially if you're doing something like finding the greatest elongations of planets (one of my algorithms does this for Mercury and Venus over the span of decades and is quite calculation intensive). Finding returns, stations etc uses similar techniques. One can speed up such calculations by estimating the time (julian date) based upon averages and then using the discrepancy to generate a new estimated julian date, but luck strikes with the first value chosen which is somewhat arbitrary and then there is the value compared against which has to do with the accuracy level desired. Curtis Manwaring Zoidiasoft Technologies, LLC Quote Wed Mar 18, 2015 12:27 am
60 by jventura Hi Curtis, I'm following a simpler approach which is to define a planet as stationary when its longitude speed is less than 1 arc-second. There are other approaches, but it seems no one knows which is the "correct" one.. The source code is quite simple: https://github.com/flatangle/flatlib/bl ... ct.py#L131 Jo?o Ventura Quote Wed Mar 18, 2015 1:05 pm